August | 2011 | s2Member Membership Plugin for WordPress

Mod Security, 503 403 errors

Regarding mysterious 503/403 (access denied) errors associated with mod_security (Mod Security).

We've just taken a closer look at some of the most popular configurations for mod_security, such as the default ruleset that many hosts use from this source: https://www.owasp.org/index.php/Category:OWASP_ModSecurity_Core_Rule_Set_Project

Unfortunately, there are MANY mod_security rules that can produce false positive results, and we've also found that each host runs with a little bit different combination of rules, based on what they consider to be most important to their clients; and perhaps tailored to the most common software applications they host for their clients.

In short, there's really no way for s2Member to work around everything mod_security looks at, from one host to another.

If you're running mod_security, and you plan to continue to run it, you may need your hosting company or sysadmin to tweak things for the applications that you run, by removing paranoid rules from your mod_security configuration.

For instance, in the Core Rule Set Project, we've found several rules that would negatively impact even a default WordPress installation, even counting points against cookies set by the core WordPress framework. Anyway, you get the picture, paranoid!

Known Problematic Areas In s2Member

URL: http://example.com/?s2member_register=[encrypted data string appears here]
URL: http://example.com/?s2member_sp_access=[encrypted data string appears here]
URL: http://example.com/?s2member_paypal_notify=[followed by GET/POST data from PayPal]
URL: http://example.com/?s2member_paypal_return=[followed by GET/POST data from PayPal]

For that matter, any URL that contains ?s2member_ and/or ?s2member_pro_ could be considered suspect under a paranoid mod_security configuration.

Also some cookie data stored under cookie names starting with: s2member_ and/or wordpress_.

mod_security produces too many false positives, and too many headaches. If configured properly, it can be useful. The problem is, it seldom is. That been said, I do understand that many hosts use this as a way to further protect the integrity of their servers.

Given the degree of complexity associated with heuristic rule sets for mod_security, all we can do with s2Member is follow "best practices" about what data we include in GET/POST/COOKIE/HEADER data (e.g. no HTML in query strings, no function/parameter names, no SQL keywords). http://stackoverflow.com/questions/3024123/how-to-write-mod-security-friendly-php-code

Beyond that, if you are still experiencing what are seemingly random 403 errors (possibly associated with cookies, headers, query string variables, etc), please follow the instructions below.

Dedicated Server

Try adding SecFilterEngine Off and SecFilterScanPOST Off to an .htaccess file in the web root. Many hosts allow this to be disabled on a user basis. Some users are allowed to do this by default on WHM/cPanel-based servers.

If you run your own dedicated server, and you want to save yourself headaches associated with mod_security, you can disable it inside your httpd.conf file with something like this.

# Mod Security v1.x.
# May work in .htaccess too, on some hosts.
<IfModule mod_security.c>
	SecFilterEngine Off
	SecFilterScanPOST Off
</IfModule>

# Mod Security v2.x.
# Will NOT work in .htaccess, use httpd.conf.
<IfModule mod_security2.c>
	SecRuleEngine Off
</IfModule>

This solution is a tradeoff: security vs usability. Do this solution at your own risk, research things for yourself! See also:
http://wordpress.org/support/topic/disable-mod-security
https://github.com/SpiderLabs/ModSecurity/wiki/Reference-Manual#SecRuleEngine

Or, if you run your own dedicated server and you want to keep mod_security, but remove certain rules that are getting in your way (i.e. rules causing a problem for s2Member, and/or other applications you run).

First, check your Apache error.log file for Mod Security errors, and look for the rule ID associated with each of them. Then remove rule IDs that are causing problems in your httpd.conf file.

# Mod Security v2.x only.
# Will NOT work in .htaccess, use httpd.conf.
<IfModule mod_security2.c>
	SecRuleRemoveById 960024 981173 981212 960032 960034
</IfModule>

Again a tradeoff: security vs usability. And again, do this at your own risk.

Shared Hosting

If you're on shared/managed hosting, ask your hosting company to disable mod_security for you. Or, ask them to whitelist the s2Member application, by disabling mod_security for URLs that contain ?s2member_ in their query string, or are otherwise associated with your WordPress installation.

Yet another alternative, ask them to whitelist specific URLs that are causing problems for you. Hosts that run mod_security are familiar with these requests, because mod_security is so very picky.

All you need to do is provide your host with the full URL that is failing (including any query string variables that appear after the question mark in the URL), and point them to this article.

Or just ask them to back down on the paranoia a bit overall with respect to mod_security and/or the PHP Suhosin extension, which is yet another paranoid module (under certain configurations, that is). http://www.hardened-php.net/

If you continue to have trouble, consider using a host that does NOT use mod_security, or one that has a good flexible configuration; one which does not inhibit the functionality of trusted PHP applications and plugins for WordPress.

Some hosts that just recently started using mod_security, or have recently upgraded to mod_security v2.x, may still need time to work the kinks out of their default configuration. Try to be patient with your hosting company, but don't hang around forever waiting for a miracle either.

Other related articles:
- http://www.binarymoon.co.uk/2011/05/wordpress-mod-security-2/
- http://docs.mybb.com/1.6/Help-Mod-security/#Known_problematic_pages
- http://blog.modsecurity.org/2007/02/handling-false.html
- https://github.com/SpiderLabs/ModSecurity/wiki/Reference-Manual
- http://web.archive.org/web/20110623183531/http://abing.gotdns.com/posts/2006/wordpress-error-404-when-publishing-or-saving-post/