Thanks for the feedback. On Wed, Aug 17, 2011 at 10:36 PM, Ryan Barnett <[email protected]> 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 > 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: [email protected] 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") 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.) 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 _______________________________________________ Owasp-modsecurity-core-rule-set mailing list [email protected] https://lists.owasp.org/mailman/listinfo/owasp-modsecurity-core-rule-set
