Well like most people I upgraded WordPress 2.7 in December 2008. Everything appeared to be going well, no major issues. Mind you I have been quiet on this blog over the last month or so.
Anyway went to save a post with an externally sourced image in it the other day, and the post failed to update, returning me instead to the standard 404 error page. Which is strange as it had saved okay minutes before. The only difference being the newly inserted image code.
So I did a bit of a search and it appears that there has been an ongoing issue with the ModSecurity module that is used by some hosts, which is not part of the WordPress install . It also appears that this 404 on a post save issue has been around for a while.
So what is this ModSecurity thingie?
ModSecurity is a code module for open source web servers that acts like a firewall. It works via providing protection from a range of attacks against web applications on the web server (such as WordPress).
Well that is certainly something that you want to keep operating on your site, as it protects from cross-site request forgeries, script injection, automated attacks, block information disclosure issues and much more.
A Solution Maybe
It has been suggested all over the place that maybe it’s a good idea to just disable the ModSecurity for that application which you are having a problem. You do this via inserting one of the following into your .htaccess file
<IfModule mod_security.c> SecFilterEngine Off SecFilterPost Off </IfModule>
<IfModule mod_env.c> SetEnv MODSEC_ENABLE Off PassEnv MODSEC_ENABLE </IfModule>
This is Not a Good Idea
ModSecurity is there for a reason, disabling it is like removing all your house locks because one sticks from time to time.
It would be better to fix the issue with ModSecurity, as that is the source of the problem here.
ModSecurity works via comparing the text you are saving or processing to a list of positive and negative outcome rules. If part of your processed text, my blog post in this case, matches a rule, instead of letting it proceed as normal, it will resolved to the designated alternative action, a 404 page in this case.
A Real Solution
So what we need to do is work out what is tripping up the ModSecurity.
I was lucky I knew it was just the image html code. So after a bit of an elimination I have determined that there must be a rule on my host that stops the source code “src=http:”. This also means that I can’t use the built in media insert functionality within WordPress as that generates code with the offending string in it.
The real solution in this case, is to get the host to remove or amend the rule to one that allows for the detection of the <script> tag as well as the offending src linking code.