Signature Syntax

The content rule option matches when the specified string is found anywhere in the full content of the request or response.

You can use the content keyword for request or response attack signatures. To apply the signature to responses, note the following:

• Enable the Apply Response Signatures setting for the related file type.
• In the rule itself, set the Apply to option to Response.

   content:"ABC";

The uricontent rule option matches when the specified string is found anywhere in the normalized URI, including the query string. The string match is case-sensitive, and must be exact.

You can use the uricontent keyword for request attack or bot signatures only. You cannot use the objonly flag in bot signatures.

   uricontent:"ABC";

The headercontent rule option matches a specified string that is found anywhere in the HTTP request headers. The string match is case-sensitive, and must be exact.

You can use the headercontent keyword for request attack or bot signatures only. In bot signatures, the useragentonly flag is mandatory.

   headercontent:"ABC";

   headercontent: "MyMaliciousBot"; useragentonly; ipp: "/MyMaliciousBot v0.[0-9]/H";
      useragentonly;

The valuecontent rule option matches when a specified string is found anywhere within a alphanumeric user-input parameter, or if found in the complete payload when the Apply Value and Content Signatures content profile is selected. The system applies valuecontent rules only to parameters defined in the security policy. The rule matches against each parameter separately, on the full name and value pair.

You can use the jsononly, xmlonly, gwtonly, httponly, and plaintextonly modifiers with valuecontent to explicitly enforce signatures on specific profiles.

You can use the valuecontent keyword for request attack signatures only. You cannot combine this scope with any other scope in a single rule.

In other words, you cannot use the valuecontent option with other content rule options. You can disable a parameter signature at both the parameter level, and the security policy level.

   valuecontent:"ABC";
   valuecontent:"ABC"; httponly;
   valuecontent:"ABC"; jsononly;
   valuecontent:"ABC"; plaintextonly;
   valuecontent:"ABC"; xmlonly;

For example, suppose you have the following signature:

valuecontent:"soda";
valuecontent:"bar"; distance 0;

It will match in the following scenarios.

• A request goes to a URL in the form data content profile, and its content is a parameter defined as alphanumeric (like the default wildcard *). It matches a request such as the following:

  POST /a_form_data_url.html HTTP/1.1
  Host: beni.core.com
  
  alpha_numeric_parameter=sodabar

• A request goes to a URL that has Request Body Handling set to Apply value and content signatures. Its content matches a request such as the following:

  POST /a_value_signature_url.html HTTP/1.1
  Host: beni.core.com
  Content-Length: 548
  

  Some other payload with unusual formatting, which is not form data then suddenly sodabar occurs then another payload continues.
• A parameter defined as alphanumeric occurs in the query string:

  GET /some_url.html?alpha_numeric_parameter=sodabar HTTP/1.0

Use the reference rule option in a rule to provide an external reference or link to information related to the rule, its source, or any other relevant documentation.

Here are the reference types that you can use in this rule option:

   reference:url,www.reference.com;
   reference:bugtraq,1234;
   reference:cve,2007-1234;
   reference:nessus,1234;

You can use the nocase modifier with any of the keywords to make it not case-sensitive.

   content:"ABC"; nocase;

You can use the offset modifier to modify keywords in any scope. The scope determines where the offset matching begins. For example, the rule uricontent:"ABC"; offset:10; matches these requests:

   xxxx123456789012345
   GET /234567890ABC ...
   GET /2345678901ABC ...

but not these requests:

   xxxx123456789012345
   GET /23456789ABC ...
   GET /2345678ABC ...  

Here is an example rule with the offset modifier:

   content:"ABC"; offset:10;
   uricontent:"ABC"; offset:10;

The example matches these requests:

   12345678901234567890
   GET /67890ABC ...
   GET /678901ABC ...

but not these:

   12345678901234567890
   GET /6789ABC ...
   GET /678ABC ...

Use the plaintextonly modifier with valuecontent to enforce signatures.

valuecontent:”url=http”; plaintextonly;

Without the plaintextonly keyword, this signature would match any parameter named url that starts with http, possibly causing false positives. With the keyword, the signature has to match the entire string (including the equal sign) inside a WebSocket message, making it a more specific signature.

