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

51–60 of 94 posts

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

#51

Post by uxp »

chrisguitarguy wrote: post #39
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

It should be noted that the author states that this htaccess rule "block[s] access to any file containing the string wp-config.php", but the rule itself is designed to block any temporary editor file matching the pattern he describes in the article regardless if it is named wp-config.php or not. Your nginx rule does the same.

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

#53

Post by killahpriest »

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…

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.

Complete untrue. You can (and are advised to) move your wp-config.php above public_html. The reason its not done by default is because you just can't do this on many of the crappy hosting services, and it creates a barrier for entry for people making their first-ever site.

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

#54

Post by Yaggo »

mylittlepony wrote: post #40
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.

True, but other languages are not typically processed in the traditional mod_php way where urls are directly mapped to files in your static root, thus it's extremely rare to see e.g. python or ruby files served as static files.

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

#55

Post by bradleyland »

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).

I'm not sure this is fair to pin on PHP in a broad way. Many PHP frameworks do not use the application file-structure root as the httpd document root.

For example with a Symfony app:

. - App root

./web/ - httpd doc root

./app/ - app files

./app/config/ - config files

Barring an exploit that lets you break out of the httpd doc root (not saying this is impossible), there is no way to request the config or app files directly.

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

#56

Post by mauvehaus »

nodata wrote: post #48
mauvehaus wrote: post #46

Earlier quoted context omitted.

A solution using xargs instead of exec: find . -name "*.swp" | xargs rm I believe find -exec forks and execs once for every file found, xargs may only fork and exec once, provided that all of the files find finds fit in a single command line. Hopefully not an issue in this case, but it can greatly speed up a deletion when you have a lot of files to find and delete. [EDIT] Doesn't properly handle spaces in filenames,…

Please don't run the command above, it doesn't handle spaces. You might delete something you didn't intend to delete. You need to add -print0 to find, and -0 to xargs to make it work properly: find . -name "*.swp" -print0 | xargs -0 rm But better would be to use -delete as I wrote above.

I'm a little bummed to find that this doesn't work on Solaris either (just checked). I don't generally use spaces in paths, but it's probably about half luck that I haven't been bitten by this yet. And sadly, I can't always just put GNU findutils on.

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

#57

Post by antihero »

killahpriest wrote: post #53
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…

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. Complete untrue. You can (and are advised to) move your wp-config.php above public_html . The reason its not done by default is because you just can't do this on many of t…

Except you can on 99% of crappy hosts. I remember even Tripod allowed you to put things outside of public_html.

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

#58

Post by antihero »

sirn wrote: post #44
antihero wrote: post #31

Earlier quoted context omitted.

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?

Yes you can. Dotdeb's php-fpm.ini even includes this line by default: ; To configure the pools it is recommended to have one .conf file per ; pool in the following directory: include=/etc/php5/fpm/pool.d/*.conf Then you could configure ENV inside FPM pool using the env directive: env[DB_HOST] = localhost env[DB_USER] = foobar env[DB_PASSWORD] = foobar ...and use something like this in e.g. Wordpress config: define('D…

That's pretty handy. Didn't think about the phpinfo thing, actually, though in all fairness if they managed to upload any PHP files you're rather screwed. I think the way to be secure would be to not actually serve PHP files in the document root and instead have nginx proxy / directly to the FPM pool, and just alias your static files over, much as one would with Django.

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

#59

Post by antihero »

shakesbeard wrote: post #24
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…

Because your average graphics designer or blogger has no idea what Apache is, what public directories or file permissions are. They just want to run their own blog. That's why Wordpress (or PHP for that matter) is successful; it's easy to set up and get started.

In that case why not just host it at wordpress.com where it's managed by people who are (presumably) more experienced?

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

#60

Post by antihero »

chrisguitarguy wrote: post #39
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

Not sure if it's actually that helpful but might be nicer to serve up a 404, in the interest of opacity.

Simply giving the hacker less information (though not just depending on this) is a useful form of security. If you give them a 401, then they at least know that the file exists.

Post reply on HN