Does WordPress contain “default” anti-SQL injection code that responds with a 404 error?

As suggested by @Jeff Mattson, hours of research and testing suggest that this is probably due to mod_security. I also investigated the likelihood of it being due to Suhosin, but I don’t think it’s to blame.

Here’s the deal. It doesn’t really help if we verify that the problem is due to mod_security. We don’t control the servers that run our plugin and our efforts to disable mod_security via .htaccess have failed.

Fortunately, there’s light at the end of the tunnel. Regardless of what is causing the problem, a fix that is nearly guaranteed to fix the problem is to simply modify our POST data.

The solution I plan to implement is to Base62 encode the data that we’re sending to our plugin. Base64 would probably work as well, but I’d like to solve this problem once and for all, and due to its limited character set, Base62 is the safer bet when dealing with a neurotic beast like mod_security.

This should work because mod_security looks for certain “trouble” strings in submitted data. I doubt the module is sophisticated enough to attempt applying a bunch of different encodings to submitted data (plus, doing so would adversely affect performance), so this is nearly guaranteed to fix our problems.

Yay!

Leave a Comment