Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

This is the first time that I am working on a web application. I was going through the question What should every programmer know about web development? and noticed one thing that I knew nothing of:

Make sure your database connection information is secured.

I am confused about it because as per my knowledge the database info, password, etc will be on my server used in my coding to connect to the db. Then what does this line specifically mean?

share|improve this question
add comment

2 Answers

up vote 6 down vote accepted

Basically, it means that you must store the username and password to the database in a directory that the web server cannot access directly. For example, if you use PHP, and your Apache configuration points to /project-root/www, you could store the login information in /project-root/config/db.php; if you store it in, say, /project-root/www/config/db.php. Assuming that your server configuration isn't broken, this means that db.php cannot be accessed over the internet.

You also need to get the permissions for the config file right. The account the web server runs under (ideally a dedicated account for your application) should be the only one with any kind of access to the config file. In a UNIX environment, assuming Apache is configured to run your application's virtual host under your own account, 600 or even 400 is a suitable permission set. This ensures that other users with access to the same machine (except root) cannot read your configuration file.

Additionally, you'll want to take a few more security measures:

  • Create a database user specially for the application, and give it just enough permissions to do its job (SELECT, UPDATE, INSERT and DELETE on the tables it needs is usually enough). Do not give the user any permissions on any other databases: if your application is compromised, you can at least mitigate the risk for other databases. If the user also has permissions on system databases, a successful attacker can possibly elevate permissions by creating new users through the system tabls and granting them more permissions. Specifically, never ever use administrative database accounts for production websites.
  • Use a strong password. Since you won't have to manually type the password a lot, a sequence of, say, 32 random bytes, converted to base64, should make for a good enough password.
  • If the database runs on the same machine as the web server, configure it to refuse connections from anything but localhost. If it runs on a dedicated server, use a whitelist of allowed hosts, and put the whole thing behind a properly configured firewall.
  • If you use a quasi-interpreted language such as PHP (where the source code sits on the web server), it is a good idea to write your configuration as source code too, and use an appropriate filename extension. This way, if someone manages to request the configuration file over the internet, it will be executed, and produce a blank page, still hiding the database credentials from the attacker (this is a last straw though; you should never rely on this alone).

And of course, you need to check your application for general security flaws, especially SQL injection and path traversal: these are the most common ways of getting at your database.

If the application is really sensitive, you need to take more precautions, such as encrypting configuration files, but for your average low-profile website, this should do the trick.

share|improve this answer
add comment

Basically, you need to ensure that your configuration files which contain that connection information are not in a place where they could be read by anything other than the code.

For example, often people will put such files under the webroot, where it is potentially possible that the webserver will serve them as plain text, so that users can read them. Clearly, that's bad. So put them somewhere outside of the webroot, accessible only to the code that's doing the connecting.

share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.