Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

feross.org

Post reply on HN
Print view View original

1–10 of 94 posts

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

#2

Post by josefresco »

To protect the wp-config.php file using htaccess is a well known security precaution for any WP pro.

The issue however is if you have a copy of said file, in which case protecting the main version would be useless.

Also I'd say the blame if you can assign any is on Vim, Emacs, Gedit, and Nano which would have had to crash in order to set these chain of events in motion.

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

#4

Post by thejosh »

josefresco wrote: post #2

To protect the wp-config.php file using htaccess is a well known security precaution for any WP pro. The issue however is if you have a copy of said file, in which case protecting the main version would be useless. Also I'd say the blame if you can assign any is on Vim, Emacs, Gedit, and Nano which would have had to crash in order to set these chain of events in motion.

wp-config.php~ and wp-config.php# and other variations may slip through a simple htaccess, even for a "wp pro" :-)

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

#5

Post by antihero »

How utterly stupid do you have to be to engineer software that requires you to have configuration files in a publicly accessible folder? Even most shared hosts now will have a public_html folder and the ability to put sensitive stuff not inside it.

The .htaccess hacks are great but they are just patching the symptom, and one slip up and you're back to square one.

The best way to do configuration is to have it in environment variables that are populated in a completely separate config file for the specific instance, so for instance a uWSGI ini file.

This is very easy with Django and uWSGI.

In your uWSGI.ini:

    env = DJANGO_SETTINGS_MODULE=yoursite.settings.production
    env = DJANGO_SECRET_KEY=herp
    env = DJANGO_DB_PASSWORD=derp
In yoursite/settings/production.py

    from .base import *
In yoursite/settings/base.py

    import os
    
    DATABASES = {
        'default': {
            ...
            'PASSWORD': os.environ.get('DJANGO_DB_PASSWORD'),
            ...
        }
    }

    SECRET_KEY = os.environ.get('DJANGO_SECRET_KEY')
I'm not sure if this is possible with WordPress or the whole shitty PHP way of doing things - perhaps if you had a FPM pool for each site and site specific configuration in there?

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

#6

Post by djt »

josefresco wrote: post #2

To protect the wp-config.php file using htaccess is a well known security precaution for any WP pro. The issue however is if you have a copy of said file, in which case protecting the main version would be useless. Also I'd say the blame if you can assign any is on Vim, Emacs, Gedit, and Nano which would have had to crash in order to set these chain of events in motion.

thanks for the summary, I had to read the whole article to pick that out. Also, if there is a connection error (such as FTP session ending) that could also leave the copy on the server.

Take away is to not use an editor that auto-saves or to save it on your local computer and put the finished file onto the server.

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

#9

Post by mobweb »

My small-ish personal website gets hammered everyday by bots trying to access obscure config files and installer scripts from various CMS I have never even heard about.

I think the chance of successfully obtaining DB credentials using this method is fairly high even without those "backup files" mentioned in the link.

I'd assume there are many people out there who can set up a simple CMS themself but ignore/don't understand how to properly remove the various "installer" and "configurator" scripts once they're done...

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

#10

Post by analog »

MattBearman wrote: post #7

This is why everything except a font accessor (index.php) should be stored in a directory behind the publicly accessible web root directory. It's standard practice for most web frameworks, and yet it seems the most popular CMSs don't bother.

It would make the CMSs harder to deploy, security gets traded off for convenience.
Post reply on HN