# ------------------------------------------------------------------------ # OWASP ModSecurity Core Rule Set ver.3.3.2 # Copyright (c) 2006-2020 Trustwave and contributors. All rights reserved. # # The OWASP ModSecurity Core Rule Set is distributed under # Apache Software License (ASL) version 2 # Please see the enclosed LICENSE file for full details. # ------------------------------------------------------------------------ # # Some protocol violations are common in application layer attacks. # Validating HTTP requests eliminates a large number of application layer attacks. # # The purpose of this rules file is to enforce HTTP RFC requirements that state how # the client is supposed to interact with the server. # https://www.w3.org/Protocols/rfc2616/rfc2616-sec3.html # # -= Paranoia Level 0 (empty) =- (apply unconditionally) # SecRule TX:EXECUTING_PARANOIA_LEVEL "@lt 1" "id:920011,phase:1,pass,nolog,skipAfter:END-REQUEST-920-PROTOCOL-ENFORCEMENT" SecRule TX:EXECUTING_PARANOIA_LEVEL "@lt 1" "id:920012,phase:2,pass,nolog,skipAfter:END-REQUEST-920-PROTOCOL-ENFORCEMENT" # # -= Paranoia Level 1 (default) =- (apply only when tx.executing_paranoia_level is sufficiently high: 1 or higher) # # # Validate request line against the format specified in the HTTP RFC # # -=[ Rule Logic ]=- # # Uses rule negation against the regex for positive security. The regex specifies the proper # construction of URI request lines such as: # # "http:" "//" host [ ":" port ] [ abs_path [ "?" query ]] # # It also outlines proper construction for CONNECT, OPTIONS and GET requests. # # -=[ References ]=- # https://www.w3.org/Protocols/rfc2616/rfc2616-sec3.html#sec3.2.1 # http://capec.mitre.org/data/definitions/272.html # SecRule REQUEST_LINE "!@rx ^(?i:(?:[a-z]{3,10}\s+(?:\w{3,7}?://[\w\-\./]*(?::\d+)?)?/[^?#]*(?:\?[^#\s]*)?(?:#[\S]*)?|connect (?:\d{1,3}\.){3}\d{1,3}\.?(?::\d+)?|options \*)\s+[\w\./]+|get /[^?#]*(?:\?[^#\s]*)?(?:#[\S]*)?)$" \ "id:920100,\ phase:2,\ block,\ t:none,\ msg:'Invalid HTTP Request Line',\ logdata:'%{request_line}',\ tag:'application-multi',\ tag:'language-multi',\ tag:'platform-multi',\ tag:'attack-protocol',\ tag:'paranoia-level/1',\ tag:'OWASP_CRS',\ tag:'capec/1000/210/272',\ ver:'OWASP_CRS/3.3.2',\ severity:'WARNING',\ setvar:'tx.anomaly_score_pl1=+%{tx.warning_anomaly_score}'" # # Identify multipart/form-data name evasion attempts # # There are possible impedance mismatches between how # ModSecurity interprets multipart file names and how # a destination app server such as PHP might parse the # Content-Disposition data: # # filename-parm := "filename" "=" value # # -=[ Rule Logic ]=- # These rules check for the existence of the ' " ; = meta-characters in # either the file or file name variables. # HTML entities may lead to false positives, why they are allowed on PL1. # Negative look behind assertions allow frequently used entities &_; # # -=[ Targets, characters and html entities ]=- # # 920120: PL1 : FILES_NAMES, FILES # ['\";=] but allowed: # &[aAoOuUyY]uml); &[aAeEiIoOuU]circ; &[eEiIoOuUyY]acute; # &[aAeEiIoOuU]grave; &[cC]cedil; &[aAnNoO]tilde; & ' # # 920121: PL2 : FILES_NAMES, FILES # ['\";=] : ' " ; = meta-characters # # Not supported by re2 (?@-]+)*$" \ "id:920470,\ phase:1,\ block,\ t:none,t:lowercase,\ msg:'Illegal Content-Type header',\ logdata:'%{MATCHED_VAR}',\ tag:'application-multi',\ tag:'language-multi',\ tag:'platform-multi',\ tag:'attack-protocol',\ tag:'paranoia-level/1',\ tag:'OWASP_CRS',\ tag:'capec/1000/255/153',\ tag:'PCI/12.1',\ ver:'OWASP_CRS/3.3.2',\ severity:'CRITICAL',\ setvar:'tx.anomaly_score_pl1=+%{tx.critical_anomaly_score}'" # In case Content-Type header can be parsed, check the mime-type against # the policy defined in the 'allowed_request_content_type' variable. # To change your policy, edit crs-setup.conf and activate rule 900220. SecRule REQUEST_HEADERS:Content-Type "@rx ^[^;\s]+" \ "id:920420,\ phase:2,\ block,\ capture,\ t:none,\ msg:'Request content type is not allowed by policy',\ logdata:'%{MATCHED_VAR}',\ tag:'application-multi',\ tag:'language-multi',\ tag:'platform-multi',\ tag:'attack-protocol',\ tag:'paranoia-level/1',\ tag:'OWASP_CRS',\ tag:'capec/1000/255/153',\ tag:'PCI/12.1',\ ver:'OWASP_CRS/3.3.2',\ severity:'CRITICAL',\ setvar:'tx.content_type=|%{tx.0}|',\ chain" SecRule TX:content_type "!@within %{tx.allowed_request_content_type}" \ "t:lowercase,\ setvar:'tx.anomaly_score_pl1=+%{tx.critical_anomaly_score}'" # # Restrict charset parameter within the content-type header # SecRule REQUEST_HEADERS:Content-Type "@rx charset\s*=\s*[\"']?([^;\"'\s]+)" \ "id:920480,\ phase:1,\ block,\ capture,\ t:none,t:lowercase,\ msg:'Request content type charset is not allowed by policy',\ logdata:'%{MATCHED_VAR}',\ tag:'application-multi',\ tag:'language-multi',\ tag:'platform-multi',\ tag:'attack-protocol',\ tag:'paranoia-level/1',\ tag:'OWASP_CRS',\ tag:'capec/1000/255/153',\ tag:'PCI/12.1',\ ver:'OWASP_CRS/3.3.2',\ severity:'CRITICAL',\ chain" SecRule TX:1 "!@rx ^%{tx.allowed_request_content_type_charset}$" \ "t:none,\ ctl:forceRequestBodyVariable=On,\ setvar:'tx.anomaly_score_pl1=+%{tx.critical_anomaly_score}'" # # Restrict protocol versions. # SecRule REQUEST_PROTOCOL "!@within %{tx.allowed_http_versions}" \ "id:920430,\ phase:1,\ block,\ t:none,\ msg:'HTTP protocol version is not allowed by policy',\ logdata:'%{MATCHED_VAR}',\ tag:'application-multi',\ tag:'language-multi',\ tag:'platform-multi',\ tag:'attack-protocol',\ tag:'paranoia-level/1',\ tag:'OWASP_CRS',\ tag:'capec/1000/210/272',\ tag:'PCI/6.5.10',\ ver:'OWASP_CRS/3.3.2',\ severity:'CRITICAL',\ setvar:'tx.anomaly_score_pl1=+%{tx.critical_anomaly_score}'" # # Restrict file extension # SecRule REQUEST_BASENAME "@rx \.([^.]+)$" \ "id:920440,\ phase:2,\ block,\ capture,\ t:none,\ msg:'URL file extension is restricted by policy',\ logdata:'%{TX.0}',\ tag:'application-multi',\ tag:'language-multi',\ tag:'platform-multi',\ tag:'attack-protocol',\ tag:'paranoia-level/1',\ tag:'OWASP_CRS',\ tag:'capec/1000/210/272',\ tag:'PCI/6.5.10',\ ver:'OWASP_CRS/3.3.2',\ severity:'CRITICAL',\ setvar:'tx.extension=.%{tx.1}/',\ chain" SecRule TX:EXTENSION "@within %{tx.restricted_extensions}" \ "t:none,t:urlDecodeUni,t:lowercase,\ setvar:'tx.anomaly_score_pl1=+%{tx.critical_anomaly_score}'" # # Backup or "working" file extension # example: index.php~, /index.php~/foo/ # SecRule REQUEST_FILENAME "@rx \.[^.~]+~(?:/.*|)$" \ "id:920500,\ phase:2,\ block,\ t:none,t:urlDecodeUni,\ msg:'Attempt to access a backup or working file',\ logdata:'%{TX.0}',\ tag:'application-multi',\ tag:'language-multi',\ tag:'platform-multi',\ tag:'attack-protocol',\ tag:'paranoia-level/1',\ tag:'OWASP_CRS',\ tag:'capec/1000/210/272',\ tag:'PCI/6.5.10',\ ver:'OWASP_CRS/3.3.2',\ severity:'CRITICAL',\ setvar:'tx.anomaly_score_pl1=+%{tx.critical_anomaly_score}'" # # Restricted HTTP headers # # -=[ Rule Logic ]=- # The use of certain headers is restricted. They are listed in the variable # TX.restricted_headers. # # The headers are transformed into lowercase before the match. In order to # make sure that only complete header names are matching, the names in # TX.restricted_headers are wrapped in slashes. This guarantees that the # header Range (-> /range/) is not matching the restricted header # /content-range/ for example. # # This is a chained rule, where the first rule fills a set of variables of the # form TX.header_name_. The second rule is then executed for all # variables of the form TX.header_name_. # # As a consequence of the construction of the rule, the alert message and the # alert data will not display the original header name Content-Range, but # /content-range/ instead. # # # -=[ References ]=- # https://access.redhat.com/security/vulnerabilities/httpoxy (Header Proxy) # SecRule REQUEST_HEADERS_NAMES "@rx ^.*$" \ "id:920450,\ phase:2,\ block,\ capture,\ t:none,t:lowercase,\ msg:'HTTP header is restricted by policy (%{MATCHED_VAR})',\ logdata:'Restricted header detected: %{MATCHED_VAR}',\ tag:'application-multi',\ tag:'language-multi',\ tag:'platform-multi',\ tag:'attack-protocol',\ tag:'paranoia-level/1',\ tag:'OWASP_CRS',\ tag:'capec/1000/210/272',\ tag:'PCI/12.1',\ ver:'OWASP_CRS/3.3.2',\ severity:'CRITICAL',\ setvar:'tx.header_name_%{tx.0}=/%{tx.0}/',\ chain" SecRule TX:/^header_name_/ "@within %{tx.restricted_headers}" \ "setvar:'tx.anomaly_score_pl1=+%{tx.critical_anomaly_score}'" SecRule TX:EXECUTING_PARANOIA_LEVEL "@lt 2" "id:920013,phase:1,pass,nolog,skipAfter:END-REQUEST-920-PROTOCOL-ENFORCEMENT" SecRule TX:EXECUTING_PARANOIA_LEVEL "@lt 2" "id:920014,phase:2,pass,nolog,skipAfter:END-REQUEST-920-PROTOCOL-ENFORCEMENT" # # -= Paranoia Level 2 =- (apply only when tx.executing_paranoia_level is sufficiently high: 2 or higher) # # # -=[ Rule Logic ]=- # # Check the number of range fields in the Range request header. # # An excessive number of Range request headers can be used to DoS a server. # The original CVE proposed an arbitrary upper limit of 5 range fields. # # Several clients are known to request PDF fields with up to 62 range # fields. Therefore the standard rule does not cover PDF files. This is # performed in two separate (stricter) siblings of this rule. # # 920200: PL2: Limit of 5 range header fields for all filenames outside of PDFs # 920201: PL2: Limit of 62 range header fields for PDFs # 920202: PL4: Limit of 5 range header fields for PDFs # # -=[ References ]=- # https://httpd.apache.org/security/CVE-2011-3192.txt SecRule REQUEST_HEADERS:Range|REQUEST_HEADERS:Request-Range "@rx ^bytes=(?:(?:\d+)?-(?:\d+)?\s*,?\s*){6}" \ "id:920200,\ phase:2,\ block,\ t:none,\ msg:'Range: Too many fields (6 or more)',\ logdata:'%{MATCHED_VAR}',\ tag:'application-multi',\ tag:'language-multi',\ tag:'platform-multi',\ tag:'attack-protocol',\ tag:'OWASP_CRS',\ tag:'capec/1000/210/272',\ tag:'paranoia-level/2',\ ver:'OWASP_CRS/3.3.2',\ severity:'WARNING',\ chain" SecRule REQUEST_BASENAME "!@endsWith .pdf" \ "setvar:'tx.anomaly_score_pl2=+%{tx.warning_anomaly_score}'" # # This is a sibling of rule 920200 # SecRule REQUEST_BASENAME "@endsWith .pdf" \ "id:920201,\ phase:2,\ block,\ t:none,\ msg:'Range: Too many fields for pdf request (63 or more)',\ logdata:'%{MATCHED_VAR}',\ tag:'application-multi',\ tag:'language-multi',\ tag:'platform-multi',\ tag:'attack-protocol',\ tag:'OWASP_CRS',\ tag:'capec/1000/210/272',\ tag:'paranoia-level/2',\ ver:'OWASP_CRS/3.3.2',\ severity:'WARNING',\ chain" SecRule REQUEST_HEADERS:Range|REQUEST_HEADERS:Request-Range "@rx ^bytes=(?:(?:\d+)?-(?:\d+)?\s*,?\s*){63}" \ "setvar:'tx.anomaly_score_pl2=+%{tx.warning_anomaly_score}'" SecRule ARGS "@rx %[0-9a-fA-F]{2}" \ "id:920230,\ phase:2,\ block,\ t:none,\ msg:'Multiple URL Encoding Detected',\ logdata:'%{MATCHED_VAR}',\ tag:'application-multi',\ tag:'language-multi',\ tag:'platform-multi',\ tag:'attack-protocol',\ tag:'OWASP_CRS',\ tag:'capec/1000/255/153/267/120',\ tag:'paranoia-level/2',\ ver:'OWASP_CRS/3.3.2',\ severity:'WARNING',\ setvar:'tx.anomaly_score_pl2=+%{tx.warning_anomaly_score}'" # # Missing Accept Header # # -=[ Rule Logic ]=- # This rule generates a notice if the Accept header is missing. # # Notice: The rule tries to avoid known false positives by ignoring # OPTIONS requests coming from known offending User-Agents via two # chained rules. # As ModSecurity only reports the match of the last matching rule, # the alert is misleading. # SecRule &REQUEST_HEADERS:Accept "@eq 0" \ "id:920300,\ phase:2,\ pass,\ t:none,\ msg:'Request Missing an Accept Header',\ tag:'application-multi',\ tag:'language-multi',\ tag:'platform-multi',\ tag:'attack-protocol',\ tag:'OWASP_CRS',\ tag:'capec/1000/210/272',\ tag:'PCI/6.5.10',\ tag:'paranoia-level/2',\ ver:'OWASP_CRS/3.3.2',\ severity:'NOTICE',\ chain" SecRule REQUEST_METHOD "!@rx ^OPTIONS$" \ "chain" SecRule REQUEST_HEADERS:User-Agent "!@pm AppleWebKit Android" \ "t:none,\ setvar:'tx.anomaly_score_pl2=+%{tx.notice_anomaly_score}'" # # PL2: This is a stricter sibling of 920270. # SecRule REQUEST_URI|REQUEST_HEADERS|ARGS|ARGS_NAMES "@validateByteRange 9,10,13,32-126,128-255" \ "id:920271,\ phase:2,\ block,\ t:none,t:urlDecodeUni,\ msg:'Invalid character in request (non printable characters)',\ logdata:'%{MATCHED_VAR_NAME}=%{MATCHED_VAR}',\ tag:'application-multi',\ tag:'language-multi',\ tag:'platform-multi',\ tag:'attack-protocol',\ tag:'OWASP_CRS',\ tag:'capec/1000/210/272',\ tag:'paranoia-level/2',\ ver:'OWASP_CRS/3.3.2',\ severity:'CRITICAL',\ setvar:'tx.anomaly_score_pl2=+%{tx.critical_anomaly_score}'" # # Missing User-Agent Header # # -=[ Rule Logic ]=- # This rules will check to see if there is a User-Agent header or not. # SecRule &REQUEST_HEADERS:User-Agent "@eq 0" \ "id:920320,\ phase:2,\ pass,\ t:none,\ msg:'Missing User Agent Header',\ tag:'application-multi',\ tag:'language-multi',\ tag:'platform-multi',\ tag:'attack-protocol',\ tag:'OWASP_CRS',\ tag:'capec/1000/210/272',\ tag:'PCI/6.5.10',\ tag:'paranoia-level/2',\ ver:'OWASP_CRS/3.3.2',\ severity:'NOTICE',\ setvar:'tx.anomaly_score_pl2=+%{tx.notice_anomaly_score}'" # # PL2: This is a stricter sibling of 920120. # SecRule FILES_NAMES|FILES "@rx ['\";=]" \ "id:920121,\ phase:2,\ block,\ t:none,t:urlDecodeUni,\ msg:'Attempted multipart/form-data bypass',\ logdata:'%{MATCHED_VAR}',\ tag:'application-multi',\ tag:'language-multi',\ tag:'platform-multi',\ tag:'attack-protocol',\ tag:'OWASP_CRS',\ tag:'capec/1000/210/272',\ tag:'paranoia-level/2',\ ver:'OWASP_CRS/3.3.2',\ severity:'CRITICAL',\ setvar:'tx.anomaly_score_pl2=+%{tx.critical_anomaly_score}'" # # PL2: Block on Missing Content-Type Header with Request Body # This is a stricter sibling of rule 920340. # # -=[ References ]=- # http://httpwg.org/specs/rfc7231.html#header.content-type SecRule REQUEST_HEADERS:Content-Length "!@rx ^0$" \ "id:920341,\ phase:2,\ block,\ t:none,\ msg:'Request Containing Content Requires Content-Type header',\ tag:'application-multi',\ tag:'language-multi',\ tag:'platform-multi',\ tag:'attack-protocol',\ tag:'paranoia-level/2',\ tag:'OWASP_CRS',\ tag:'capec/1000/210/272',\ ver:'OWASP_CRS/3.3.2',\ severity:'CRITICAL',\ chain" SecRule &REQUEST_HEADERS:Content-Type "@eq 0" \ "t:none,\ setvar:'tx.anomaly_score_pl2=+%{tx.critical_anomaly_score}'" SecRule TX:EXECUTING_PARANOIA_LEVEL "@lt 3" "id:920015,phase:1,pass,nolog,skipAfter:END-REQUEST-920-PROTOCOL-ENFORCEMENT" SecRule TX:EXECUTING_PARANOIA_LEVEL "@lt 3" "id:920016,phase:2,pass,nolog,skipAfter:END-REQUEST-920-PROTOCOL-ENFORCEMENT" # # -= Paranoia Level 3 =- (apply only when tx.executing_paranoia_level is sufficiently high: 3 or higher) # # # PL 3: This is a stricter sibling of 920270. Ascii range: Printable characters in the low range # # This rule is also triggered by the following exploit(s): # [ SAP CRM Java vulnerability CVE-2018-2380 - Exploit tested: https://www.exploit-db.com/exploits/44292 ] # SecRule REQUEST_URI|REQUEST_HEADERS|ARGS|ARGS_NAMES|REQUEST_BODY "@validateByteRange 32-36,38-126" \ "id:920272,\ phase:2,\ block,\ t:none,t:urlDecodeUni,\ msg:'Invalid character in request (outside of printable chars below ascii 127)',\ logdata:'%{MATCHED_VAR_NAME}=%{MATCHED_VAR}',\ tag:'application-multi',\ tag:'language-multi',\ tag:'platform-multi',\ tag:'attack-protocol',\ tag:'OWASP_CRS',\ tag:'capec/1000/210/272',\ tag:'paranoia-level/3',\ ver:'OWASP_CRS/3.3.2',\ severity:'CRITICAL',\ setvar:'tx.anomaly_score_pl3=+%{tx.critical_anomaly_score}'" # # PL3: The little known x-up-devcap-post-charset request header can be used to submit # a request with a different encoding as an alternative to the charset parameter in # the Content-Type header. This can be used to circumvent charset restrictions on # the Content-Type header in ASP.NET. # Note that this only works in combination with a User-Agent prefix. # # This rule is based on a blog post by Soroush Dalili at # https://soroush.secproject.com/blog/2019/05/x-up-devcap-post-charset-header-in-aspnet-to-bypass-wafs-again/ # SecRule &REQUEST_HEADERS:x-up-devcap-post-charset "@ge 1" \ "id:920490,\ phase:1,\ block,\ t:none,\ msg:'Request header x-up-devcap-post-charset detected in combination with prefix \'UP\' to User-Agent',\ logdata:'%{MATCHED_VAR_NAME}=%{MATCHED_VAR}',\ tag:'language-aspnet',\ tag:'platform-windows',\ tag:'attack-protocol',\ tag:'OWASP_CRS',\ tag:'capec/1000/210/272',\ tag:'paranoia-level/3',\ ver:'OWASP_CRS/3.3.2',\ severity:'CRITICAL',\ chain" SecRule REQUEST_HEADERS:User-Agent "@rx ^(?i)up" \ "t:none,\ setvar:'tx.anomaly_score_pl3=+%{tx.critical_anomaly_score}'" # # Cache-Control Request Header whitelist # # -=[ Rule Logic ]=- # This rule aims to strictly whitelist the Cache-Control request header # values and to blocks all violations. This should be useful to intercept # "bad bot" and tools that impersonate a real browser but with wrong request # header setup. # # The regular expression used on this rule tries to match multiple directives # in a single value, for example: "max-stale=1, max-age=2". This leads us to # use a regular expression that accepts a trailing comma to keep compatibility # with all regex engines and not PCRE only. For example: "max-stale=1, max-age=2, " # # Moreover, this regular expression allows duplicate directives sequence like: # "max-stale, max-stale=1, no-cache, no-cache". # # Standard Cache-Control directives that can be used by the client: # - max-age= # - max-stale[=] # - min-fresh= # - no-cache # - no-store # - no-transform # - only-if-cached # # References: # - https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Cache-Control # - https://regex101.com/r/CZ0Hxu/22 # SecRule &REQUEST_HEADERS:Cache-Control "@gt 0" \ "id:920510,\ phase:1,\ block,\ t:none,\ msg:'Invalid Cache-Control request header',\ logdata:'Invalid Cache-Control value in request found within %{MATCHED_VAR_NAME}: %{MATCHED_VAR}',\ tag:'application-multi',\ tag:'language-multi',\ tag:'platform-multi',\ tag:'attack-protocol',\ tag:'header-whitelist',\ tag:'paranoia-level/3',\ tag:'OWASP_CRS',\ tag:'capec/1000/210/272',\ ver:'OWASP_CRS/3.3.2',\ severity:'CRITICAL',\ chain" SecRule REQUEST_HEADERS:Cache-Control "!@rx ^(?:(?:max-age=[0-9]+|min-fresh=[0-9]+|no-cache|no-store|no-transform|only-if-cached|max-stale(?:=[0-9]+)?)(\s*\,\s*|$)){1,7}$" \ "setvar:'tx.anomaly_score_pl3=+%{tx.critical_anomaly_score}'" SecRule TX:EXECUTING_PARANOIA_LEVEL "@lt 4" "id:920017,phase:1,pass,nolog,skipAfter:END-REQUEST-920-PROTOCOL-ENFORCEMENT" SecRule TX:EXECUTING_PARANOIA_LEVEL "@lt 4" "id:920018,phase:2,pass,nolog,skipAfter:END-REQUEST-920-PROTOCOL-ENFORCEMENT" # # -= Paranoia Level 4 =- (apply only when tx.executing_paranoia_level is sufficiently high: 4 or higher) # # # This is a stricter sibling of rule 920200 # SecRule REQUEST_BASENAME "@endsWith .pdf" \ "id:920202,\ phase:2,\ block,\ t:none,\ msg:'Range: Too many fields for pdf request (6 or more)',\ logdata:'%{MATCHED_VAR}',\ tag:'application-multi',\ tag:'language-multi',\ tag:'platform-multi',\ tag:'attack-protocol',\ tag:'OWASP_CRS',\ tag:'capec/1000/210/272',\ tag:'paranoia-level/4',\ ver:'OWASP_CRS/3.3.2',\ severity:'WARNING',\ chain" SecRule REQUEST_HEADERS:Range|REQUEST_HEADERS:Request-Range "@rx ^bytes=(?:(?:\d+)?-(?:\d+)?\s*,?\s*){6}" \ "setvar:'tx.anomaly_score_pl4=+%{tx.warning_anomaly_score}'" # # This is a stricter sibling of 920270. # # This rule is also triggered by the following exploit(s): # [ SAP CRM Java vulnerability CVE-2018-2380 - Exploit tested: https://www.exploit-db.com/exploits/44292 ] # SecRule ARGS|ARGS_NAMES|REQUEST_BODY "@validateByteRange 38,44-46,48-58,61,65-90,95,97-122" \ "id:920273,\ phase:2,\ block,\ t:none,t:urlDecodeUni,\ msg:'Invalid character in request (outside of very strict set)',\ logdata:'%{MATCHED_VAR_NAME}=%{MATCHED_VAR}',\ tag:'application-multi',\ tag:'language-multi',\ tag:'platform-multi',\ tag:'attack-protocol',\ tag:'OWASP_CRS',\ tag:'capec/1000/210/272',\ tag:'paranoia-level/4',\ ver:'OWASP_CRS/3.3.2',\ severity:'CRITICAL',\ setvar:'tx.anomaly_score_pl4=+%{tx.critical_anomaly_score}'" # # This is a stricter sibling of 920270. # SecRule REQUEST_HEADERS|!REQUEST_HEADERS:User-Agent|!REQUEST_HEADERS:Referer|!REQUEST_HEADERS:Cookie|!REQUEST_HEADERS:Sec-Fetch-User "@validateByteRange 32,34,38,42-59,61,65-90,95,97-122" \ "id:920274,\ phase:2,\ block,\ t:none,t:urlDecodeUni,\ msg:'Invalid character in request headers (outside of very strict set)',\ logdata:'%{MATCHED_VAR_NAME}=%{MATCHED_VAR}',\ tag:'application-multi',\ tag:'language-multi',\ tag:'platform-multi',\ tag:'attack-protocol',\ tag:'OWASP_CRS',\ tag:'capec/1000/210/272',\ tag:'paranoia-level/4',\ ver:'OWASP_CRS/3.3.2',\ severity:'CRITICAL',\ setvar:'tx.anomaly_score_pl4=+%{tx.critical_anomaly_score}'" # # This is a stricter sibling of 920270. # The 'Sec-Fetch-User' header may contain the '?' (63) character. # Therefore we exclude this header from rule 920274 which forbids '?'. # https://www.w3.org/TR/fetch-metadata/#http-headerdef-sec-fetch-user # SecRule REQUEST_HEADERS:Sec-Fetch-User "@validateByteRange 32,34,38,42-59,61,63,65-90,95,97-122" \ "id:920275,\ phase:2,\ block,\ t:none,t:urlDecodeUni,\ msg:'Invalid character in request headers (outside of very strict set)',\ logdata:'%{MATCHED_VAR_NAME}=%{MATCHED_VAR}',\ tag:'application-multi',\ tag:'language-multi',\ tag:'platform-multi',\ tag:'attack-protocol',\ tag:'OWASP_CRS',\ tag:'capec/1000/210/272',\ tag:'paranoia-level/4',\ ver:'OWASP_CRS/3.3.2',\ severity:'CRITICAL',\ setvar:'tx.anomaly_score_pl4=+%{tx.critical_anomaly_score}'" # -=[ Abnormal Character Escapes ]=- # # [ Rule Logic ] # Consider the following payload: arg=cat+/e\tc/pa\ssw\d # Here, \s and \d were only used to obfuscate the string passwd and a lot of # parsers will silently ignore the non-necessary escapes. The case with \t is # a bit different though, as \t is a natural escape for the TAB character, # so we will avoid this (and \n, \r, etc.). # # This rule aims to detect non-necessary, abnormal escapes. You could say it is # a nice way to forbid the backslash character where it is not needed. # # This is a new rule at paranoia level 4. We expect quite a few false positives # for this rule and we will later evaluate if the rule makes any sense at all. # The rule is redundant with 920273 and 920274 in PL4. But if the rule proofs # to be useful and false positives remain at a reasonable level, then it might # be shifted to PL3 in a future release, where it would be the only rule # covering the backslash escape. # # We forbid backslashes followed by a list of basic ascii characters - unless # the backslash is preceded by another backslash. # # This rule is also triggered by the following exploit(s): # [ SAP CRM Java vulnerability CVE-2018-2380 - Exploit tested: https://www.exploit-db.com/exploits/44292 ] # SecRule REQUEST_URI|REQUEST_HEADERS|ARGS|ARGS_NAMES "@rx (?:^|[^\\\\])\\\\[cdeghijklmpqwxyz123456789]" \ "id:920460,\ phase:2,\ block,\ capture,\ t:none,t:urlDecodeUni,t:htmlEntityDecode,t:lowercase,\ log,\ msg:'Abnormal character escapes in request',\ logdata:'Matched Data: %{TX.0} found within %{MATCHED_VAR_NAME}: %{MATCHED_VAR}',\ tag:'application-multi',\ tag:'language-multi',\ tag:'platform-multi',\ tag:'attack-protocol',\ tag:'paranoia-level/4',\ tag:'OWASP_CRS',\ tag:'capec/1000/153/267',\ ctl:auditLogParts=+E,\ ver:'OWASP_CRS/3.3.2',\ severity:'CRITICAL',\ setvar:'tx.http_violation_score=+%{tx.critical_anomaly_score}',\ setvar:'tx.anomaly_score_pl4=+%{tx.critical_anomaly_score}'" # # -= Paranoia Levels Finished =- # SecMarker "END-REQUEST-920-PROTOCOL-ENFORCEMENT"