I just pushed a quick CRS update to SVN and I recommend that users update. Here is the CHANGES file info -
-------------------------- Version 2.2.3 - 10/17/2011 -------------------------- Improvements: - Added Watcher Cookie Checks to optional_rules/modsecurity_crs_55_app_defects.conf file http://websecuritytool.codeplex.com/wikipage?title=Checks#cookies Bug Fixes: - Fixed Content-Type evasion issue by adding ctl:forceRequestBodyVariable action to rule ID 960010. (Identified by Andrew Wilson of Trustwave SpiderLabs). - Updated the regex and added tags for RFI rules. The main reason for updating is that there is an evasion issue related to the default request body parsers. From the Reference Manual for the "ctl" action - http://sourceforge.net/apps/mediawiki/mod-security/index.php?title=Reference_Manual#ctl The requestBodyProcessor option allows you to configure the request body processor. By default, ModSecurity will use the URLENCODED and MULTIPART processors to process an application/x-www-form-urlencoded and a multipart/form-data body, respectively. A third processor, XML, is also supported, but it is never used implicitly. Instead, you must tell ModSecurity to use it by placing a few rules in the REQUEST_HEADERS processing phase. After the request body is processed as XML, you will be able to use the XML-related features to inspect it. Request body processors will not interrupt a transaction if an error occurs during parsing. Instead, they will set the variables REQBODY_PROCESSOR_ERROR and REQBODY_PROCESSOR_ERROR_MSG. These variables should be inspected in the REQUEST_BODY phase and an appropriate action taken. The forceRequestBodyVariable option allows you to configure the REQUEST_BODY variable to be set when there is no request body processor configured. This allows for inspection of request bodies of unknown types. One of the SpiderLabs AppPentest Consultants found that by sending different Content-Type request headers, oftentimes the application doesn't care, and it would cause ModSecurity not to parse the request body. This means that POST ARGS and REQUEST_BODY variables would not be populated. It is for this reason that we have updated the following rule in the modsecurity_crs_30_http_policy.conf file (http://mod-security.svn.sourceforge.net/viewvc/mod-security/crs/trunk/base_rules/modsecurity_crs_30_http_policy.conf?revision=1854) SecRule REQUEST_METHOD "!^(?:GET|HEAD|PROPFIND|OPTIONS)$" "phase:1,chain,t:none,block,msg:'Request content type is not allowed by policy',id:'960010',tag:'POLICY/ENCODING_NOT_ALLOWED',tag:'WASCTC/WASC-20',tag:'OWASP_TOP_10/A1',tag:'OWASP_AppSensor/EE2',tag:'PCI/12.1',severity:'4',logdata:'%{matched_var}'" SecRule REQUEST_HEADERS:Content-Type "^([^;\s]+)" "chain,capture" SecRule TX:0 "!@within %{tx.allowed_request_content_type}" "t:none,ctl:forceRequestBodyVariable=On,setvar:'tx.msg=%{rule.msg}',setvar:tx.anomaly_score=+%{tx.warning_anomaly_score},setvar:tx.policy_score=+%{tx.warning_anomaly_score},setvar:tx.%{rule.id}-POLICY/CONTENT_TYPE_NOT_ALLOWED-%{matched_var_name}=%{matched_var}" This rule will force population of REQUEST_BODY for Content-Types not defined by the admin in the 10 config file. One option for this issue would be to simply update the actions for this rule and deny the request if a client is sending unexpected Content-Types. Many users, however, are running in anomaly scoring or detection only mode and not blocking based on just one rule. With this new configuration, other rules would be able to inspect the REQUEST_BODY variable and create alerts. Please let us know if you have any feedback. -- Ryan Barnett Senior Security Researcher Trustwave - SpiderLabs ________________________________ 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