You can use the depth modifier to modify keywords for any scope. The scope determines where the depth matching begins. For example, the rule uricontent:"ABC"; depth:10; matches these requests:

   xxxx123456789012345
   GET /234567ABC ...
   GET /23456ABC ...

but not these requests:

   xxxx123456789012345
   GET /2345678ABC ...
   GET /23456789ABC ...  

You can combine the offset and depth modifiers to define both the beginning and end boundaries of the area in which the keyword can match. For example, the rule content:"ABC"; offset:10; depth:20; matches these requests:

   1234567890123456789012345
   GET /67890ABC ...
   GET /678901234567ABC ...

but not these requests:

   1234567890123456789012345
   GET /678ABC ...
   GET /6789ABC ...

Here is an example rule with the depth modifier:

   content:"ABC"; depth:10;
   uricontent:"ABC"; depth:10;

The example matches these requests:

   12345678901234567890
   GET /67ABC ...
   GET /6ABC ...

but not these:

   12345678901234567890
   GET /678ABC ...
   GET /6789ABC ...

Use the distance modifier to specify that the previous keyword matches no less than the specified number of bytes from the prior keyword. The distance modifier is similar to the offset modifier. The distance modifier enforces a minimum number of bytes relative to the end of the previously specified keyword, whereas the offset modifier is an absolute value that starts matching from the beginning of the corresponding keyword scope.

Use the distance modifier when the rule includes two keywords, and you want to enforce that the second keyword appears (anywhere) after the first keyword. Note that without the distance modifier, no positional relationship exists between two keywords in a rule. As such, the rule content:"ABC"; content:"XYZ";, without the distance modifier, matches both of these requests:

   GET /ABCXYZ ...
   GET /XYZABC ...

Example rule with the distance modifier:

   content:"ABC"; content:"XYZ"; distance:10;

The example matches these requests:

   xxxxxxxx12345678901234567890
   GET /ABC1234567890XYZ ...
   GET /ABC12345678901XYZ ...

but not these:

   xxxxxxxx12345678901234567890
   GET /ABC123456789XYZ ...
   GET /ABC12345678XYZ ...

Use the within modifier to specify that the previous keyword matches no more than the specified number of bytes from the prior keyword. The within modifier is similar to the depth modifier, except that the within modifier enforces a maximum number of bytes relative to the end of the previously specified keyword, whereas the depth modifier is an absolute value that starts matching from the beginning of the corresponding keyword scope.

You can combine the distance and within modifiers to define both the beginning and end boundaries of the area in which the keyword can match, relative to the end of the previous keyword match.

   xxxxxxxx12345678901234567890 
   GET /ABC1234567890XYZ ... 
   GET /ABC12345678901234567XYZ ...

   xxxxxxxx1234567890123456789012345 
   GET /ABC123456789XYZ ... 
   GET /ABC123456789012345678XYZ ...

   content:"ABC"; content:"XYZ"; within:10;

The example matches these requests:

   xxxxxxxx12345678901234567890
   GET /ABC1234567XYZ ...
   GET /ABC123456XYZ ...

but not these:

   xxxxxxxx12345678901234567890
   GET /ABC12345678XYZ ...
   GET /ABC123456789XYZ ...

Use the objonly modifier with the uricontent keyword to specify that the match must be found within the URI and not the query string. For example, in the URI, GET /index.html?q=1, the object part is /index.html.

   uricontent:"ABC"; objonly;

The example matches these requests:

   GET /ABC ...
   GET /ABC?param=123 ...

but not this request:

   GET /123?param=ABC ...

Use the norm modifier to specify that the system applies additional normalization processes to parameter and value pairs before applying the rule. The additional normalization processes include transformations to mitigate evasion techniques commonly used in cross-site scripting (XSS), SQL-Injection, and Command Execution attacks.

   valuecontent:"ABC"; norm;

When writing rules in user-defined signatures, you use the pipe symbol (|) to escape special characters in keywords. You use the ASCII-equivalent hexadecimal values to represent the characters in the argument and surround them with pipe symbols. The system escapes all of the values that occur between the two pipe symbols in the argument.

You must escape the following characters when using them in a keyword argument:

