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. 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 ( under the right scenario ):
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 in cookie names starting with: `s2member_` and/or `wordpress_`.
I don't personally care for mod_security ( I think it produces too many false positives, and too many headaches ). If configured properly, it can be useful. The problem is, it seldom is. That being 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 ( i.e. no HTML in query strings, no function/parameter names, no SQL keywords, etc ).
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.
Here are some basic instructions that may help some of you.
1. 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.
- Code: Select all
# 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>
( * please do this at your own risk though, research things for yourself! ) ( also see: this article )
Or see: http://sourceforge.net/apps/mediawiki/m ... RuleEngine
2. 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.
- Code: Select all
# Mod Security v2.x only.
# Will NOT work in .htaccess, use httpd.conf.
<IfModule mod_security2.c>
SecRuleRemoveById 960024 981173 981212 960032 960034
</IfModule>
( * please do this at your own risk though, research things for yourself! ) ( also see: this article )
Or see: http://sourceforge.net/apps/mediawiki/m ... RuleEngine
3. Or, 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. As 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 ? mark in the URL ), and point them to this thread. 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 ).
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.
We recommend MediaTemple® (gs): http://www.mediatemple.net/go/order/?re ... ks-inc.com
Other related articles:
How To Fix WordPress and Mod Security 2
MyBB ( Mod Security issues )
Handling Mod Security False Positives
Mod Security ( Documentation / Reference Manual )
Mod Security ( Quick Configuration Examples )
Mysterious 403/404 Errors ( Mod Security )
Nothing ever gets resolved that way. You see where I'm coming from?
