1% of CMS-Powered Sites Expose Their Database Passwords (2011) • Hacker News Board

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

#91

Post by kysol » Tue, Feb 05, 2013, 5:44 AM UTC

astrodust wrote: post #83

trebor wrote: post #67

Earlier quoted context omitted.

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

The PHP ecosystem has some really awful defaults which is why it's developed such a bad name for itself. It may be that many of these are there to accommodate misconfigured web hosts, but this behavior has a way of self-perpetuating. Example: PHP 5.5 will be running for the next billion years because when mysql_query is finally put to rest in newer versions all those applications that depend on it will fall over. Thu…

Actually, it comes back to the user, not so much the coder. After I left a job a while back they hired some random as a replacement. The replacement had no Linux experience, so the next best thing for them was to tell the owner to move all software to a shared host (which they had had experience with before).

Everything was written below a public root, but the shared host didn't allow this, so the next thing you saw was: domain.com/publicroot/index.php^ when the new developer took over. The funniest thing was that they had internal subdomains which ended up public as well, one with full customer listings.

"Never attribute to malice that which is adequately explained by stupidity." - Hanlon's Razor

^ fake path

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

#92

Post by javipas » Tue, Feb 05, 2013, 9:40 AM UTC

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

Thx, I'll try that.

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

#93

Post by calinet6 » Tue, Feb 05, 2013, 5:29 PM UTC

im3w1l wrote: post #74

calinet6 wrote: post #73

Lol. That's just called statistics. I bet you 1% of every web site or server in existence does something so blatantly and unthinkably wrong that it would make any sysadmins eyes pop out of his head. 1% is in fact extremely low in my opinion—my guess would be closer to 10-15% of sites have some glaring security hole. The only important thing is to not let it be your site.

Or a site holding data of yours, which is harder.

Exactly. This is why you use different passwords for every site.

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

#94

Post by damncabbage » Tue, Feb 05, 2013, 11:05 PM UTC

sirclueless wrote: post #38

damncabbage wrote: post #14

Earlier quoted context omitted.

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

You're right; on reflection, version control has nothing to do with it (besides a .gitignore with wp-config-anything ignore entries). I used to use a wp-config.php file in a shared directory on the server that gets symlinked in by Capistrano during deployments; there's no way to accidentally create new .swo/.bkp/.whatever files in production without both screwing up the Capistrano recipe and wp-config.php file creation.

(It seems I skipped actually writing something useful and went straight to durr version control, sorry.)

Points A) and C) are dead on. Addressing your point B), though:

Yes, it is commodity software. But most seem to use at least some plugins and themes, and making changes to those without a rollback is a nightmare. You can make backups before changing things, sure, but version control has that already built in.

(Sibling posts to yours point out that Wordpress looks in both the docroot and one level up for wp-config.php - if I ever manage a Wordpress site again I'll be sure to move it out.)