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...
including a .htaccess file like this one:
php_flag register_globals 0
deny from all
will protect quite a few people from any future register_globals security
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)...
<Files ~ '\.php$'>
Deny from all
Allow from none
<Files ~ '\.phps'>
Allow from all
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
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
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:
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.