-
Notifications
You must be signed in to change notification settings - Fork 605
matchzones bnf
Match Zones mz are present in rules and whitelists. It is used to specify where a pattern should be searched (rules) or where it should be allowed (whitelist).
Please note that matchzones behave a bit differently in rules and whitelists : In rules each condition is OR (ie. in BODY
or in HEADERS
),
while in whitelist it's AND (ie. url must be /foo
and exception must happen in ARGS
)
4 main zones exist : URL, ARGS, HEADERS, BODY, and matchzone can be more or less restrictive.
A mz can be wide :
-
ARGS
: GET args -
HEADERS
: HTTP Headers -
BODY
: POST args (and RAW_BODY) -
URL
: The URL itself (before '?')
Or more specific :
-
$ARGS_VAR:string
: named GET argument -
$HEADERS_VAR:string
: named HTTP header -
$BODY_VAR:string
: named POST argument
Sometime, regular expressions are needed (ie. variable names can vary) :
-
$HEADERS_VAR_X:regex
: regex matching a named HTTP header (>= 0.52) -
$ARGS_VAR_X:regex
: regex matching the name of a GET argument (>= 0.52) -
$BODY_VAR_X:regex
: regex matching the name of a POST argument (>= 0.52)
A matchzone can be restricted to a specific URL : (but is not a zone on its own)
-
$URL:string
: restricted to this url -
$URL_X:regex
: restricted to url matching regex (>= 0.52)
A matchzone that targets BODY,HEADERS,ARGS can add |NAME
to specify the target is not
the content of a variable, but its name itself.
It is useful in specific contexts (ie. whitelist [ ]
in form var names on url /foo)
BasicRule id:1310,1311 "mz:$URL:/foo|BODY|NAME";
more specific, match-zones :
-
FILE_EXT
: Filename (in a multipart POST containing a file) -
RAW_BODY
: A raw, unparsed representation of the BODY of a http request (>= 0.55rc0)
A matchzone is a combination of one or several zone with an optional url.
In most situations, variable name and url can be predicted, and a static mz can be created :
When regular expressions are needed :
note: You CANNOT mix regex ($URL_X
) and static ($ARGS_VAR
) in a rule.
$URL and $URL_X are only used to restrict the scope of a matchzone, and are not specifying the zone.
In whitelist context, all conditions must be satisfied :
BasicRule wl:X "mz:$ARGS_VAR:foo|$URL:/bar";
id X is whitelisted in GET variable 'foo' on URL '/bar'
In rules context, $URL
or $URL_X
must be satisfied if present. Any other condition is treated as OR (opposite to whitelists).
BasicRule str:Y id:X "mz:ARGS|BODY";
pattern 'Y' will be matched against any GET and POST arguements
BasicRule str:Y id:X "mz:ARGS|BODY|$URL:/foo";
pattern 'Y' will be matched against any GET and POST arguements as long as URL is /foo
Matchzones composed of static ($*_VAR:
$URL:
) matchzones are stored in hashtables, and thus optimal.
Regex matchzones ($*_VAR_X:
$URL_X:
) require more runtime processing.
It is not possible to mix static and regex matchzone in a same rule/whitelist : mz:$ARGS_VAR_X:^foo$|$URL:/x
or mz:$URL_X:/foo|$ARGS_VAR:x
are wrong.