HTTP Error – WordPress Flash Uploader

We recently moved our website to a VPS (Virtual Private Server) running 64-Bit CentOS, WHM, cPanel, Apache 2.2, PHP 5.3, and My SQL 5.x,  We figured we could get better performance and greater control out of running our own hosted web environment and the VPS seemed like the best fit at the time. At present, we can’t justify the cost of a full blown dedicated server but hope to soon! Anyway, overall our move went better than expected with no major problems. However, one error that we noticed that occurred repeatedly when we tried to use the Flash Uploader in WordPress, was the dreaded HTTP Error. (click bottom of image for larger view)

WP Flash Uploader HTTP Error

Flash Uploader in WordPress HTTP Error

I call this HTTP Error the dreaded error, because after researching for hours, trying all the various suggested fixes, and having nothing work consistently we finally stumbled upon a website that provided us with enough information to correct the problem. It took us hours to locate the solution so we decided that we would post it here in our Tools, Tips, & Tricks section our the NetworkCEO website in hopes that it makes it easier for the next person looking to resolve this issue.

First of all, let me point out that this error IS RELATED to the MOD_SECURITY module within Apache. In earlier versions of WordPress, it was a bug, but it was fixed back in version 2.8. So if you are seeing this error in a later version of WordPress (we are running 3.2.1) it is most likely related to your Apache web server incorporating the MOD_SECURITY module. In order to fix the issue you need to determine if you have mod_security or mod_security2 installed because the resolution for each of these modules is quite different.

MOD_SECURITY is an open source web application firewall that is installed as a module for Apache-based web servers. There are two widely used versions of the mod_security module, the first release of mod_security was just plain mod_security, the latest release is referred to as mod_security2. At the time of this post the latest release of mod_security is MODSecurity 2.6.

What Causes the HTTP Error

As I mentioned, we are running CentOS 5.7 with WHM and cPanel so the examples you see here are based on that configuration. However, you should be able to apply our suggestions to your own environment if you have an understanding of your server operating system and the location of the server files for Apache and Mod_Security.

The HTTP Error is caused by mod_security because there is a security rule in mod_security that is triggered by the WordPress Flash Uploader. This security rule is meant to stop known security flaws in Flash that have been exploited to inject code into your website. You can see this security rule trigger a message in your mod_security logs in WHM when you try to upload a file using the Flash Uploader. The message we were receiving was the following;

Access denied with code 406 (phase 2). Pattern match "^Shockwave Flash" at REQUEST_HEADERS:User-Agent. [file "/usr/local/apache/conf/modsec2.user.conf"] [line "203"]

Your message may be different based upon the version of mod_security you have installed. As you can see from our message, it clearly states that the rule triggered by the pattern match was in the modsec2.user.conf file which helped us to determine that we had mod_security2 installed.

You will want to determine the mod_security that you have installed and then apply the fix defined in the appropriate section below.

MOD_SECURITY

If you have the earlier version of mod_security installed, then it’s a little easier to fix the HTTP Error for the Flash Uploader because your changes can all be incorporated in the .htaccess file in your root directory. This is one of the most confusing aspects of the fixes we found on the internet because not too many websites distinguished the fixes between mod_security and mod_security2.

For mod_security you just need to disable this rule for the async-upload.php file in your .htaccess file. You can do this by inserting the following directive into your .htaccess file in the root of your website.

<IfModule mod_security.c>
<Files async-upload.php>
SecFilterEngine Off
SecFilterScanPOST Off
</Files> </IfModule>

Now when you use the WordPress Flash Uploader this mod_security rule will not be triggered. The Flash Uploader uses the page async-upload.php and by the above directive the security filter and scanning have been turned off for that one page.

It’s important to point out that you do not want to disable mod_security for your entire website! We found numerous posts on the internet that defined the above directive without the Files specification. DON’T DO THIS! You will open your website up to all type of vulnerability because you will completely disable mod_security.

Once you have made these changes to your .htaccess file and saved the changes, your Flash Uploader should now work, as changes made to the .htaccess file are immediate.

MOD_SECURITY2

If you are running mod_security2 then the .htaccess changes will not work!

Mod_security2 does not allow changes to it’s security rules via the .htaccess file. The only way you can make changes is through a file called /usr/local/apache/conf/modsec2/custom.conf. This is an important difference between mod_security and mod_security2 and one that I am sure has caused many web site owners a lot of anguish and grief.

To fix this error, if you are running mod_security2, requires a 2 Step process;

Step 1 –

A) In WHM, open your MOD_Security log under Plugins/Mod Security.

B) At the top of the page you will see an “Edit Config” button. Click it and open the Mod Sec2 Rules.

C) Scroll down until you find the following entry under #Spam Bots –

SecRule HTTP_User-Agent  "^Shockwave Flash"

D) We need to change this entry to add an ID so that we can reference it in our mod_security override later. Copy this rule to a new line, comment out the old rule and add the following –

#SecRule HTTP_User-Agent  "^Shockwave Flash"
SecRule HTTP_User-Agent  "^Shockwave Flash" "id:xxxxxxxxxx"

Replace “xxxxxxxxxx” with an arbitrary number to be used as the ID for this rule. It doesn’t matter what the number is, but you will need to remember it for Step 2(C) in these instructions.

E) Scroll back to the top of the Modsec2 Rules and ensure that the 2 lines below are uncommented in your Modsec2 file. The lines should appear as below;

## whitelist ##
Include "/usr/local/apache/conf/modsec2/whitelist.conf"
Include "/usr/local/apache/conf/modsec2/custom.conf"

We will be making changes to the custom.conf file in Step 2 and we want to ensure that our changes are included in the ModSec2 Rules.

F) Save this file by clicking on the “Save Configuration” button at the bottom of the page.

Step 2 –

A) Now open a SSH connection to your server using your favorite SSH Client. We used Putty for our purposes.

B) CD over to /usr/local/apache/conf/modsec2/

C) Using vi, modify the file custom.conf as follows; (click bottom of image to enlarge);

ModSec2 Custom Changes

ModSec2 Custom Changes

 The file should contain the following;

<locationMatch "/wp-admin/async-upload.php">
SecRuleRemoveById xxxxxxxxxx
</LocationMatch>

There may already be other entries in this file. If so, just add this entry to the bottom of this file and save it.

Again, it is important that you replace the “xxxxxxxxxx” with an arbitrary number that you selected in Step 1(D) above. This number is an arbitrary ID that we assigned and use to identify the Mod_sec2 security role that we want to override.

D) Reboot your server for the changes that you made to take effect.

Once your server comes back on-line from your reboot, test your changes by uploading a file to your WordPress site via the Flash Uploader. If you followed all of the steps correctly your file should now upload fine without the Dreaded HTTP Error!

Leave a Reply