This is very helpful, recently I've come to share in some views of the community that libinjection isn't the most well supported/reviewed of all the projects on github. Fortunately compared to many other projects it is quite small from a codebase perspective and as a result the attack surface isn't outrageous, and reviewing it is reasonable. That being said we NEED to continue to including other rules that suppliment libinjection in case of a bypass, which is what we do in v3.0.0-rc1 :)
From: <owasp-modsecurity-core-rule-set-boun...@lists.owasp.org<mailto:owasp-modsecurity-core-rule-set-boun...@lists.owasp.org>> on behalf of Walter Hop <mod...@spam.lifeforms.nl<mailto:mod...@spam.lifeforms.nl>> Date: Saturday, February 6, 2016 at 10:23 AM To: "owasp-modsecurity-core-rule-set@lists.owasp.org<mailto:owasp-modsecurity-core-rule-set@lists.owasp.org>" <owasp-modsecurity-core-rule-set@lists.owasp.org<mailto:owasp-modsecurity-core-rule-set@lists.owasp.org>> Subject: Re: [Owasp-modsecurity-core-rule-set] Paranoia Mode: Controversial candidate 950120 / 931130 (Possible RFI) On 04 Feb 2016, at 10:08, Christian Folini <christian.fol...@netnea.com<mailto:christian.fol...@netnea.com>> wrote: With that being said, the blogpost above showed me, that libinjection is able to detect a great many sqli and xss attacks. But it is far from complete. (See blogpost for numbers) So I think it is _one_ rule in a set of rules aimed to stop sqli and xss. Diversity is key. Also: A realworld sqlinjection typically triggers a variety of anti-sqli rules. With _only_ libinject it would be a single critical alert. I've done a little testdrive with the CRS v3.0.0-rc1 rules today and the coverage of libinjection for MySQL is pretty complete actually! When scanning a little vulnerable test app with the dev version of sqlmap in two configurations: (1) --random-agent and (2) --random-agent --dbms=mysql, the complete CRS v3.0.0-rc1 detected all attempts with mostly high anomaly scores. Then I disabled all CRSv3's SQLi and XSS rules, except libinjection's @detectSQLi rule. Similarly, almost all attempts were detected just by libinjection alone! Out of 380 malicious requests, only the following examples were let through by libinjection: select * from foo where id=1,."'.""',) select * from foo where id=1'wqffhb<'">wweNuE select * from foo where id=1) WAITFOR DELAY '0:0:5' AND (9227=9227 select * from foo where id=1 WAITFOR DELAY '0:0:5' select * from foo where id=1') WAITFOR DELAY '0:0:5' AND ('UUAn'='UUAn select * from foo where id=1' WAITFOR DELAY '0:0:5' AND 'AzTu'='AzTu select * from foo where id=1%' WAITFOR DELAY '0:0:5' AND '%'=' (WAITFOR DELAY is Microsoft SQL dialect, usable for blind injection. I'll try this again with a newer libinjection, and if necessary report it upstream.) Resuming, libinjection's sensitivity in detecting SQLi is already very impressive! So if we ever should find a large false positive rate in an SQLi rule in the future, we don't need to be too sentimental about that single rule, as the addition of libinjection in CRS v3 ensures that SQLi should start with a nice anomaly score already. However, I agree with you completely that it's preferable to leave in any useful regexp based rules that we have. I was just curious about libinjection since it was an unknown factor to me. I'll comment on the individual rules later! -- Walter Hop | PGP key: https://lifeforms.nl/pgp<http://scanmail.trustwave.com/?c=4062&d=1ZW21qA6mVzaHrUP30VymOueR3E0w4jjrmj3ltOfGA&s=5&u=https%3a%2f%2flifeforms%2enl%2fpgp> ________________________________ 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
