[Owasp-modsecurity-core-rule-set] 981242 SQL Injection detection false positives?
RBarnett at trustwave.com
Thu Aug 18 09:40:06 EDT 2011
On 8/18/11 1:15 AM, "Paul McGarry" <paul at paulmcgarry.com> wrote:
>Thanks for the feedback.
>On Wed, Aug 17, 2011 at 10:36 PM, Ryan Barnett <RBarnett at trustwave.com>
>> Thanks for the feedback Paul. FYI - you can review some of the
>> For the specific rule you mentioned - 981242 - this is a converted
>Incidently there seems to be a double usage of that ID (and others
>near it, 981231-981246 actually) in
I will fix these, thanks.
>> rule. You can review example test payloads that they use here -
>> nitorTest.php. Look for the public function testSQLIList() sections.
>I think previously I have ended up disabling many the PHP-IDS based
>rules because of the false positives.
>Is there some difference between how PHP-IDS executes the rules and
>how modsecurity treats them?
>I note that if I put:
>a_a_axoraaaaaa at aaaaa.com
>in the box on
>it poses no problem
>Message: Warning. Pattern match
>at ARGS:email. [file
>[line "52"] [id "981212"] [rev "2.2.1"] [msg "SQL Injection Attack:
>SQL Operator Detected"] [data "xor"] [severity "CRITICAL"] [tag
>"WEB_ATTACK/SQL_INJECTION"] [tag "WASCTC/WASC-19"] [tag
>"OWASP_TOP_10/A1"] [tag "OWASP_AppSensor/CIE1"] [tag "PCI/6.5.2"]
>3 Orchard Street
>on the PHP_IDS demo is fine and
>gives me warnings (981248 on "3 Or" and 981242 on "3 Orc")
The rule that triggered is not a converted PHPIDS rule but rather one that
we developed as part of the SQL Injection Challenge analysis. This
particular rule is trying to identify common SQL Operators. Examples here
1#Operators_671486718712981_8325. We tried to lessen false positives by
not triggering only on common keywords like "AND" or "IS".
>Ironically the rules seem to cause the most problems in places where
>they might be most useful, ie where the user is actually entitled to
>enter 'free text' and validation will more likely be looser than on
>fields containing more defined parameters. (The anomoly score tends to
>get ramped up too, such as when there is an email and an email_confirm
>field on the same page or the street name appears twice in a
>submission as part of both the cardholder info and shipping address.)
Interestingly, the reverse seems to be true :) I posed a similar theory
internally at SpiderLabs and based on analysis of customer engagements
(from our Global Security Report - https://www.trustwave.com/GSR) totaling
more than 220 forensic investigations and more than 2300 pentests - we
found that free-text form fields are the least likely to have SQL
Injection related vulnerabilities. Parameter types other than free-text
(numeric, drop-down lists, hidden fields, buttons, etc...) are far more
likely to have injection-type flaws as Devs wrongly assume that clients
will not (or can not) manipulate them.
>I do not believe the stuff I work on is vulnerable to SQL injection
>but we all know about defence in depth. It would be nice to have as
>much turned on as possible on (for example) a page collecting credit
>card info but some of the rules seem too loose to be usable in
>practice with real world input the forms should be able to receive.
This transmission may contain information that is privileged, confidential, and/or exempt from disclosure under applicable law. If you are not the intended recipient, you are hereby notified that any disclosure, copying, distribution, or use of the information contained herein (including any reliance thereon) is STRICTLY PROHIBITED. If you received this transmission in error, please immediately contact the sender and destroy the material in its entirety, whether in electronic or hard copy format.
More information about the Owasp-modsecurity-core-rule-set