[Owasp-modsecurity-core-rule-set] rule bypass question

Ryan Barnett ryan.barnett at breach.com
Mon Nov 30 16:32:26 EST 2009

On Sunday 29 November 2009 10:41:56 am Chris Datfung wrote:
> I have the following in section H of an event that was a false positive:
> Message: Operator GT matched 1 at TX:arg_name_menu. [file
>  "/opt/modsecurity/etc/crs/base_rules/modsecurity_crs_40_generic_attacks.co
> nf"] [line "28"] [msg "Possible HTTP Parameter Pollution Attack: Multiple
>  Parameters with the same Name."] Message: Warning. Operator GE matched 5
>  at TX:anomaly_score. [file
>  "/opt/modsecurity/etc/crs/base_rules/modsecurity_crs_60_correlation.conf"]
>  [line "41"] [msg "Transactional Anomaly Score (score 20): Possible HTTP
>  Parameter Pollution Attack: Multiple Parameters with the same Name."]
>  Action: Intercepted (phase 2)
> Apache-Handler: proxy-server
> Stopwatch: 1259298234088338 14916 (181 11756 -)
> Producer: ModSecurity for Apache/2.5.11 (http://www.modsecurity.org/); core
>  ruleset/2.0.3.<http://2.0.3.> Server: Apache/2.2.14 (Unix) mod_ssl/2.2.14
>  OpenSSL/0.9.8l
> The rule at line 28 in modsecurity_crs_40_generic_attacks.conf does not
>  have a rule ID. The false positive appears in multiple parameters in the
>  /VulnScript.php script, so ideally, I'd like to add a SecRuleRemoveById
>  rule, which does not look like a possible in this case. I read the
>  examples in modsecurity_crs_48_local_exceptions.conf, but am still unclear
>  how to bypass this rule. Can someone point me in the right direction?
Hey Chris,
Please see my other email that I just sent to the list about the new CRS 
v2.0.4 as the HTTP Parameter Pollution rule now has a rule id.  With this 
info, you can now add the following example exception rule to the 48 local 
exceptions conf file -

SecRule REQUEST_FILENAME "@streq /VulnScript.php" 
SecRule TX:/^HPP-1.*ARGS:(foo|bar)/ "." "chain,setvar:tx.hpp-
        SecRule TX:'/^HPP-/' "^TX:(hpp.*ARGS:(foo|bar))$" "capture,setvar:!tx.

This exception will first check the URL and then it will check to see if there 
are any TX matches for http parameter pollution for either the foo or bar 
parameters (adjust these accordingly for your page where the false positives 
are occurring).  If matches are found, then it will both expire the TX 
variables and adjust the anomaly score.

Let me know if you need any more help.


More information about the Owasp-modsecurity-core-rule-set mailing list