github_mirrors/ModSecurity
3
0
Fork 1
mirror of https://github.com/owasp-modsecurity/ModSecurity.git synced 2026-01-16 08:27:10 +03:00
Code Issues Packages Projects Releases Wiki Activity

More v3 Reference Manual mods

Martin Vierula
2022-09-04 12:53:59 -07:00
parent a7b6dd56b4
commit 695a349ebc
1 changed files with 18 additions and 29 deletions
Download Patch File Download Diff File Expand all files Collapse all files

47
Reference-Manual-(v3.x).mediawiki

@@ -694,7 +694,7 @@ This directive supports multiple parameters, each of which can be a rule ID or a
== SecRuleRemoveByMsg ==
'''Description:''' Removes the matching rules from the current configuration context.
'''Syntax:''' <code>SecRuleRemoveByMsg STRING </code>
'''Syntax:''' <code>SecRuleRemoveByMsg TEXT </code>
'''Example Usage:''' <code>SecRuleRemoveByMsg FAIL </code>
@@ -705,7 +705,7 @@ Normally, you would use SecRuleRemoveById to remove rules, but this directive su
== SecRuleRemoveByTag ==
'''Description:''' Removes the matching rules from the current configuration context.
'''Syntax:''' <code>SecRuleRemoveByTag STRING </code>
'''Syntax:''' <code>SecRuleRemoveByTag TEXT </code>
'''Example Usage:''' <code>SecRuleRemoveByTag attack-dos </code>
@@ -786,7 +786,7 @@ end
== SecRuleUpdateActionById ==
'''Description:''' Updates the action list of the specified rule.
'''Syntax:''' <code>SecRuleUpdateActionById RULEID[:offset] ACTIONLIST</code>
'''Syntax:''' <code>SecRuleUpdateActionById RULEID ACTIONLIST</code>
'''Example Usage:''' <code>SecRuleUpdateActionById 12345 "deny,status:403"</code>
@@ -801,7 +801,7 @@ SecRule ARGS attack "phase:2,id:12345,t:lowercase,t:none,t:compressWhitespace,de
</pre>
The addition of t:none will neutralize any previous transformation functions specified (t:lowercase, in the example).
; Note : If the target rule is a chained rule, you must currently specify chain in the SecRuleUpdateActionById action list as well. This will be fixed in a future version.
; Note : If the target rule is a chained rule, action updates may only be made to the main (first) rule in the chain.
== SecRuleUpdateTargetById ==
'''Description:''' Updates the target (variable) list of the specified rule.
@@ -1203,11 +1203,10 @@ Contains a list of form fields that were used for file upload. Available only on
== FULL_REQUEST ==
Contains the complete request: Request line, Request headers and Request body (if any).
The last available only if SecRequestBodyAccess was set to On. Note that all properties of SecRequestBodyAccess will be respected here, such as: SecRequestBodyLimit.
<code>SecRule FULL_REQUEST "User-Agent: ModSecurity Regression Tests" "id:21"</code>
; Note : Available on version 2.8.0+
; Note : The current implementation appears to omit the Request line
== FULL_REQUEST_LENGTH ==
Represents the amount of bytes that FULL_REQUEST may use.
@@ -1337,17 +1336,16 @@ IQ %{MULTIPART_INVALID_QUOTING}, \
IQ %{MULTIPART_INVALID_HEADER_FOLDING}, \
FE %{MULTIPART_FILE_LIMIT_EXCEEDED}'"
</pre>
The multipart/form-data parser was upgraded in ModSecurity v2.1.3 to actively look for signs of evasion. Many variables (as listed above) were added to expose various facts discovered during the parsing process. The MULTIPART_STRICT_ERROR variable is handy to check on all abnormalities at once. The individual variables allow detection to be fine-tuned according to your circumstances in order to reduce the number of false positives.
The multipart/form-data parser actively looks for certain signs of evasion. Many variables (as listed above) expose various facts discovered during the parsing process. The MULTIPART_STRICT_ERROR variable is handy to check on all abnormalities at once. The individual variables allow detection to be fine-tuned according to your circumstances in order to reduce the number of false positives.
== MULTIPART_UNMATCHED_BOUNDARY ==
Set to 1 when, during the parsing phase of a multipart/request-body, ModSecurity encounters what feels like a boundary but it is not. Such an event may occur when evasion of ModSecurity is attempted.
The intention of this variable is to identify possible evasion attempts by identifying lines that begin with '--' but are followed by characters such that it is not a match to the boundary. Even in its original implementation (in ModSecurity v2) this detection was known to be prone to false positives. A change made in ModSecurity v3 resulted in two detection variations, one that was still prone to false positives, and a revised detection that will detect very little. The ongoing utility and suitability of this detection is subject to review.
The best way to use this variable is as in the example below:
<pre>
SecRule MULTIPART_UNMATCHED_BOUNDARY "!@eq 0" \
"phase:2,id:31,t:none,log,deny,msg:'Multipart parser detected a possible unmatched boundary.'"
</pre>
Change the rule from blocking to logging-only if many false positives are encountered.
Set to either 1 or 2 when, during the parsing phase of a multipart/request-body, ModSecurity encounters what feels like a boundary but it is not.
See the description of rule 200004 in modsecurity.conf-recommended for more detail.
You can also change the rule from blocking to logging-only if many false positives are encountered.
== OUTBOUND_DATA_ERROR ==
This variable will be set to 1 when the response body size is above the setting configured by SecResponseBodyLimit directive. Your policies should always contain a rule to check this variable. Depending on the rate of false positives and your default policy you should decide whether to block or just warn when the rule is triggered.
@@ -1357,9 +1355,9 @@ The best way to use this variable is as in the example below:
<code>SecRule OUTBOUND_DATA_ERROR "@eq 1" "phase:1,id:32,t:none,log,pass,msg:'Response Body Larger than SecResponseBodyLimit Setting'"</code>
== PATH_INFO ==
Contains the extra request URI information, also known as path info. (For example, in the URI /index.php/123, /123 is the path info.) Available only in embedded deployments.
Contains the request URI information that precedes any '?' character.
<code>SecRule PATH_INFO "^/(bin|etc|sbin|opt|usr)" "id:33"</code>
<code>SecRule PATH_INFO "^/(php)" "id:33"</code>
== PERF_ALL ==
Not supported in v3
@@ -2870,11 +2868,7 @@ SecRule REMOTE_ADDR "@ipMatch 192.168.1.100,192.168.1.50,10.10.50.0/24" "id:162"
short alias for ipMatchFromFile
== ipMatchFromFile ==
'''Description:''' Performs a fast ipv4 or ipv6 match of REMOTE_ADDR variable, loading data from a file. Can handle the following formats:
*Full IPv4 Address - 192.168.1.100
*Network Block/CIDR Address - 192.168.1.0/24
*Full IPv6 Address - 2001:db8:85a3:8d3:1319:8a2e:370:7348
*Network Block/CIDR Address - 2001:db8:85a3:8d3:1319:8a2e:370:0/24
'''Description:''' Performs a fast ipv4 or ipv6 match of REMOTE_ADDR variable, loading data from a file. The same formats are suppored as with ipMatch.
'''Examples:'''
@@ -2889,9 +2883,7 @@ The file ips.txt may contain:
10.0.0.0/8
</pre>
; Note : As of v2.9.0-RC1 this operator also supports to load content served by an HTTPS server.
; Note : When used with content served by a HTTPS server, the directive SecRemoteRulesFailAction can be used to configure a warning instead of an abort, when the remote content could not be retrieved.
; Note : This operator also supports loading content served by an HTTPS server.
== le ==
'''Description:''' Performs numerical comparison and returns true if the input value is less than or equal to the operator parameter. Macro expansion is performed on the parameter string before comparison.
@@ -3043,7 +3035,7 @@ SecRule ARGS:foo "!@streq bar" "id:176"
</pre>
== strmatch ==
'''Description:''' Performs a string match of the provided word against the desired input value. The operator uses the pattern matching Boyer-Moore-Horspool algorithm, which means that it is a single pattern matching operator. This operator performs much better than a regular expression.
'''Description:''' Returns true if the parameter string is found anywhere in the input. Macro expansion is performed on the parameter string before comparison. The implementation of this operator is currently comparable to that of the contains operator.
'''Example:'''
<pre>
@@ -3051,9 +3043,6 @@ SecRule ARGS:foo "!@streq bar" "id:176"
SecRule REQUEST_HEADERS:User-Agent "@strmatch WebZIP" "id:177"
</pre>
; Note : Starting on ModSecurity v2.6.0 this operator supports a snort/suricata content style. ie: "@strmatch A|42|C|44|F".
== unconditionalMatch ==
'''Description:''' Will force the rule to always return true. This is similar to SecAction however all actions that occur as a result of a rule matching will fire such as the setting of MATCHED_VAR. This can also be part a chained rule.
@@ -3119,7 +3108,7 @@ SecRule XML "@validateSchema /path/to/xml.xsd" "phase:2,id:191,deny,msg:'Failed
'''Example:'''
<pre>
# Validate URL-encoded characters in the request URI
SecRule REQUEST_URI_RAW "@validateUrlEncoding" "id:192"
SecRule REQUEST_URI_RAW "@validateUrlEncoding" "id:192,phase:1"
</pre>
ModSecurity will automatically decode the URL-encoded characters in request parameters, which means that there is little sense in applying the @validateUrlEncoding operator to them —that is, unless you know that some of the request parameters were URL-encoded more than once. Use this operator against raw input, or against the input that you know is URL-encoded. For example, some applications will URL-encode cookies, although that’s not in the standard. Because it is not in the standard, ModSecurity will neither validate nor decode such encodings.