We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF or read online on Scribd
You are on page 1/ 10
Table 5.2. Request variables
Variable Description
ARGS Request parameters (tead-only collection)
ARGS_COMBINED_STZE Total sizeof al request parameters combined
ARGS NAMES, Request parameters’ names (cllection
ARGS GET (Query string parameters (read-only coletion)
ARGS_GET_NAMES Avery string parameter’ names (ead-only collection)
ARGS_POST Request body parameters (read-only collection)
ARGS_POST_NAMES Request body parameters’ names (read-only collection)
FILES File names (read-only collection)
FILES_COMBINED_SIZE
FILES_TWPNAHES
PATH_INFO
‘uery_sraine
RENOTE_USe
REQUEST _BASENAME
REQUEST_s00¥
REQUEST_cooKIES
REQUEST _COOKIES_ NAMES
REQUEST FILENAME
REQUEST.
REQUEST.
REQUEST_LINE
REQUEST_METHOD
REQUEST_pROTOCOL
REQUEST_URI
REQUEST _URI_RAw
Combined size ofall uploaded files
File parameter names (read-only collection)
‘list of file sizes (read-only collection)
‘list of temporary file names (read-only collection)
Extra path information
Request querystring
Remote user
Request URI basename
Request body
Request cookies (read-only collection)
Request cookies’ names (read-only collection)
Request URI filename/path
Request headers (collection, read-only)
Request headers’ names (read-only collection)
Request line
Request method
Request protocol
Request URI, convert to exclude hostname
Request URI, as it was presented in the request
Server variables
Server variables contain the pieces of information available to the server, most of them valid
only for the transaction being processed at the moment they are evaluated.
Server variables
68
hylis J. Henderson Table 5.3. Server variables
Variable Description
‘UTH_IVPE ‘Authentication type
REMOTE_ADDR Remate address
REMOTE HOST Remate host
REMOTE_PoRT Remote port
SCRTPT_BASENAME Script basename
SCRIPT_FILENAME Script flename/path
scarPT 1D Script group 1D
SCRLPT_GROUPNAME Script group name
SCRIPT_ODE Script permissions
scart UID Script user ID
SCRIPT_USERNAME Script user name
SERVER_ADDR Sewer address
SERVER_NAME Server name
SERVER_PORT Sewer port
Response variables
Response variables are those extracted from the response part of the transaction that is being
inspected. Most response variables will be available in phase 3. The arguably most impor-
tant response variable, RESPONSE_BODY, is only available in phase 4 (the phase is also called
RESPONSE_BODY).
Table 5.4. Response variables
Variable Description
RESPONSE_BODY Response body
RRESPONSE_CONTENT_LENGTH Response content length
RESPONSE_CONTENT_TYPE Response content type
RESPONSE_HEADERS. Response headers (read-only collection)
RRESPONSE_HEADERS_NAMES Response headers’ names (read-only collection)
RESPONSE_PROTOCOL Response protocol
RESPONSE_STATUS Response status code
70 Chapter 5: Rule Language Overview
perty of Phyls J. Henderson Miscellaneous variables
Miscellaneous variables are exactly what they are called: they are the variables that couldn’t
fit in any other category.
Variable
Description
NIGHEST_SEVERITY
ATCHED_VAR
MATCHED_VAR_NAME
moosec_suito
SESSIONID
UsERID
WeBAPPID
EBSERVER_ERROR_LOG
Highest severity encountered
Contents ofthe last variable that matched
Name ofthe last variable that match
ModSecurity build version fg, 02050102)
Session ID associated with current transaction
User I associated with cutet transaction
‘Web application ID associated with current transaction
Enor messages generated by Apache during current transaction
Parsing flags
Parsing flags are used by ModSecurity to signal important parsing events. The idea is to
avoid taking implicit action (e.g., blocking in response to an invalid request), but allow the
rules to decide what to do.
Table 5.6. Request body parsing v
les
Variable
Description
‘MILTIPART_BOUNDARY_QUOTED
MILTIPART_BoUNDARY_HHITESPACE
MILTIPART_CRLF_LF_LINES
MILTIPART_DATA BEFORE
MILTIPART_DATA_AFTER
MILTIPART_HEADER_FOLDING
MILTIPART_LF_LINE
MILTIPART_SEMICOLON_MISSING
MILTIPART_STRICT_ERROR
MULTIPART_UNMATCHED_BOUNDARY
REQBODY PROCESSOR
REQBODY_PROCESSOR_FRROR
REQBODY_PROCESSOR_ERROR_MSG
Multipart parsing error: quoted boundary encountered
Multipart parsing error: whitespace in boundary
Mutipart parsing error: mined tne endings used
Mutipart parsing error: seen data before first boundary
Muttipart parsing error: seen data after last boundary
Multipart parsing error: header folding used
Mutipart parsing error: LF tine ending detected
Multipart parsing errr: missing semicolon before boundary
‘At least one multipart ertor except MULTIPART_UNVATCHED_BOUNDARY occurred
Mutipart parsing errr: unmatched boundary detected (prane to false positives)
Request processor that handled request body
Request processor eror lag (0 or 1)
Request processor error message
Miscellaneous variables
7
hylis J. Henderson Collections
Collections are the special kind of variables that can contain other variables. With exception
of the persistent collections, all collections are essentially one-off, special variables that give
access to the information to which ModSecurity has access.
Table 5.7. Special collections
Variable Descrintion
ew Environment variables (read-only clleton, although t's possible to use set
var to change
ceo Geo lookup information fromthe lst egeoLockup invocation (read-only calles
tion)
GLOBAL Global information, shared by all processes (read/write collection)
ra IP address data storage readrte colton)
* Transient transaction data (‘ear eleton)
RULE Curent rule metadata (ead-onycoleton)
sesston Session date storage rad/witeclleton
use User data storage (read/write callestion)
xa XI DOM tre (read-only calleton
Time variables
‘Time variables all represent the moment in time when the transaction that ModSecurity is
processing began.
Table 5.8. Time variables
Variable Description
TINE Time (HHMMSS)
TINE_pAY Day of the month (1-31)
‘TINE_gPocH Seconds since January 1, 1970 (e.g, 1251029017)
TINE_HouR Hour ofthe day (0-23)
TINe_HIN Minute of the hour (0-89)
TINE_How Month of the year (0-11)
Tane_sec Seoond ofthe minute (0-58)
‘TINe_WoAY Wook day (0-8)
TIME_YEAR Year
n Chapter 5: Rule Language Overview
Property of Phyllis J. Henderson Operators
In the examples so far the assumption was that we are always going to use regular pat-
tern matching against input. While regular expressions are very useful, there are often times
when you want to do something else. That is when operators come to play. The truth is
that ModSecurity always uses an operator, but that it assumes that you want to use regular
patterns matching unless you specify an operator in a rule. So, to start with, here’s a rule
that explicitly specifies an operator- -the regular pattern matching one!
SecRule ARGS:usernane "@rx *(adnin|xoct)$*
‘The above rule which checks if the requested username is adnin or root. You may have
noticed a few things:
+ Operators begin with a @ character.
+ Operators are always placed at the beginning of the second SecRule token.
+ There's always a space after an operator. Whatever follows the space is the single op-
erator parameter. In the case of the @rx operator, the parameter is a regular expres-
sion,
+ When you have a rule with an explicit operator you'll need to use double quotes
around the token, because there’s always going to be a space character inside the to-
ken. Omitting double quotes would only confuse Apache and cause it to complain.
‘The power of the operators comes from the extensive functionality on offer. String oper-
ators, shown in Table 5.9, “String matching operators”, are most often used. You've seen
plenty examples using regular pattern matching so far. In addition to the simple matching
operators (@beginsWith, @endsWith, etc.), ModSecurity supports parallel matching, where a
large number of patterns can be matched at once. That is what @pm and @pnFronFile are for.
String matching operators
String matching operators all take a string on input and attempt to match it to the provided
parameter. The @rx and épm operators are the ones commonly used, because of their versa-
tility (@x) and speed (@pn), but the remaining operators are also useful, especially if you
need variable expansion, which neither @x nor @pm support.
Operators 3
Property of Phyllis J. Henderson Miscellaneous operators
And, finally, there’s the miscellaneous category (Table 5.12, “Miscellaneous operators”),
which offers some very useful functionality.
Table 5.12. Miscellaneous operators
Operator Description
egealookip Determines the physica location ofan P adress
@inspectFile Invokes an external script to inspect a file
en Looks paameter against aRBL (alte blacklist)
averifyCc Checks if the parameter is a valid credit card number
Actions
Actions make ModSecurity tick. They make it possible to react to events and, more impor-
tantly, they are the glue that hold everything else together and make the advanced features,
possible. They are also the most overloaded element of the rule language. Because of the
constraints of the Apache configuration syntax, within the rule language exists, actions are
used to carry everything other than variables and operators. Actions can be split into 7 cat-
egories.
Disruptive actions
Disruptive actions (Table 5.13, “Disruptive actions”) specify what a rule wants to do on a
match, Each rule must be associated with exactly one disruptive action. The pass action is
the only exception, as it will allow processing to continue when a match occurs. All other
actions from this category will block in some specific way.
Table 5.13. Disruptive actions
Aetion Description
allow ‘Stop processing of one or more remaining phases
block Indicates that a rule wants to block
deny Block transaction with an eror page
drop Close network connection
pass Do not block, goto the next rule
proxy Proxy request to @ backend web server
redirect Redirect request to some other web server
Miscellaneaus operators 8
Property of Phyllis J. Henderson Flow actions
Flow actions (Table 5.14, “Flow actions”) alter the way rules are processed within a phase.
Table 5.14, Flow actions
Action Description
chain Connect two or more rules into a single logical rule
skip Skip over one or more rules that follow
skipafter Skip to the rule or marker wth the provided 1D
Metadata actions
Metadata actions (Table 5.15, “Metadata actions”) provide additional information about
rules. The information is meant to accompany the error messages to make it easier to un-
derstand why they occurred.
Table 5.15. Metadata actions
Aetion Description
id Assign unique ID toa rule
phase Phase fora rule torunin
sg Message string
rev Revision number
severity Severity
tag Tag
Variable actions
Variable actions (Table 5.16, “Variable actions”) deal with variables. They allow you to set,
change and remove variables.
16 (Chapter 6; Rule Language O
Property of Phyllis J. Henderson Table 5.16, Variable actions
Action Description
capture Capture results into one or more variables
deprecatevar Decrease numerical variable value overtime
cexpirevar Remove variable after atime period
initeol Creat anew persistent cllection
setenv Set orremove an environment variable
setvar Set, remove, increment or desrement a variable
setuid Associate current transaction with an application user ID (sername)
setsid Associate current transaction wth an application session ID
Logging actions
Logging actions (Table 5.17, “Logging actions”) influence the way logging is done. The ac-
tions that influence if logging takes place (auditlog, log, noauditlog, and nolog) only con-
trol current rule affects logging if it matches. ‘To control logging for the transaction as a
whole you'll need to use the ct] action.
Table 5.17. Logging actions
sation Description
auditlog Tog curent transaction te aut og
log Log ror message; implies auditog
logéata Log supplied data as part of eror message
noautitlog Do nt log current transection to aut og
neleg Dont lg enor messege; implies noouditlog
sanitisenrg Remove request parameter om ait og
sanitiseMatched Remove parameter in which a match occurred from audit log
sanitiseRequstHeader Remove request header fram aut og
sanitiseResponseHeader Remove response header from audit log
Special actions
Special actions (Table 5.18, “Special actions”) are gateways of sort; they provide access to
another class of functionality. The ct1 action has several sub-actions of its own and allows
engine configuration to be changed only the current transaction. The multiMatch rule acti-
vates a special way of matching in which the rule operator is run after every transformation
Logging actions 7
perty of Phyls J. Henderson (normally, the operator is run only once after all transformations). The t action is used to
specify zero or more transformations that will be applied to variables before an operator
isrun.
Table 5.18. Special actions
Action Description
etl Change configuration of curent transaction
rmultiMatch ‘Activate mutti-matching, where an operator runs after every transformation
t
Specify transformation functions to apply to variables before matching
Miscellaneous actions
Miscellaneous actions (Table 5.
belong in any of the groups.
Table 5.19. Miscellaneous actions
9, “Miscellaneous actions”) contain the actions that don’t
Action Description
append ‘Append content to response body
exec Execute extemal script
pause Pause transaction
prepend Prepend content o response body
Specityrespanse status code to use with deny and redirect
Specity name space for use with XPath expressions
78
Chapter 5: Rule Language Overview
hylis J. Henderson