 |  |
| |
A number of operators can be used in rules, as documented below. The operator syntax used the "@" symbol followed by the specific operator name.
Description: This operator is a numerical comparison and stands for "equal to."
Example:
SecRule &REQUEST_HEADERS_NAMES "@eq 15"Description: This operator is a numerical comparison and stands for "greater than or equal to."
Example:
SecRule &REQUEST_HEADERS_NAMES "@ge 15"Description: This operator is a numerical comparison and stands for "greater than."
Example:
SecRule &REQUEST_HEADERS_NAMES "@gt 15"Description: Executes the external script/binary given as parameter to the operator against every file extracted from the request.
Example:
SecRule FILES_TMPNAMES "@inspectFile /opt/apache/bin/inspect_script.pl"Description: This operator is a numerical comparison and stands for "less than or equal to."
Example:
SecRule &REQUEST_HEADERS_NAMES "@le 15"Description: This operator is a numerical comparison and stands for "less than."
Example:
SecRule &REQUEST_HEADERS_NAMES "@lt 15"Description: Look up the parameter in the RBL given as parameter. Parameter can be an IPv4 address, or a hostname.
Example:
SecRule REMOTE_ADDR "@rbl sc.surbl.org"Description: Regular expression operator. This is the default operator, so if the "@" operator is not defined, it is assumed to be rx.
Example:
SecRule REQUEST_HEADERS:User-Agent "@rx nikto"Note
Regular expressions are handled by the PCRE library (http://www.pcre.org). ModSecurity compiles its regular expressions with the following settings:
The entire input is treated as a single line, even when there are newline characters present.
All matches are case-sensitive. If you do not care about case
sensitivity you either need to implement the lowercase transformational function, or
use the per-pattern(?i)modificator, as allowed by
PCRE.
The PCRE_DOTALL and
PCRE_DOLLAR_ENDONLY flags are set
during compilation, meaning a single dot will match any character,
including the newlines and a $
end anchor will not match a trailing newline charater.
Description: Validates the byte range used in the variable falls into the specified range.
Example:
SecRule ARG:text "@validateByteRange 10, 13, 32-126"Note
You can force requests to consist only of bytes from a certain
byte range. This can be useful to avoid stack overflow attacks (since
they usually contain "random" binary content). Default range values are
0 and 255, i.e. all byte values are allowed. This directive does not
check byte range in a POST payload when
multipart/form-data encoding (file upload) is used.
Doing so would prevent binary files from being uploaded. However, after
the parameters are extracted from such request they are checked for a
valid range.
validateByteRange is similar to the ModSecurity 1.X SecFilterForceByteRange Directive however since it works in a rule context, it has the following differences:
You can specify a different range for different variables.
It has an "event" context (id, msg....)
It is executed in the flow of rules rather than being a built in pre-check.
Description: This operator requires the request body to be processed as XML.
Example:
SecDefaultAction log,deny,status:403,phase:2
SecRule REQUEST_HEADERS:Content-Type ^text/xml$ \
phase:1,t:lowercase,nolog,pass,ctl:requestBodyProcessor=XML
SecRule REQBODY_PROCESSOR "!^XML$" nolog,pass,skip:1
SecRule XML "@validateDTD /path/to/apache2/conf/xml.dtd"Description: This operator requires the request body to be processed as XML.
Example:
SecDefaultAction log,deny,status:403,phase:2
SecRule REQUEST_HEADERS:Content-Type ^text/xml$ \
phase:1,t:lowercase,nolog,pass,ctl:requestBodyProcessor=XML
SecRule REQBODY_PROCESSOR "!^XML$" nolog,pass,skip:1
SecRule XML "@validateSchema /path/to/apache2/conf/xml.xsd"This operator requires request body to be processed as XML.
Description: Verifies the encodings used in the variable (if any) are valid.
Example:
SecRule ARGS "@validateUrlEncoding"Note
URL encoding is an HTTP standard for encoding byte values within a
URL. The byte is escaped with a % followed by two hexadecimal values
(0-F). This directive does not check encoding in a POST payload when the
multipart/form-data encoding (file upload) is used.
It is not necessary to do so because URL encoding is not used for this
encoding.
Description: Verifies the variable is a valid UTF-8 encoded string.
Example:
SecRule ARGS "@validateUtf8Encoding"Note
UTF-8 encoding is valid on most web servers. Integer values between 0-65535 are encoded in a UTF-8 byte sequence that is escaped by percents. The short form is two bytes in length.
check for three types of errors:
Not enough bytes. UTF-8 supports two, three, four, five, and six byte encodings. ModSecurity will locate cases when a byte or more is missing.
Invalid encoding. The two most significant bits in most characters are supposed to be fixed to 0x80. Attackers can use this to subvert Unicode decoders.
Overlong characters. ASCII characters are mapped directly into the Unicode space and are thus represented with a single byte. However, most ASCII characters can also be encoded with two, three, four, five, and six characters thus tricking the decoder into thinking that the character is something else (and, presumably, avoiding the security check).