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

31–40 of 94 posts

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

#31

Post by antihero »

Kudos wrote: post #15
antihero wrote: post #5

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 envi…

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?

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

#32

Post by Yaggo »

The fundamental problem with many PHP applications is that the php files are located in document root, i.e. can be potentially served as static files. More correct approach would be to put them outside document root (e.g. APP_DIR/lib), and using index.php which requires them (e.g. APP_DIR/static/index.php).

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

#34

Post by switch007 »

switz wrote: post #30
Torn wrote: post #26

Earlier quoted context omitted.

Could be HN mod editorialising at work

Don't start assuming without evidence. I don't support the changing of titles, but I'm not going to blame the mods for something they didn't do.

Perhaps "it could be..." was merely a suggestion rather than an accusation? (It's within the realm of possibility based on empirical evidence.)

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

#35

Post by fatalerrorx3 »

anu_gupta wrote: post #8

The title of the linked post is 1% of CMS-Powered Sites Expose Their Database Passwords - has it changed since submission?

It looks like this article was submitted over a year ago with that original title, it's since changed it's name and was recently resubmitted

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

#36

Post by nodesocket »

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;
    }

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

#37

Post by kmfrk »

antihero wrote: post #5

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 envi…

    The best way to do configuration is to have it in
    environment variables
Isn't it the only sensible way, actually?

Django doesn't expose static files the same way, so you still get away with a secret.txt stored as a file.

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

#38

Post by sirclueless »

damncabbage wrote: post #14
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.

> Also I'd say the blame if you can assign any is on Vim, Emacs, Gedit, and Nano ... Or the guy who is just editing files directly on the server (or shovelling everything up with FTP), instead of sane version control. (I'm not sure anyone doing the former can be counted as "Pro", WP or otherwise.)

Please don't put your database passwords into version control. https://github.com/search?q=path%3Awp-config.php&ref=sim...

(A) Database passwords are a security risk. You don't want them escaping to other servers when you clone or share code.

(B) Wordpress is commodity software. You are unlikely to need custom modifications to the source. "I'm on version 3.4.2" is sane enough version control.

(C) Database passwords are ephemeral. You don't need to keep a durable record of them. If your hard drive fails or you otherwise lose your record of them, you can just change the password. What is needed is a good backup strategy, not a durable password.

I would say live editing wp-config.php outside of version control is the best strategy, until you start needing to synchronize multiple webservers. At that point you should switch to some deployment and configuration manager like Chef or Puppet, not put passwords into version control.

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

#39

Post by chrisguitarguy »

javipas wrote: post #27

The author helps with an Apache rule: Order allow,deny Deny from all What would be the equivalent of this for Nginx?

    location ~ "(^#.*#|~|\.sw[op])$" {
        return 401;
    }
Or something along those lines.

Nodesocket's answer is good as well: http://news.ycombinator.com/item?id=5164017

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

#40

Post by mylittlepony »

Yaggo wrote: post #32

The fundamental problem with many PHP applications is that the php files are located in document root, i.e. can be potentially served as static files. More correct approach would be to put them outside document root (e.g. APP_DIR/lib), and using index.php which requires them (e.g. APP_DIR/static/index.php).

That's not restricted to PHP, since it does not even depend on the language.
Post reply on HN