I'm working on an application in VB.NET that has to connect to a MySQL database and FTP. How secure is it if I used it in an application that I gave to other people. E.g. if I was to let other people use this application would they be able to find out the MySQL and FTP connection details through intercepting packets or something like that?
If that's the case how can I work round this? Also, part of my application is an uploader for users to upload files, is FTP secure for that or are there better alternatives ways in doing that? My server is a Windows Server 08 if that makes any difference.
Thanks in advance.
FTP is plaintext. It is very easy to get user names and passwords just by packet sniffing. If the ftp is supposed to be secure rather look ay sftp or ftps solutions. These use SSL type encryption on the network layer. Never ever use a ftp server for sensitive information.
MySQL traffic can also be sniffed though it is considerably harder to reverse engineer the protocol. If data has to flow between client and mysql in a secured fashion you can configure mysql to use SSL certificates to encrypt the information. This will ensure security is of highest standards.
It depends, but as per Accessing SQL Server with Explicit Credentials article and it is applicable to MySql as well:
The recommended method is to store the predetermined user name and
password on the server, and then read it and add it to the connection
string at run time. An advantage of this technique is that your
application can access the database using different credentials under
different circumstances, depending on what it needs to do in the
database.
Security Note Never hard-code credentials as strings into programs in your application. Anyone who can get access to the code
file, even the compiled code, will be able to get at the credentials.
Security Note Always give a predetermined user name the minimal access privileges to a resource. Never use "sa" or any other
administrative-level user name. Always use passwords
Related
I'm trying to solve the problem described by CWE-798, specifically how to allow my application to authenticate to a database securely. I would like to set a mysql password within mysqld and push that information out to a PHP application server. This entails communicating the new password from mysqld to PHP before a PHP instance attempts to connect to the mysqld.
(I did read through the suggested approaches on mitre.org and have some knowledge of privileged access management - however NONE of the recommendations actually solve the problem).
Unless this is initiated within the mysqld e.g. using its event scheduler, then I need to maintain some sort of script outside MySQL which will need credentials to connect - thus defeating the objective.
My problem is that I don't know how to get MySQL to initiate a client connection to the application to inject the new password; it does not appear to provide a standard function for invoking a URL nor for executing a program.
Is my only option to implement a UDF?
The vulnerability you're describing seems to primarily relate to applications that are in the hands of users that can freely inspect what they've been given, such as might be the case in a desktop application or a mobile app. If you have credentials in there you must take great pains to encrypt them, and then prevent that encryption from being cracked by protecting your key, but seeing as how all of this has to happen on the user's hardware you're fighting a battle you may never win.
This is how the DVD encryption was cracked, the private key for decrypting DVD data was stored in a desktop application and eventually uncovered.
Server-side code has different concerns. Here you want to avoid hard-coding credentials into your application not because you're concerned about hostile users per-se, though that can be an issue, but because you do not ever want your credentials to end up in a version control system.
One way to ensure this never happens is to have the credentials stored in a file external to your application, like a config file that the application can reference. Most frameworks have some kind of configuration file (.yml, .ini, .xml) that define how they connect to the database. This file should be stored on the server and only on the server, not on developer workstations, not in your version control, and especially not somewhere shared.
You can go down the road of using something like Zookeeper to manage your configuration files but the investment of time required makes this a futile exercise unless you're managing hundreds of servers.
So the short answer here is: Don't put your credentials in your code, or store it with your code. Put it in a config file that's kept on the server and the server alone.
I am creating a web service for a small company which will use client authentication and possibly https for a RESTful service. I am asking a very simple question that I hope is not too broad, but I am very new and naive to internet security. What precautions must I take to ensure my data is secure?
To describe my service a bit, users have an account where they place presumably insensitive information and retrieve it from a database using a homemade authentication token I create on successful login with a salted password. I am using an amazon instance where MySQL is local and access is granted remotely to me so I can access it directly from my home. I am using a few php scripts to do my work requesting and adding data and am attempting to protect against injection. I am storing my MySQL credentials in a separate file from the php scripts. I can only ssh into my server with a pem file that I believe is safe.
My biggest fear is that someone will come and delete all of my data. What other precautions must I take? Thanks
If you're using Amazon EC2 then you should make use of their security groups to lock down your MySQL server and ensure that no external access to it is possible.
Application servers have an internal non-routing 10.x type IP that should be used for access control, and any external IPs, like your home network, should be specifically whitelisted if VPN access or SSH tunnelling is not practical, as those two are far easier to secure.
Be absolutely sure that no credentials, configuration files, or keys are stored anywhere in your web root. That is, should you accidentally misconfigure your application server in the worst possible way, with directory indexes turned on and everything, it's not possible to snag anything critical.
You might also want to specifically exclude the downloading of *.inc in case you make a mistake. The idea here is to set up a number of safeguards you'd have to break before things go horribly awry. A single-mistake failure situation is always the result of bad planning.
Above all else, be extremely vigilant about proper SQL escaping to avoid SQL injection bugs as no amount of firewall security on your MySQL server will help you when someone can drive a truck through a mistake in your code and have free reign on the server. It's recommended to thoroughly audit any SQL interfacing code you've written before going live with it.
Be sure to have a proper deployment procedure that uses a version control system. If you ever have an intrusion it's very easy to roll back to a known-good version of the code if you have one. The 1990s style "throw files at server with FTP" deployment approach is hazardous at the best of times and fatal to your business when it goes wrong. Use version control or you're living on borrowed time.
on a Windows local network I have a MySql database, several client applications (that only query the database) and one Windows NT service that fills the database on a regular basis.
I am looking for the best way to store database credentials such that all applications can access the database.
For the client applications (that are run by normal users) I store the credentials in the Windows credential manager, that as far as I understand is only visible to the specific user.
My question is:
Where do I best store the MySql credentials such that the Windows service can access the database?
thanks in advance,
Nicolas
The LsaStorePrivateData and LsaRetrievePrivateData functions are a reasonably straightforward method of storing and retrieving a secret. Data stored in this way can only be retrieved by someone with administrative access to the machine. This doesn't provide 100% protection, but (assuming there are no bugs and that the cryptographic algorithm has not been broken) the protection is as good as is logically possible if the secret has to be retrieved by a system service without manual intervention.
There is no built-in GUI for LsaStorePrivateData. You will need to write some code that uses this function to save the MySql credentials. (This code could, however, be located in the same executable as the system service, and accessed via a command-line option.)
The service runs as a user also, so why can't you use the same approach for it? That assumes that the service runs as its own user, or some other secure account.
I'm new to MySQL and I'm using a desktop DB management app called "Querious" to simplify the process while I learn.
I want to work on (mainly just structure & basic population) a database that's hosted elsewhere, but the host won't allow any remote MySQL calls on their server.
What is their reasoning for restricting MySQL calls to localhost only? Is this a security or a performance concern?
This is a security concern. The idea is that if people can't remotely connect, they have to compromise the system. Not just the files that hold the database information.
You may be able to request that just add your IP address to a trusted host file, but I doubt they'll do that either.
It's fairly common practice to not allow remote DB connections
I've run into this problem with GoDaddy where they implement this by default. You can change this, however, by indicating that you want to allow remote access. If you've already created your DB, though, you can't change it, so I would recommend creating a new DB and deleting your other one.
The reason why is for security. If only your app can call your DB, you don't have to worry about other people trying to access it.
Distill,
An improperly-configured MySQL instance is dangerous, whether the user is remote or local. This could allow malicious attackers to cause crashes or remote execution of arbitrary code (i.e., owning the machine).
You can use PuTTY to create a tunnel if it's allowed by the server so that your application traffic goes through ssh and then is forwarded to the correct port on localhost.
Currently the major means of connecting Flash AS2/AS3 to a MySQL database are:
Flash > PHP > MySQL -- "secure code" in PHP Scripts
Flash Asql or Assql > MySQL -- "secure code" in MySQL Stored Procedures
The second approach is newer, but directly connects to a MySQL DB using binary sockets and ByteArrays.
In which case would the "secure code" be less accessible and therefore more secure?
I'm assuming stored procedures cannot be accessed via FTP so that might be harder to break into?
Stored procedures can only be accessed by someone with the correct database credentials so they will be secure assuming no one cracks your Data Base password. You know it might actually be that the PHP code is more secure as you can hold the Data Base password on the server instead of in the host app.
I suppose you can always decompile flash and try to locate the password in the host app because with asql the password will be stored in the host app, instead of on the server hidden behind PHP
I'm not sure asql would work for users behind the proxy, so I wouldn't use it for website. Approach with PHP in the middle seems to be better and you can (and should) model api for your application that is different from your DB structure.
It appears that both assql and binary sockets are synchronous links that use a socket connection to the database. Which might be great for an AIR application, but for a browser app might be highly problematical. Is this for sure what you want? Your question about access through stored procedures gives me the idea you aren't too sure about this stuff.
In fact, using PHP properly will likely be easier for building a solid abstraction and security indirection barrier between your app (and its host) and the database.
EDIT:
Web clients and servers use the http protocol to communicate. This is called a "stateless" and "connectionless" (which is only kinda true) protocol because the connection between the two only lasts as long as it takes for the client to request everything and the server to send back everything. The obvious benefit is that the server only knows about each client for a very brief period of time.
A socket (in the sense these two protocols use one) is a permanently established connection between the client and server that persists until one end or the other closes it (connection-based); and both sides know the state of the connection (open or closed). So they tie up a lot of host resources per client for a long time, and things get wacky when the connection breaks. Big difference, and it can't be run through the ports supporting web pages - another port needs to be provided (sometimes two) on the host and the client to support the socket.