Difference between revisions of "Configure wiki security"

From Organic Design wiki
(Basic security testing)
(See also: Load testing)
Line 61: Line 61:
 
== See also ==
 
== See also ==
 
*[[Tune a Production Mediwiki using APC Cache]]
 
*[[Tune a Production Mediwiki using APC Cache]]
 +
*[[Load testing]]
 
[[Category:MediaWiki]]
 
[[Category:MediaWiki]]

Revision as of 21:26, 3 March 2012

Procedure.svg Configure wiki security
Organic Design procedure

Error reporting

Error details should only be sent to sysops. A plain error message should be presented to all other users. The following can be added to LocalSettings.php to set this up. This snippet refers to an error.php file such as this one.

{{{1}}}

Protecting files

MediaWiki has a script called img_auth.php which is used to allow files to be protected. Requests to the image files are made via the img_auth.php script instead of into the image file structure, and the files are stored outside of web-accessible space. More information about the configuration can be found at MW:Manual:Image Authorization.

The setup is quite simple and just involves setting $wgUploadDirectory to the internal absolute location of the images, and $wgUploadPath to the external location of the img_auth.php script.

Unfortunately this method seems to have a problem with Friendly URL's, I had to patch the img_auth.php script so that the title part of the PATH_INFO would be extracted properly.

^.+/img_auth.php

Apache configuration

The rewrite rules are much simpler when using the above file protection technique because thumbnails and full images are treated the same way and are covered by the rule that handles normal script access within the /wiki directory. Also some additional directory rules should be added to restrict file-browsing.

RewriteEngine On

RewriteCond %{REQUEST_URI} ^/wiki/
RewriteRule (.*) $1 [L]

RewriteRule (.*) /wiki/index.php$1 [L]

<Directory />
    AllowOverride None
    Order Deny,Allow
    Options All -Indexes
</Directory>

Basic security testing

Most test-suites for testing web-application security are very extensive and time-consuming to set up, configure and run. So for those of us who don't really specialise in security but need a quick way to test that our sites are reasonably water-tight, the Zaproxy is pretty good. It runs on all platforms and installs an HTTP proxy server that you connect your browser through. I don't think the basic free package can do HTTPS connections so you may have to temporarily disable HTTPS on your site during testing.

Once you have it running (on Ubuntu, just download, unpack and run zap.sh from the desktop. Lanuch your browser and connect through Zap (on localhost:8080 by default). You can then go to your web-site in the browser to give Zap the address, then start the test in Zap from its toolbar - easy as that!

See also