Thread: [mod-security-users] Why do I get [msg "Request content type is not allowed by policy"] [data "appl
Brought to you by:
victorhora,
zimmerletw
From: Mirabito, M. (M. (CDC/CCID/O. (CTR) <mc...@cd...> - 2010-02-26 16:47:13
|
Hello to everyone, We are brand new to Mod_security so we are still struggling to say the least to get a better understating. We have been using Mod_Security 2.5.11 with Apache 2.2.14 on Win 2003 and getting our applications to behave properly, but yesterday we decided to upgrade to Mod Security 2.5.12 with rule set 2.0.5. as we were struggling with another rule that did not make too much sense to us. The upgrade resulted in the following issue but we do not understand how we can address the issue, what we are seeing is that every page request now logs to mod security [msg "Request content type is not allowed by policy"] [data "application/x-www-form-urlencoded]. Is this something we can remedy because I am hesitant to comment out the rule using the SecRuleRemoveByID directive? I am not even sure if this a mod_security configuration or rule set issue Any help or suggestions are greatly appreciated. Thanks in advance, Max Here is the partial warning we are getting on any page that we hit [id "960010"] [msg "Request content type is not allowed by policy"] [data "application/x-www-form-urlencoded] Here is the security log --e14a0000-A-- [26/Feb/2010:10:55:12 --0500] S4fu255v238AABQMBY4AAAA9 10.100.121.53 4409 158.111.219.127 443 --e14a0000-B-- POST /MYAPP/jsp/appmain?action=login HTTP/1.1 Accept: */* Referer: https://appserver /MYAPP/jsp/appmain?action=login Accept-Language: en-us Content-Type: application/x-www-form-urlencoded UA-CPU: x86 Accept-Encoding: gzip, deflate User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1; .NET CLR 1.1.4322; .NET CLR 2.0.50727; InfoPath.1; .NET CLR 3.0.04506.648; .NET CLR 3.5.21022; MS-RTC LM 8; .NET CLR 3.0.4506.2152; .NET CLR 3.5.30729) Host: apd-v-ccid-sams.cdc.gov Content-Length: 48 Connection: Keep-Alive Cache-Control: no-cache Cookie: JSESSIONID=B5FEA90B9A406EBE1F5D1B24BC44386A; s_vi=[CS]v1|49774EAB00000F89-A2B0C0900000060[CE] --e14a0000-F-- HTTP/1.0 200 OK X-Powered-By: Servlet 2.4; JBoss-4.0.5.GA (build: CVSTag=Branch_4_0 date=200610162339)/Tomcat-5.5 Content-Type: text/html;charset=UTF-8 Via: 1.1 apd-v-ccid-sams.cdc.gov Connection: close --e14a0000-H-- Message: Pattern match "^([^;\s]+)" at REQUEST_HEADERS:Content-Type. [file "C:/Apache2.2/conf/mod_security/base_rules/modsecurity_crs_30_http_polic y.conf"] [line "63"] [id "960010"] [msg "Request content type is not allowed by policy"] [data "application/x-www-form-urlencoded"] [severity "WARNING"] [tag "POLICY/ENCODING_NOT_ALLOWED"] [tag "WASCTC/WASC-20"] [tag "OWASP_TOP_10/A1"] [tag "OWASP_AppSensor/EE2"] [tag "PCI/12.1"] Apache-Handler: proxy-server Stopwatch: 1267199707998078 4781219 (0 187499 -) Producer: ModSecurity for Apache/2.5.12 (http://www.modsecurity.org/); core ruleset/2.0.5. Server: Apache/2.2.14 (Win32) mod_ssl/2.2.14 OpenSSL/0.9.8k --e14a0000-Z-- Here is a partial debug log: [4] Recipe: Invoking rule cb4ea0; [file "C:/Apache2.2/conf/mod_security/base_rules/modsecurity_crs_30_http_polic y.conf"] [line "63"] [id "960010"]. [5] Rule cb4ea0: SecRule "REQUEST_METHOD" "!@rx ^(?:GET|HEAD|PROPFIND|OPTIONS)$" "phase:2,chain,t:none,pass,nolog,auditlog,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}" [4] Transformation completed in 0 usec. [4] Executing operator "!rx" with param "^(?:GET|HEAD|PROPFIND|OPTIONS)$" against REQUEST_METHOD. [4] Operator completed in 0 usec. [4] Rule returned 1. [4] Recipe: Invoking rule cb6b08; [file "C:/Apache2.2/conf/mod_security/base_rules/modsecurity_crs_30_http_polic y.conf"] [line "64"]. [5] Rule cb6b08: SecRule "REQUEST_HEADERS:Content-Type" "@rx ^([^;\\s]+)" "capture" [4] Transformation completed in 0 usec. [4] Executing operator "rx" with param "^([^;\\s]+)" against REQUEST_HEADERS:Content-Type. [4] Operator completed in 0 usec. [4] Warning. Pattern match "^([^;\s]+)" at REQUEST_HEADERS:Content-Type. [file "C:/Apache2.2/conf/mod_security/base_rules/modsecurity_crs_30_http_polic y.conf"] [line "63"] [id "960010"] [msg "Request content type is not allowed by policy"] [data "application/x-www-form-urlencoded"] [severity "WARNING"] [tag "POLICY/ENCODING_NOT_ALLOWED"] [tag "WASCTC/WASC-20"] [tag "OWASP_TOP_10/A1"] [tag "OWASP_AppSensor/EE2"] [tag "PCI/12.1"] [4] Rule returned 1. [4] Recipe: Invoking rule cb7138; [file "C:/Apache2.2/conf/mod_security/base_rules/modsecurity_crs_30_http_polic y.conf"] [line "65"]. [5] Rule cb7138: SecRule "TX:0" "!@within %{tx.allowed_request_content_type}" "phase:2,pass,log,t:none,setvar:tx.msg=%{rule.msg},setvar:tx.anomaly_sco re=+%{tx.warning_anomaly_score},setvar:tx.policy_score=+%{tx.warning_ano maly_score},setvar:tx.%{rule.id}-POLICY/CONTENT_TYPE_NOT_ALLOWED-%{match ed_var_name}=%{matched_var}" [4] Transformation completed in 0 usec. [4] Executing operator "!within" with param "%{tx.allowed_request_content_type}" against TX:0. [4] Operator completed in 0 usec. [4] Rule returned 0. Here is our a partial .conf file: <IfModule security2_module> Include conf/mod_security/*.conf Include conf/mod_security/base_rules/*.conf SecRuleEngine On SecDefaultAction log,auditlog,deny,status:403,phase:2,t:lowercase,t:replaceNulls,t:compre ssWhitespace SecAuditEngine RelevantOnly SecDebugLogLevel 5 SecAuditLogType Serial SecAuditLog logs/mod_security.log SecDebugLog logs/modsec_debug.log SecTmpDir "logs" SecDataDir "logs" SecUploadDir "logs" SecAuditLogStorageDir "logs" </IfModule> |
From: Ryan B. <rya...@br...> - 2010-02-26 16:59:03
|
On Friday 26 February 2010 11:46:29 Mirabito, Massimo (Max) (CDC/CCID/OD) (CTR) wrote: > Hello to everyone, > > We are brand new to Mod_security so we are still struggling to say the > least to get a better understating. We have been using Mod_Security 2.5.11 > with Apache 2.2.14 on Win 2003 and getting our applications to behave > properly, but yesterday we decided to upgrade to Mod Security 2.5.12 with > rule set 2.0.5. as we were struggling with another rule that did not make > too much sense to us. > > The upgrade resulted in the following issue but we do not understand how > we can address the issue, what we are seeing is that every page request > now logs to mod security [msg "Request content type is not allowed by > policy"] [data "application/x-www-form-urlencoded]. Is this something we > can remedy because I am hesitant to comment out the rule using the > SecRuleRemoveByID directive? I am not even sure if this a mod_security > configuration or rule set issue > > Any help or suggestions are greatly appreciated. > There is a bug in that rule as it is missing a "chain" action on the 2nd SecRule. The rule should be this - SecRule REQUEST_METHOD "!^(?:GET|HEAD|PROPFIND|OPTIONS)$" "phase:2,chain,t:none,pass,nolog,auditlog,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,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 issue has already been reported in JIRA (https://www.modsecurity.org/tracker/browse/CORERULES-37) and fixed in CRS v2.0.6. You can manually add the "chain" action to your rule to fix the issue now. -Ryan |
From: Mirabito, M. (M. (CDC/CCID/O. (CTR) <mc...@cd...> - 2010-02-26 17:17:49
|
Ryan, Many thank that fixed our problem. MAx -----Original Message----- From: Ryan Barnett [mailto:rya...@br...] Sent: Friday, February 26, 2010 11:59 To: mod...@li... Cc: Mirabito, Massimo (Max) (CDC/CCID/OD) (CTR); Wang, Silver (CDC/CCID/OD) (CTR) Subject: Re: [mod-security-users] Why do I get [msg "Request content type is not allowed by policy"] [data "application/x-www-form-urlencoded] On Friday 26 February 2010 11:46:29 Mirabito, Massimo (Max) (CDC/CCID/OD) (CTR) wrote: > Hello to everyone, > > We are brand new to Mod_security so we are still struggling to say the > least to get a better understating. We have been using Mod_Security 2.5.11 > with Apache 2.2.14 on Win 2003 and getting our applications to behave > properly, but yesterday we decided to upgrade to Mod Security 2.5.12 with > rule set 2.0.5. as we were struggling with another rule that did not make > too much sense to us. > > The upgrade resulted in the following issue but we do not understand how > we can address the issue, what we are seeing is that every page request > now logs to mod security [msg "Request content type is not allowed by > policy"] [data "application/x-www-form-urlencoded]. Is this something we > can remedy because I am hesitant to comment out the rule using the > SecRuleRemoveByID directive? I am not even sure if this a mod_security > configuration or rule set issue > > Any help or suggestions are greatly appreciated. > There is a bug in that rule as it is missing a "chain" action on the 2nd SecRule. The rule should be this - SecRule REQUEST_METHOD "!^(?:GET|HEAD|PROPFIND|OPTIONS)$" "phase:2,chain,t:none,pass,nolog,auditlog,msg:'Request content type is not allowed by policy',id:'960010',tag:'POLICY/ENCODING_NOT_ALLOWED',tag:'WASCTC/WASC-2 0',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,setvar:'tx.msg=%{rule.msg}',setvar:tx.anomaly_score=+%{tx. warning_anomaly_score},setvar:tx.policy_score=+%{tx.warning_anomaly_scor e},setvar:tx. %{rule.id}-POLICY/CONTENT_TYPE_NOT_ALLOWED-%{matched_var _name}=%{matched_var}" This issue has already been reported in JIRA (https://www.modsecurity.org/tracker/browse/CORERULES-37) and fixed in CRS v2.0.6. You can manually add the "chain" action to your rule to fix the issue now. -Ryan |