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 might already have open_basedir set to only allow inclusion WITHIN the webroot.
Most packages like Wordpress are developed to run on the maximum number of servers. It isn't built to run on the best, or smartest configured ones—but the average, out-of-the-box Apache/PHP install.
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..."
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
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?
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;
}
This is a bit of a hack, since you don't really know how the "backup" file will look like. It might end with tilde, but it might end with .bkp. It's impossible to iterate through all the possibilities, just like it's impossible to separate them from valid files.
A much cleaner solution would be to separate "callable" entry-point files (like index.php) from "library" files into separate directories and point nginx/Apache only to the directory with callable files.
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.
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?
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.
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.
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.
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.
If you wanna see php done right, forget about all the crap you have seen and take a look at symfony.com. It has great docs, that focus on teaching web development (not just a framework) and all these sysadmin best practices like how to set the permissions, etc. Trust me, I have used every popular framework (including Rails and Django), and Symfony2 has nothing to envy.
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.
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.
I don't know what you mean. You just tell the web server what you want to do, and it will do it. Eg: "Process only files in this dir, and only accept requests to this kind of URL. And any request to that kind URL, pass it to this single php file".
Do software like XAMP have bad defaults and shouldn't be used for production out of the box? Maybe.
Has that helped a lot of people to get started, and make PHP the most popular server language for the web? Definitely.
Should we mock all php devs including experts, because of designers or ninja CEOs who tried/succeeded in editiing or making a website but made some mistakes in the process? The answer is still no.
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.
vim lets you choose where to put swp/backup files. Mine are always in ~/.vim/tmp. Avoids awkward issues with scripts that operate on the current directory recursively. And no, you cannot blame shitty security on a text editor.
(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.
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.)
Our tutor in my first year uni course taught us to put sensitive information into a folder outside the web path, and use relative paths to include the files where needed. There is absolutely zero reason these sensitive files should be accessible via URL.
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.
Why would they not have a config folder which uses .htaccess to protect everything inside? That would close this vulnerability without affecting convenience.
Yii places all config information (and any files that shouldn't be accessed by a visitor) in a folder called "protected" that is behind a "deny from all" .htaccess file. WordPress should consider something like that.
For the majority of users that use PHP: A lot of hosts now allow editing of php.ini which isn't accessible to the web (or else it's time to switch hosts).
This is another great reason to "keep config files out of web root." WordPress supports this, although it's not by default, and poorly documented, and even suggested it's not beneficial.
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...
"If the text editor crashes or the SSH connection drops during editing"
What about the time of editing? During that time, the temp files exist. Are they readably? I would guess so. So even if you just edit them and have to crash, you are vurnurable.
As a side note a lot of Wordpress sites do expose the wp-config-sample.php file. See for example the official Yahoo! Blog, The Wall Street Journal, Sony Blog, etc...:
> Thus, 230 / 216391 = 0.11% of all websites are vulnerable.
> Latest stats say that about 13.8% of the top 10,000 websites run CMSs. If we just focus on CMS-powered websites, then the percentage of vulnerable sites is much higher:
> Thus, 230 / (216391 * 0.138) = 0.77% of websites running a CMS are vulnerable.
I don't think those numbers mean what you think they mean.
13.8% out of 10,000 doesn't say much about the top 216,391. And perhaps 0 out of 230 of the vulnerable websites use CMS, however unlikely that is.
When I'm working with CodeIgniter (which ExpressionEngine is based off), I always rewrite access to subfolders of the project to the index.php file, because that's the only file that there needs to be access to for the site to function properly. This keeps anyone from accessing configuration (or any other) files.
This is not anything new and has been known for ages.
Assuming one follows the "defense-in-depth" approach, however, this is easily mitigated and becomes a non-issue.
FWIW, I could give you the username and password that my instances of WordPress use to connect to MySQL and you wouldn't be able to do anything with them.
Interesting security concern. It might be added that if one has several backup files, and has MultiviewsMatch enabled, the files aren't actually readable but get run instead. This is because multiple backups get numbered after a dot, while single backups and crashed files do not.
I have never thought about this, as I'm super paranoid about database credentials stored in any sort of config file (where it's wp-config.php, settings.php or any other language with frontfacing credentials).
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, see the comments below for other slick solutions.
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.
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.
Would also note that if php for some reason is turned off the server will send the actual config file wp-config.php as well as well as all those other files that are mentioned by the OP.
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.
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.
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 phpMyAdmin installed in a standard location on a given domain and not locked down well - for sites where this is the case this bug is very serious.
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 - for them this is a bigger problem as revealing the DB password also reveals the credentials needed to access other things (perhaps an SSH account with privileged access either directly or via sudo).
> 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.
> 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.
I think you should delete your comment. It's not helpful to hand out other peoples' passwords like that, regardless of how easy it might be to find them.
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.wikia.com/wiki/Remove_swap_and_backup_files_from_...