As Josh mentioned, if you test these payloads against the CRS demo (http://www.modsecurity.org/demo/crs-demo.html) you will see that these requests are flagged. Some of the detection was done by generic detection rules that you may not have had activated (check the experimental directory).
Additionally, as a result of the ModSecurity SQL Injection Challenge (http://www.modsecurity.org/demo/challenge.html) we are making significant updates to the SQL Injection detection rules within ModSecurity. We will be releasing a CRS updating this week. -- Ryan Barnett Senior Security Researcher Trustwave - SpiderLabs On 7/10/11 11:20 AM, "Alexandre Biancalana" <[email protected]> wrote: >Hi list, > > I've configured mod_security 2.6.0 with modsecurity-crs_2.2.0 rules >in paranoid mode. > > Looking at apache logs I've perceived that some tries of sql >injection and xss aren't blocked by mod_security even in paranoid >mode. > > Follow my mod_security_crs_10_config.conf: > >SecComponentSignature "core ruleset/2.2.0" >SecRuleEngine On >SecDefaultAction "phase:2,pass,log" >SecAction >"phase:1,id:'981206',t:none,nolog,pass,setvar:tx.anomaly_score_blocking=on >" >SecAction "phase:1,id:'981207',t:none,nolog,pass, \ >setvar:tx.critical_anomaly_score=10, \ >setvar:tx.error_anomaly_score=4, \ >setvar:tx.warning_anomaly_score=3, \ >setvar:tx.notice_anomaly_score=2" >SecAction >"phase:1,id:'981208',t:none,nolog,pass,setvar:tx.inbound_anomaly_score_lev >el=5" >SecAction >"phase:1,id:'981209',t:none,nolog,pass,setvar:tx.outbound_anomaly_score_le >vel=4" >SecAction >"phase:1,id:'981210',t:none,nolog,pass,setvar:tx.paranoid_mode=1" >SecAction >"phase:1,id:'981211',t:none,nolog,pass,setvar:tx.max_num_args=255" >SecAction "phase:1,id:'981212',t:none,nolog,pass, \ >setvar:'tx.allowed_methods=GET HEAD POST OPTIONS', \ >setvar:'tx.allowed_request_content_type=application/x-www-form-urlencoded >multipart/form-data text/xml application/xml application/x-amf', \ >setvar:'tx.allowed_http_versions=HTTP/0.9 HTTP/1.0 HTTP/1.1', \ >setvar:'tx.restricted_extensions=.asa/ .asax/ .ascx/ .axd/ .backup/ >.bak/ .bat/ .cdx/ .cer/ .cfg/ .cmd/ .com/ .config/ .conf/ .cs/ >.csproj/ .csr/ .dat/ .db/ .dbf/ .dll/ .dos/ .ht >r/ .htw/ .ida/ .idc/ .idq/ .inc/ .ini/ .key/ .licx/ .lnk/ .log/ .mdb/ >.old/ .pass/ .pdb/ .pol/ .printer/ .pwd/ .resources/ .resx/ .sql/ >.sys/ .vb/ .vbs/ .vbproj/ .vsdisco/ .webin >fo/ .xsd/ .xsx/', \ >setvar:'tx.restricted_headers=/Proxy-Connection/ /Lock-Token/ >/Content-Range/ /Translate/ /via/ /if/'" >SecRule REQUEST_HEADERS:Content-Type "text/xml" \ > "chain,phase:1,id:'981053',t:none,t:lowercase,pass,nolog" > SecRule REQBODY_PROCESSOR "!@streq XML" >"ctl:requestBodyProcessor=XML" >SecRule REQUEST_HEADERS:User-Agent "^(.*)$" >"phase:1,id:'981217',t:none,pass,nolog,t:sha1,t:hexEncode,setvar:tx.ua_has >h=%{matched_var}" >SecRule REQUEST_HEADERS:x-forwarded-for >"^\b(\d{1,3}\.\d{1,3}\.\d{1,3}\.\d{1,3})\b" >"phase:1,id:'981225',t:none,pass,nolog,capture,setvar:tx.real_ip=%{tx.1}" >SecRule &TX:REAL_IP "!@eq 0" >"phase:1,id:'981226',t:none,pass,nolog,initcol:global=global,initcol:ip=%{ >tx.real_ip}_%{tx.ua_hash}" >SecRule &TX:REAL_IP "@eq 0" >"phase:1,id:'981218',t:none,pass,nolog,initcol:global=global,initcol:ip=%{ >remote_addr}_%{tx.ua_hash}" > > > Here are some examples of request that aren't blocked: > > >/search.php?idS=c4ca4238a0b923820dcc509a6f75849b%27%20or%20%28sleep%284%29 >%2b1%29%20limit%201%20-- >%20 > >/album.php?idalbum=35&idfoto=163&idsel=1%3C%00ScRiPt%20%0d%0a%3Eprompt%289 >73555%29%3C%2fScRiPt%3E > >/stats.php?idJ=%21%28%28%29%26%26%21%7c*%7c*%7c > >I added the word "sleep" to modsecurity_41_sql_injection_attacks.data >and that starts to stop some requests, but not all. > >That is suppose to happen ? > >Best Regards, > >Alexandre >_______________________________________________ >Owasp-modsecurity-core-rule-set mailing list >[email protected] >https://lists.owasp.org/mailman/listinfo/owasp-modsecurity-core-rule-set > 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 [email protected] https://lists.owasp.org/mailman/listinfo/owasp-modsecurity-core-rule-set
