On Fri, 12.03.2010 at 13:28:07 -0700, kj...@pintday.org <kj...@pintday.org> wrote: > > Very good suggestion, indeed.
-20 I'm impartial, though, as I don't use the default configuration, anyway. I think it's rather a non-issue. > > Especially, if someone has a 'dangerous' file, a PHP Shell for instance, > > (a perfect example: > > http://mgeisler.net/downloads/phpshell/phpshell-1.7.tar.gz) > > inside such a directory. (Or even maybe a simple file uploader, that will > > help the attacker to upload such 'shell-over-http' files.) > > Also, think "emacs-turdfile". Have any config.php~ lying around? > > or index.php~? > > Are you SURE? Yes, I am SURE. Reason: Whoever directly edits files in his or her web tree, is begging for trouble, anyway (imho), eg. resulting in famous websites telling me highly interesting stories like: "/var/www/some/stinking.php: could not contact mysql at bogusserver" (in the less-dangerous cases). I'd say that you generally need a 'development' server, no matter what, where you can have version control, build scripts etc.pp, and a Makefile that has an appropriate target for deployment, so you can go into your development area and say 'make' to put your latest version of anything online. Without cruft, recording a known (good?) state along the way, and a way to undo all of this, or prove to third parties that something was or was not online at some point in time. Having a development server can be as cheap as a virtual host with "different" access restrictions, which points to a different directory, out of reach for the regular web server, so there is really no reason for not having it. Btw, the case with emacs-turdfiles could also be solved by providing a suitable IndexIgnore statement in the configuration. Kind regards, --Toni++
