MediaWiki and ModSecurity

We were seeing 500 Internal Server Errors:

The server encountered an internal error or misconfiguration and was unable to complete your request.
Please contact the server administrator, webmaster@xsquawkbox.net and inform them of the time the error occurred, and anything you might have done that may have caused the error.
More information about this error may be available in the server error log.

My host finally figured out what was going wrong. This was in /www/logs/error_log:

Wed Nov 10 12:48:15 2010] [error] [client 71.248.161.106] ModSecurity: Access denied with code 500 (phase 2). Pattern match "(insert[[:space:]]+into.+values|select.*from.+[a-z|A-Z|0-9]|select.+from|bulk[[:space:]]+insert|union.+select|convert.+\\(.*from)" at ARGS:wpTextbox1. [file "/usr/local/apache/conf/modsec2.user.conf"] [line "355"] [id "300016"] [rev "2"] [msg "Generic SQL injection protection"] [severity "CRITICAL"] [hostname "www.xsquawkbox.net"] [uri "/xpsdk/mediawiki/index.php"] [unique_id "TNra30PhuxAAAE8SUkMAAAAQ"]

Whoa. What is that? The server has ModSecurity installed, including a bunch of rules (as defined by regular expressions) designed to reject, um, bad stuff. The rule seems to come from here and MediaWiki isn't the only program that it can hose.

If you pull apart the regular expression, you can see how things go wrong. Loosely speaking the rule matches text in this form:

insert ___ into ___ values|select ___ from ___ from ___ insert|union ___ select|convert

where the blanks can be anything, can pipe indicates that either word is acceptable. So...insert, into, values, from, form, insert, convert. Those words appear in that sequence of comments in my OpenAL sample. And frankly, it's not a very remarkable sequence, hence it matching this.

So I thought the problem was long posts, but it wasn't. The longer the post, the more likely that a particular sequence of words would show up.

From what I can tell, white-listing URLs from the rule is the "standard" fix.

mod_rewrite for MediaWiki

In moving the X-Plane SDK Wiki to MediaWiki I had to use mod_rewrite. Getting this right took me a few tries.  This is what I ended up with:
# First: any old phpwiki witih a query is rewritten to the
# "clean" mediawiki URL. Note that we do not test for file
# existence - as of this writing the php index.php DOES exist.

RewriteCond %{QUERY_STRING} ^(.+)$
RewriteRule ^xpsdk/phpwiki/(.*)$ /xpsdk/mediawiki/%1? [R=301]

# Also, if we did not rewrite that means we had no query -
# means the default page - map it to the base root.

RewriteRule ^xpsdk/phpwiki/(.*)$ /xpsdk/mediawiki/ [R=301]

# Now we have "clean" wiki URLs, so do not make any more rewrites
# permanent. What we do next is to clean up problems.

# And finally and most importantly: because php is running in a CGI,
# it needs the "ugly" title=$1 form. So...convert the virtual path
# into CGI access.

RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule ^xpsdk/mediawiki/(.+)$ /xpsdk/mediawiki/index.php?title=$1 [L,QSA]Probably the most useful thing I discovered was: by using R=301 you can force the rewrite to be visible in the URL bar. This isn't always what you want in the long term, but it does let you see the output of mod_rewrite, which is handy.

Skinning MedaWiki

We use MediaWiki for the X-Plane Wiki, which is meant to be a collection of online documentation for tech support, third party editing, etc.

After pinging some users on my blog, the consensus seemed to be that while some people liked the interactivity of a Wiki, the usability of the site wasn't as good as "normal" doc websites (e.g. made with HTML, php, and some CSS).  I can see why they said that - the regular Wiki monobook has a lot of navigation space dedicated to "wiki-like" activities (e.g. editing and maintaining) and very little dedicated to search and navigation.

After looking at my own php rolled for the scenery site and MediaWiki, it became clear that it would be easier to make MediaWiki pretty than to make my php interactive.  So I built a new skin.  This is what I learned (the hard way):

• In hindsight, using Monobook as a starting point was really, really stupid.  My goal was a very different layout from MonoBook, so I probably could have saved time by starting with a simpler skin.
• On the other hand, MonoBook's php does output layout elements in a relatively clear way, so if you need to move things around on screen by changing the document hierarchy (as opposed to using a ton of CSS) it might be easier to start with MonoBook and move sections around.
• Probably the smartest thing I could have done would have been to delete the whole style sheet and define every DIV block as having a border, padding and margin, so I could visualize the document layout.  What I did instead (slowly beat the style sheet into submission) took a lot longer.

Here are the old and new layouts.  The main ideas were:

• Eliminate the side bar.  Important side bar items like search and the wiki name go up top; less important side bar items go to the bottom.
• Use less styling - monobook has a ton of horizontal rules and borders all over the place. X-Plane Wiki content is often complex enough that readers don't need eye distractions. Most of the page is dedicated to document content.
• Category breadcrumbs are enabled, and moved to the top, with much smaller style-sheet elements.  This provides "hierarchical" navigation (assuming the Wiki's category system is maintained).

The next step will be to redo the main portal pages (particularly main_page, which was never properly built) to give users a clear idea of where they need to go.