Live data from Hacker News

1% of CMS-Powered Sites Expose Their Database Passwords (2011)

feross.org

61–70 of 94 posts

Re: 1% of CMS-Powered Sites Expose Their Database Passwords (2011)

#61

Prevent nginx from serving files that start with a period or tilde will help. # prevent hidden files from being served and logged location ~ /\. { access_log off; log_not_found off; deny all; } # prevent tilde files from being served and logged location ~ ~$ { access_log off; log_not_found off; deny all; }

This is a bit of a hack, since you don't really know how the "backup" file will look like. It might end with tilde, but it might end with .bkp. It's impossible to iterate through all the possibilities, just like it's impossible to separate them from valid files.

A much cleaner solution would be to separate "callable" entry-point files (like index.php) from "library" files into separate directories and point nginx/Apache only to the directory with callable files.

Re: 1% of CMS-Powered Sites Expose Their Database Passwords (2011)

#62
This is another great reason to "keep config files out of web root." WordPress supports this, although it's not by default, and poorly documented, and even suggested it's not beneficial.

http://codex.wordpress.org/Editing_wp-config.php#Configure_D... http://codex.wordpress.org/Hardening_WordPress#Securing_wp-c...

Re: 1% of CMS-Powered Sites Expose Their Database Passwords (2011)

#64
post #43

how much % of these 1% websites have their database server allowing remote connections ? does the DB password mean anything without allowing remote connections ? (let's forget shared hosts for a moment)

Assuming there are no other bugs in the CMS in question, and no other apps are installed with access to the same server, and the admins implement good authentication policies, there is no danger from this.

But...

It is rare there is only one app on a server, even a non-shared one, so this information could be used in conjunction with this information in order to cause bother. It is not uncommon to see something like phpMyAdmin installed in a standard location on a given domain and not locked down well - for sites where this is the case this bug is very serious.

It is scary how many people out there calling themselves sysadmins use the same password for everything to do with a given service, or even for everything - for them this is a bigger problem as revealing the DB password also reveals the credentials needed to access other things (perhaps an SSH account with privileged access either directly or via sudo).

Re: 1% of CMS-Powered Sites Expose Their Database Passwords (2011)

#65
post #45

0. Put local config files outside of webroot or other publicly accessible directories, include programatically. 1. Disable swap/backup files in your editor (or write them to a different location)[1] 2. Git ignore or SVN ignore swap files and backup files 3. Configure your web server to not serve such files. Some combination of these should keep you safe. :) [1]: in vim: noswap nobackup nowritebackup or http://vim.wik…

Step 0 is the only way to do it. I'm constantly stunned to see how many PHP apps violate this rule.

Re: 1% of CMS-Powered Sites Expose Their Database Passwords (2011)

#66
post #15

Earlier quoted context omitted.

You are correct, you could do almost exactly the same thing in "the whole shitty PHP way of doing things" using FPM pools.

Excellent! Part of me wants to have a play and see how closely I can get a PHP/FPM/nginx to resemble my Python/uWSGI Emperor/nginx stack. You can do stuff like include /srv/*/pool.ini, right?

uWSGI is capable of serving PHP, mind.

Re: 1% of CMS-Powered Sites Expose Their Database Passwords (2011)

#67
post #45

0. Put local config files outside of webroot or other publicly accessible directories, include programatically. 1. Disable swap/backup files in your editor (or write them to a different location)[1] 2. Git ignore or SVN ignore swap files and backup files 3. Configure your web server to not serve such files. Some combination of these should keep you safe. :) [1]: in vim: noswap nobackup nowritebackup or http://vim.wik…

Step 0 is the only way to do it. I'm constantly stunned to see how many PHP apps violate this rule.

You've obviously never had an amateur developer run smack-into open_basedir issues before. The application basically gets a 404 error when including dependencies, until they look for open_basedir configuration. A developer really needs to know when open_basedir has restricted an include, because the error is really vague.

And shared hosts don't generally allow files outside the webroot of a site. When they do, they might already have open_basedir set to only allow inclusion WITHIN the webroot.

Most packages like Wordpress are developed to run on the maximum number of servers. It isn't built to run on the best, or smartest configured ones—but the average, out-of-the-box Apache/PHP install.

Re: 1% of CMS-Powered Sites Expose Their Database Passwords (2011)

#70
This is not anything new and has been known for ages.

Assuming one follows the "defense-in-depth" approach, however, this is easily mitigated and becomes a non-issue.

FWIW, I could give you the username and password that my instances of WordPress use to connect to MySQL and you wouldn't be able to do anything with them.

Post reply on HN