naxsi

Naxsi Matchzones

Matchzones, denoted by the prefix mz:, are crucial components of rules and whitelists. They act like filters to define specific locations where a pattern should be searched or allowed.

Here’s how they function differently based on the context:

📣 Important

Naxsi decodes any url-encoded or hexadecimal sequence, this means the string or regex to search for must be of the decoded content (this applies also to URLs).

Example: 1%20UnioN%20SeLEct%201 becomes 1 UnioN SeLEct 1 before applying rules.

Any Matchzone

This special matchzone designated by ANY allows to define rules and whitelists which matches in any area of a request.

For instance, the rule MainRule id:12345 "s:$FOO:8,$BAR:4" "str:malicious" "mz:ANY"; is equivalent of writing the following rules but in one line.

MainRule id:12345 "s:$FOO:8,$BAR:4" "str:malicious" "mz:ARGS|HEADERS|BODY|URL";
MainRule id:12345 "s:$FOO:8,$BAR:4" "str:malicious" "mz:RAW_BODY";
MainRule id:12345 "s:$FOO:8,$BAR:4" "str:malicious" "mz:FILE_EXT";

📣 Important

This can be used also for whitelists, but it is possible to disable a rule by just not declaring any matchzone (see the Whitelist matchzones notes).

Filter by HTTP Headers

HTTP headers let the client and the server pass additional information with a message in a request or response; Naxsi allows to filter rules and whitelists by headers as follows:

Filter by Any HTTP header value

This Matchzone designated by HEADERS is specifically tailored to identify only the content found within HTTP headers.

For instance:

Filter by Any HTTP header name

This Matchzone designated by HEADERS|NAME is specifically tailored to identify only the name of the header found within HTTP request.

For instance:

Filter by HTTP header name

This Matchzone designated by $HEADERS_VAR:foo and $HEADERS_VAR_X:^foo$ is specifically tailored to identify only the content found within an HTTP header named foo.

For instance:

📣 Important

This can be mixed with |NAME to perform the filtering at argument name instead of value. Example: mz:$HEADERS_VAR_X:^foo\d+$|NAME matches only the HTTP header named foo<number>.

Filter by GET query

HTTP GET requests can carry information, referred as queries, in the form of key=value pairs; Naxsi allows to filter rules and whitelists by these arguments as follows:

Filter by Any GET query value

This Matchzone designated by ARGS is specifically tailored to identify only the value found within HTTP GET query.

For instance:

Filter by Any GET query name

This Matchzone designated by ARGS|NAME is specifically tailored to identify only the name of the GET query found within HTTP request.

For instance:

Filter by GET query value or name

This Matchzone designated by $ARGS_VAR:foo and $ARGS_VAR_X:^foo$ is specifically tailored to identify only the content found within an HTTP GET query named foo.

For instance:

📣 Important

This can be mixed with |NAME to perform the filtering at argument name instead of value. Example: mz:$ARGS_VAR_X:^foo\d+$|NAME matches only the GET query named foo<number>.

Filter by POST Requests

HTTP POST requests carries information in the HTTP body; the request data can have multiple formats:

Naxsi allows to filter these in rules and whitelists as follows:

Filter by Any application/x-www-form-urlencoded Value

This Matchzone designated by BODY is specifically tailored to identify only the value found within HTTP POST body.

For instance:

Filter by Any application/x-www-form-urlencoded Key

This Matchzone designated by BODY|NAME is specifically tailored to identify only the name of the header found within HTTP request.

For instance:

Filter by Any application/x-www-form-urlencoded Key and Value

This Matchzone designated by $BODY_VAR:foo and $BODY_VAR_X:^foo$ is specifically tailored to identify only the content found within an HTTP POST body named foo.

For instance:

📣 Important

This can be mixed with |NAME to perform the filtering at argument name instead of value. Example: mz:$BODY_VAR_X:^foo\d+$|NAME matches only the POST argument named foo<number>.

Filter by Any multipart/form-data filename

This Matchzone designated by FILE_EXT is specifically tailored to match only the filename found within HTTP multipart POST request.

For instance:

Filter by HTTP Raw Body

This Matchzone designated by RAW_BODY is specifically tailored to match any byte sequence in an unparsed HTTP body.

For instance:

📣 Important

This matchzone is internally converted as BODY zone, thus the BasicRule wl:12345 "mz:BODY"; and BasicRule wl:12345 "mz:RAW_BODY"; are equivalent.

Filter by HTTP URL

Naxsi supports filtering by HTTP URL as follows:

Filter by HTTP URL (global)

This Matchzone designated by URL is specifically tailored to identify only the value found within HTTP URL.

For instance:

📣 Important

This matchzone is globally applied, it is possible to restrict the matchzone to a specific URL or substring in the URL via $URL or $URL_X (see below).

Filter by HTTP URL (restricted)

This Matchzone designated by $URL:/foo and $URL_X:^/foo$ is specifically tailored to identify only the URL containing the string /foo.

These can be mixed with all the previous matchzones as follows:

In rules context, $URL or $URL_X must be satisfied if present. Any other condition is treated as OR (opposite to whitelists).

In whitelist context, all conditions must be satisfied, so a whitelist like BasicRule wl:X "mz:$ARGS_VAR:foo|$URL:/bar"; is interpreted as id X is whitelisted in GET variable foo on URL /bar

⚠️ Warning

You CANNOT mix $URL_X:<regex> and $ARGS_VAR:<string>, $BODY_VAR:<string> and $HEADERS_VAR:<string> in a rule or whitelist.

It is allowed instead to mix $URL_X:<regex> with $ARGS_VAR_X:<regex>, $BODY_VAR_X:<regex> and $HEADERS_VAR_X:<regex> and to mix $URL:<string> with $ARGS_VAR:<string>, $BODY_VAR:<string> and $HEADERS_VAR:<string>.

ℹ️ Info

It is allowed to mix FILE_EXT and RAW_BODY with $URL_X:<regex> and $URL:<string>.

Go Back

Table of Contents.

This site is open source. Improve this page.