On 8/18/11 1:15 AM, "Paul McGarry" <p...@paulmcgarry.com> wrote:
>Thanks for the feedback. > >On Wed, Aug 17, 2011 at 10:36 PM, Ryan Barnett <rbarn...@trustwave.com> >wrote: >> Thanks for the feedback Paul. FYI - you can review some of the >>reference > >> For the specific rule you mentioned - 981242 - this is a converted >>phpids > >Incidently there seems to be a double usage of that ID (and others >near it, 981231-981246 actually) in >modsecurity_crs_41_sql_injection_attacks.conf I will fix these, thanks. > >> rule. You can review example test payloads that they use here - >> >>https://dev.itratos.de/projects/php-ids/repository/entry/trunk/tests/IDS/ >>Mo >> 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_axoraaa...@aaaaa.com >in the box on >https://demo.phpids.org/ >it poses no problem > >while accessing > >http://testing/index.php?email=a_a_axoraaaaaa%40aaaa.com > >generates: > >Message: Warning. Pattern match >"(?i:(\\!\\=|\\&\\&|\\|\\||>>|<<|>=|<=|<>|<=>|xor|rlike|regexp|isnull)|(?: >not\\s+between\\s+0\\s+and)|(?:is\\s+null)|(like\\s+null)|(?:(?:^|\\W)in[+ >\\s]*\\([\\s\\d\"]+[^()]*\\))|(?:xor|<>|rlike(?:\\s+binary)?)|(?:regexp\\s >+binary))" >at ARGS:email. [file >"/etc/httpd/conf.d/modsecurity-crs_2.2.1/base_rules/modsecurity_crs_41_sql >_injection_attacks.conf"] >[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"] > >Similarly >3 Orchard Street >on the PHP_IDS demo is fine and >http://testing/index.php?street=3+Orchard+Street >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 - https://docs.google.com/Doc?docid=0AZNlBave77hiZGNjanptbV84Z25yaHJmMjk&pli= 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. -Ryan > >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. > >Paul > 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. _______________________________________________ Owasp-modsecurity-core-rule-set mailing list Owasp-modsecurity-core-rule-set@lists.owasp.org https://lists.owasp.org/mailman/listinfo/owasp-modsecurity-core-rule-set
