Applies To:
Show Versions
BIG-IP ASM
- 15.0.1, 15.0.0, 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.
Note: 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 |
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
(content and uricontent), and
within, a relative modifier:
content:"ABC"; uricontent:"XYZ"; within:10;
- You cannot combine the valuecontent, pcre P, or re2 P rule 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 additional valuecontent, pcre P, or re2 P keywords, including those with the norm modifier (or N, for pcre or re2).
