5 ms·
You seem to imply this is a novel attack vector. But it's really just an instance of a very old mistake: Don't use the root of your app as document root! It's
by vog 11y ago
You seem to imply this is a novel attack vector. But it's really just an instance of a very old mistake:
Don't use the root of your app as document root!
It's really as simple as that. Almost all modern apps have a subdirectory "public/" or similar. That one is meant to be used as document root. You only have to ensure there are no sensitive files in there.
If you fail to introduce such a directory, you'll have a game of cat-and-mouse, where you have to add extra webserver rules for each sensitive file: VCS, crypto secrets, private keys, and so on. In that setup it's easy and very likely to forget one. Of course, this then creates the feeling of "How can anybody keep track of this never ending list of security details?"
In the end, this is a blacklist vs. whitelist thing. Like with your firewall, you want one rule that blocks everything and allows only specific stuff. The alternative is to allow for everything, have rules to deny all sensitive stuff, and finally get in trouble for having forgotten one rule (e.g. probably because an additional service was introduced after the firewall rules have been written.)
- juliangregorian 11y agoGreat point. How much do you want to bet most of these are PHP, where it takes special discipline not to make your top directory web-accessible?
- TazeTSchnitzel 11y agoDoes it? If you're on a shared host with just the one directory, maybe. But if you are configuring your own server, you still point it to htdocs and keep the config below it.
- pmx 11y agoIt takes very little effort in php. You simply have your index.php and any public assets in the document root and then use index.php as a bootstrap to bring up your application. Everything else goes outside of the document root.
- deleted 11y ago[deleted]
- deleted 11y ago[deleted]
- vog 11y agoYet, almost all well-known PHP applications don't have a public directory. And almost all non-PHP webapplications do have a public directory (e.g. practically all Python/Django and Ruby/Rails projects). So the connection to PHP is apparent till today, although it may have to do more with crappy super-cheap hosting providers than with the language itself.
- leftnode 11y agoVery simple setup. You have: .git web/index.php src/*.php Make the document root /full/path/to/web/index.php. Edit: Also use a deployment tool like Capistrano which removes the .git directory as well.
- vog 11y agoYes, it is easily avoided. But it is still violated by lots of PHP projects, including well-known projects with large userbases: * Wordpress * Tiki * ... and so on. I don't think this is by accident: This technique is too old and well-known to be ignored by large projects. Rather, they conciously don't do that to cause less hassle for the occasional admin: Those can simply dump it into some directory and don't have to setup a proper docroot or anything. And extra work for those who want a more secure setup. This is clearly a usability versus security issue, resolved in the unfortunate, usual way.
- jbeales 11y agoI don't have insight into the decision-making at WordPress, but they probably do this because they want to be compatible with as many web hosts as possible, and so many super-cheap shared hosts just give you a public directory that you're supposed to dump everything in. It's possible to set it up properly on most of these hosts, but it's much more difficult, and if you ever have issues the support team says you're using a "non-supported configuration." At least WordPress lets you move your config file one level above the webroot and will find it automatically.
- juliangregorian 11y agoDrupal, MediaWiki, Laravel, Slim, it's a pretty long list, and it includes projects that target Serious Devlopers.
- vog 11y agoAlso, this is really PHP specific. Look at any larger Python (Django/Flask/...) or Ruby (Rails/...) project, and you will always find a proper "public" directory, although it may be named differently. Not sure about Perl though ...