WordPress – 404 after Saving a Post


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?

Good question.

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

Alternative One

<IfModule mod_security.c>
SecFilterEngine Off
SecFilterPost Off

Alternative Two

<IfModule mod_env.c>

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.

This type of rule will be in place to stop cross-site javascript injection attacks. It is most likely the result of a sloppy custom rule generation.

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.

Tags: , , , ,

Looks like there is no conversation here yet, why not start one.