Manual Chapter :
Signature Options
Applies To:
Show Versions
BIG-IP ASM
- 17.1.2, 17.1.1, 17.1.0, 17.0.0, 16.1.5, 16.1.4, 16.1.3, 16.1.2, 16.1.1, 16.1.0, 16.0.1, 16.0.0, 15.1.9, 15.1.8, 15.1.7, 15.1.6, 15.1.5, 15.1.4, 15.1.3, 15.1.2, 15.1.1, 15.1.0, 15.0.1, 15.0.0, 14.1.5, 14.1.4, 14.1.3, 14.1.2, 14.1.0
Signature Options
Keyword summary
The keywords, generally referred to as
scopes
, are used in signatures to
search for specific fixed strings in different parts of the input. This table summarizes the
keywords that you can use in signatures, including the reference keyword, which is not a
scope.Keyword | Use |
|---|---|
content
| Matches the full content. |
uricontent
| Matches the URI, including the query string (unless using the
objonly modifier). |
headercontent
| Matches the HTTP header. |
valuecontent
| Matches an alphanumeric user-input parameter (or an extra-normalized parameter,
if using the norm modifier); used for parameter values, XML
objects, JSON/GWT objects, XML/JSON parameters, and cookies. When a signature
includes the valuecontent keyword, XML payloads are
examined.The valuecontent parameter
replaces the paramcontent parameter that was used in Application Security Manager versions prior to 10.0. |
reference
| Provides an external link to documentation and other information for the
rule. |
Modifiers summary
The modifiers alter the meaning of keywords used in a signature. This table summarizes
the modifiers.
Modifier | Usage |
|---|---|
depth
| Specifies that the preceding keyword is found not more than X bytes into the
appropriate scope. This is an absolute modifier. |
distance
| Specifies that the preceding keyword is found not less than X bytes after the
prior keyword. This is a relative modifier. |
gwtonly
| Applies the signature if the request contains Google Web Toolkit (GWT) content.
Used with the valuecontent keyword. |
httponly
| Matches on parameters when used with the valuecontent
keyword. |
jsononly
| Applies the signature if the request contains JSON content. Used with the
valuecontent keyword. |
nocase
| Makes the preceding keyword not case-sensitive. |
norm
| Matches the preceding parameter to which additional normalizations have been
applied. |
objonly
| Limits the scope of the preceding uricontent keyword to the
URI part only. |
offset
| Specifies that the preceding keyword is found not less than X bytes into the
appropriate scope. This is an absolute modifier. |
plaintextonly
| Applies the signature if the request contains plain text content. Used with the
valuecontent keyword. |
within
| Specifies that the preceding keyword is found not more than X bytes after the
prior keyword. This is a relative modifier. |
xmlonly
| Applies the signature if the request contains XML content. Used with the
valuecontent keyword. |
Regular expression scopes
Scopes
define the portion of a request or response that the regular expression
keyword (pcre
, re2
, ipp
) applies
to. This table lists the rule flags to use for different scopes in an attack or bot signature. Rule flag |
Scope |
|---|---|
C
|
Full content of the request or response body |
U |
URI, including query string |
O |
URL only (URI without query string) |
H |
HTTP headers |
V |
HTTP parameters in query string or POST data |
N
|
HTTP parameters with additional normalizations |
In signatures, rules for responses can contain only rule options and modifiers that apply
to the entire content of the response. In other words, for response rules, you can use the
content
and reference
keywords, and any
applicable modifiers for these keywords. You can also use the pcre
,
re2
, or ipp
rule options for responses, as
long as you do not use a scope modifier for them. Keyword and flag compatibility
These tables describe the compatibility between keyword rule options themselves, and
between keywords and regular expression (regex) flags. You can refer to these tables when
developing attack or bot signatures to understand which keywords and flags can be used together.
"Valid" means that you can use the combination together in a signature. "Invalid" means you
cannot use the two together.
Keywords/Keywords |
content |
uricontent |
headercontent |
paramcontent |
valuecontent |
|---|---|---|---|---|---|
content |
Valid |
Valid |
Valid |
Invalid |
Invalid |
uricontent |
Valid |
Valid |
Valid |
Invalid |
Invalid |
headercontent |
Valid |
Valid |
Valid |
Invalid |
Invalid |
paramcontent |
Invalid |
Invalid |
Invalid |
Valid |
Invalid |
valuecontent |
Invalid |
Invalid |
Invalid |
Invalid |
Valid |
Keywords/Flags |
None |
U |
O |
H |
P |
N |
V |
|---|---|---|---|---|---|---|---|
content |
Valid |
Valid |
Valid |
Valid |
Invalid |
Invalid |
Invalid |
uricontent |
Valid |
Valid |
Valid |
Valid |
Invalid |
Invalid |
Invalid |
headercontent |
Valid |
Valid |
Valid |
Valid |
Invalid |
Invalid |
Invalid |
paramcontent |
Invalid |
Invalid |
Invalid |
Invalid |
Valid |
Valid |
Invalid |
valuecontent |
Invalid |
Invalid |
Invalid |
Invalid |
Invalid |
Invalid |
Valid |
Flags/Flags |
None |
U |
O |
H |
P |
N |
V |
|---|---|---|---|---|---|---|---|
None |
Valid |
Valid |
Valid |
Valid |
Invalid |
Invalid |
Invalid |
U |
Valid |
Valid |
Valid |
Valid |
Invalid |
Invalid |
Invalid |
O |
Valid |
Valid |
Valid |
Valid |
Invalid |
Invalid |
Invalid |
H |
Valid |
Valid |
Valid |
Valid |
Invalid |
Invalid |
Invalid |
N |
Invalid |
Invalid |
Invalid |
Invalid |
Valid |
Valid |
Invalid |
V (See note) |
Invalid |
Invalid |
Invalid |
Invalid |
Invalid |
Invalid |
Valid |
You should use V (with
httponly
if necessary) instead of the
deprecated P regex flag.About normalization
For the URI and parameter scopes, the system always applies a normalization process before
applying the rule options to the signature. For parameters, you can include the
norm
modifier with the valuecontent
keyword to cause
the system to perform additional normalizations to make the content more regular. The additional
parameter normalizations also help mitigate common evasion techniques used in XSS, SQL-Injection,
and Command Execution attacks. Therefore, it is a good idea to use additional normalizations, by
default.Composite rules
You can combine rule options together to form
composite rules
. By using keywords
combined with modifiers, the rule options merge to form a single assertion. Rule options are
combined using an implied AND operator; this makes it so that all conditions in the rule must be
met in order to satisfy the rule as a whole. Consider the following points when combining rule options:
- You can combine different scopes within one rule as long as you do not use any relative modifiers. For example, this rule is invalid because it includes two scopes (contentanduricontent), andwithin, a relative modifier:content:"ABC"; uricontent:"XYZ"; within:10;
- You cannot combine thevaluecontent,pcre P, orre2 Prule options with other scope keywords. The parameter rule options must be the only scope keywords in their respective rules. You can, however, combine the parameter keywords with additionalvaluecontent,pcre P, orre2 Pkeywords, including those with thenormmodifier (orN, forpcreorre2).