• Colon (:)
• Semicolon (;)
• Double quotation mark (")
• Backward slash (\)
• Pipe (|)
• All binary characters (not ASCII-printable characters), including:
  • ASCII 0x00 through 0x1F
  • ASCII 0x7F through 0xFF
• The space character (ASCII 0x20)

   content:"ABC|20|XYZ";
   content:"ABC|22 22|XYZ";

In the example, where |20| represents the space character, the first rule matches the string ABC XYZ. In the second rule in the example, where |22 22| represents two double quotation marks, the rule matches the string ABC""XYZ.

Note that there is a different syntax when escaping characters in regular expressions. Refer to the pcre and re2 documentation for details or look online at https://re2.googlecode.com/hg/doc/syntax.html.

You can place the not (!) character in front of a string to make that string an exception to a rule. However, the negative keyword cannot be the only keyword in a signature, so you cannot use the not character (!) without a positive condition before it. A relationship, such as distance, must exist between the negative and positive keywords.

You can use the not (!) character in front of a regular expression even without a non-negative keyword.

Here are some examples of using the not (!) character.

   content:"ABC"; content:!"CDE"; distance:1;
   uricontent:"ABC"; uricontent:!"CDE"; distance:0;
   headercontent:"ABC"; headercontent:!"CDE"; distance:0;
   valuecontent:"ABC"; valuecontent:!"CDE"; distance:0;
   content:"ABC"; pcre:!"/<regex>/";
   re2:!"/<regex>/";

The re2 rule option performs a regular expression match on different parts of the input, and accepts the open-source RE2 regular expression syntax (as of Application Security Manager™ version 11.2). You can find the full syntax at https://re2.googlecode.com/hg/doc/syntax.html. The re2 syntax is similar to the pcre regular expression syntax.

The scope of the match depends on the re2 modifiers that you specify.

   re2:"/regex/[options]";
   re2:!"/regex/[options]";

In regular expressions, you must escape the following characters: period (.), caret (^), dollar sign ($), asterisk (*), plus sign (+), question mark (?), parentheses [( )], left square bracket ([), left curly brace ({), backslash (\), and vertical bar (|); and inside character classes you need to escape caret (^), hyphen (-), right square bracket (]), and backslash (\). Note that when escaping characters in regular expressions using re2, you use re2 escape sequences, and not the pipe symbol, to escape characters.

Note that you do not need to escape semicolons that are not followed by whitespace, such as:

re2: "/soda;bar/";

If an argument requires a semicolon followed by whitespace, you can either escape the semicolon as follows:

re2: "/soda\x3b bar/";

or escape the whitespace (one or more spaces) after the semicolon:

re2: "/soda;\s+bar/";

You can also escape both the semicolon and the whitespace in the same regular expression:

re2: "/soda\x3b\s+bar/";

For the re2 escape sequences, look online at https://re2.googlecode.com/hg/doc/syntax.html.

The pcre rule option performs a regular expression match on different parts of the input, and is based on the Perl-compatible regular expressions (PCRE) syntax.

The scope of the match depends on the PCRE modifiers that you specify. For details about the syntax used within the regular expression itself, refer to the PCRE documentation at pcre.org.

   pcre:"/<regex>/";
   pcre:"/<regex>/<modifiers>";

In regular expressions, you must escape the following characters: period (.), caret (^), dollar sign ($), asterisk (*), plus sign (+), question mark (?), parentheses [( )], left square bracket ([), left curly brace ({), backslash (\), and vertical bar (|); and inside character classes you need to escape caret (^), hyphen (-), right square bracket (]), and backslash (\). Note that pcre has a different syntax (other than the vertical bar) for escaping characters (as explained at pcre.org).

The ipp option, used only for bot signatures, performs a regular expression match on the input (instead of using pcre or re2). (The ipp option is analogous to the Snort keyword pcre.) The ipp option uses an Intel-based regular expression engine (processor-optimized) that is available on the BIG-IP system. For example:

   headercontent: "MyMaliciousBot"; useragentonly; ipp: "/MyMaliciousBot v0.[0-9]/H";
      useragentonly;

This bot signature searches for MyMaliciousBot in the user-agent, and if found, it runs the regular expression "/MyMaliciousBot v0.[0-9]/H" on the user-agent header. The useragentonly modifier narrows down the header scope to the user agent only, and can be used only when the previous modifier was headercontent, or ipp with the /H modifier. An HTTP request that contains the header User-Agent: MyMaliciousBot v0.8 is considered a bot as a result of using this signature.