Last modified: 2011-03-13 18:05:55 UTC
This is not a catch all for security, however, most ISP's allow their users to have a .htaccess file... Most also have globals turned on.. but that is changing... anyway: including a .htaccess file like this one: ********* php_flag register_globals 0 <Files ".ht*"> deny from all </Files> ************* will protect quite a few people from any future register_globals security vulnerabilities and, you can also do a few things like, make the LocalSettings.php file not be read when php is out... by using code like this (works with apache2)... ************ <IfModule !sapi_apache2.c> <Files ~ '\.php$'> Order allow,deny Deny from all Allow from none </Files> <Files ~ '\.phps'> Order deny,allow Allow from all </Files> </IfModule> ************* you may have to edit it so that it works with other common php variable names... or just block the viewing of LocalSettings.php at all times...
Can you confirm that such an .htaccess will never cause the entire directory to become inaccessible with 403 errors due to trying to override settings that are not allowed to be overridden?
Can you confirm that such an .htaccess will never cause the entire directory to become inaccessible with 403 errors due to trying to override ... No, my if module !sapi line is dependant on the version of apache. because the apache2 module of php is called something different than the apache1 module.. which is different from the cgi??? But, the globals off, and the files .ht* .. I can confirm and a file setting for LocalSettings.php needs to be tested, because I don't know if php will be able to access the file even if the web browser can't.. I'm using apache2, and I can do a test case on that setting.. However, having a few of these other apache config options commented out! in the .htaccess could make it easier for sysadmins to say, implement mod-rewrite rules.. just by copying and pasting something that is already on the system.
*** Bug 2636 has been marked as a duplicate of this bug. ***
Granted ... Even if the MediaWiki PHP code is based upon internal "include" statements and not Apache sub-requests then adding a general .htaccess file with only Options -Indexes Will not stop anyone who knows the exact URI path to a php file trying out attacks on such files or other resources but it will stop raw directory structure from being displayed if there arent any of index.php, index.cgi, or other Default index page in such directory. After further thought this isnt a MediaWiki installation issue per se - it is a FAQ item that needs to be addressed before more new MediaWiki sysadmins and Apache webmasters start asking these types of questions: 1) Besides deleting config after the new install are there any other security considerations that should be addressed to help make "new site A" more secure? 2) What can be done on a Per-Directory basis to help control access and display of raw structure -- especially when the sysamdin may not have access to the primary httpd.conf files (as in my case where I host using CPanel and cannot access or change the primary Apache config files.) 3) Besides PHP issues are there Apache-related configuration concerns or issues surrounding Apache modules which should be addressed? Things like that. Not trying to be difficult ... just thnking out loud.
For a start see: http://meta.wikimedia.org/wiki/Documentation:Security
I'm going to WONTFIX this; have had too much trouble with .htaccess files cutting off entire directory trees because Apache is configured to reject them.
