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

81–90 of 94 posts

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

#81

Post by emillon »

mauvehaus wrote: post #50
emillon wrote: post #49

Earlier quoted context omitted.

Technically, your solution does not work with files whose name contain a space or newline. A working solution is either to do '-print0' in find and '-0' in xargs, or to just use '-delete' instead of the -exec. It is also possible to use '+' instead of ';' with '-exec' to say "fork as few times as possible", ie pack the largest list of arguments to rm you can. But '-delete', when supported, won't even fork/exec.

Are these GNU find extensions? I spend a lot of time on solaris, and I don't remember seeing a delete option. Thanks for the tips though!

You're right, -delete is not standard, but I think that + and -print0 are.

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

#82

Post by jasonlotito »

antihero wrote: post #59
shakesbeard wrote: post #24

Earlier quoted context omitted.

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?

There could be many reasons, not the least of which is that the hosting provider would be providing the installation and updates for the user.

So, they are paying for it by people who are presumably more experienced.

Edit: Just to be clear, I'm not excusing any of the mistakes. Just pointing out how normal people could get screwed over, even if they are using a "professional service" and paying for it.

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

#83

Post by astrodust »

trebor wrote: post #67
astrodust wrote: post #65

Earlier quoted context omitted.

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 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. Thus, a legacy version of PHP will be supported by hosts, bugs, security holes and all.

"You either die a hero, or live long enough to see yourself become the villain..."

PHP crossed the line from hero long ago.

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

#84

Post by astrodust »

brendoncrawford wrote: post #78
sequoia wrote: 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…

4. Don't make live edits on your production server.

5. FTP is not a deployment tool.

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

#85

Post by dsl »

antihero wrote: post #57
killahpriest wrote: post #53

Earlier quoted context omitted.

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.

But things inside public_html can't read files outside of it. I believe cPanel is configured this way be default.

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

#86

Post by [deleted] »

sequoia wrote: 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…

[deleted]

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

#87

Post by stcredzero »

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.

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

I wonder what the percentages are for cops, doctors, judges, and pilots are?

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

#88

Post by stcredzero »

dspillett wrote: post #64
level09 wrote: 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…

> 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

That should immediately mark them as a Dunning-Krueger victim/hack and you should get someone else. If you're not using something equivalent to a password vault or something equivalent, you're not as security savvy as you think you are.

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

#89

Post by Ergomane »

dspillett wrote: post #64
level09 wrote: 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…

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

That depends on the contents of the file in question. Example: An attacker can forge hmacs if the config file contains the signing key.

Post reply on HN