Last modified: 2011-03-13 18:05:55 UTC

Wikimedia Bugzilla is closed!

Wikimedia migrated from Bugzilla to Phabricator. Bug reports are handled in Wikimedia Phabricator.
This static website is read-only and for historical purposes. It is not possible to log in and except for displaying bug reports and their history, links might be broken. See T2415, the corresponding Phabricator task for complete and up-to-date bug report information.
Bug 415 - include a .htaccess file to turn of globals and other safety measures, and commented out other apache.conf options
include a .htaccess file to turn of globals and other safety measures, and co...
Status: RESOLVED WONTFIX
Product: MediaWiki
Classification: Unclassified
Installer (Other open bugs)
unspecified
All All
: Lowest enhancement with 1 vote (vote)
: ---
Assigned To: Nobody - You can work on this!
:
: 2636 (view as bug list)
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2004-09-07 12:02 UTC by Aaron Peterson
Modified: 2011-03-13 18:05 UTC (History)
1 user (show)

See Also:
Web browser: ---
Mobile Platform: ---
Assignee Huggle Beta Tester: ---


Attachments

Description Aaron Peterson 2004-09-07 12:02:08 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...
Comment 1 Brion Vibber 2004-09-07 19:03:51 UTC
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?
Comment 2 Aaron Peterson 2004-09-07 23:35:42 UTC
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. 
 
 
Comment 3 Brion Vibber 2005-06-30 23:23:39 UTC
*** Bug 2636 has been marked as a duplicate of this bug. ***
Comment 4 Bill Jones 2005-07-01 08:07:51 UTC
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.
Comment 5 Brion Vibber 2005-07-01 08:17:52 UTC
For a start see:
http://meta.wikimedia.org/wiki/Documentation:Security
Comment 6 Brion Vibber 2005-12-04 08:31:07 UTC
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.

Note You need to log in before you can comment on or make changes to this bug.


Navigation
Links