Page MenuHomePhabricator

include a .htaccess file to turn of globals and other safety measures, and commented out other apache.conf options
Closed, DeclinedPublic

Description

Author: alpeterson

Description:
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...


Version: unspecified
Severity: enhancement

Details

Reference
bz415

Event Timeline

bzimport raised the priority of this task from to Lowest.Nov 21 2014, 6:53 PM
bzimport set Reference to bz415.
bzimport added a subscriber: Unknown Object (MLST).

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?

alpeterson wrote:

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. ***

mw-bugs wrote:

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?

  1. 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.)

  1. 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.

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.