F5 Logo MyF5
Search
  1. MyF5 Home
  2. BIG-IP Application Security Manager: Implementations
  3. Adding Entities to a Security Policy
Manual Chapter : Adding Entities to a Security Policy

Applies To:

Show Versions Show Versions

BIG-IP ASM

  • 17.0.0
Manual Chapter

Adding Entities to a Security Policy

Adding File Types to a Security Policy

About adding file types

In a security policy, you can manually specify the file types that are allowed (or disallowed) in traffic to the web application being protected. This is only if you are not using the recommended automatic policy building. When you are using automatic policy building, Application Security Manager™ determines which file types to add, based on legitimate traffic.
When you create a security policy, a wildcard file type of *, representing all file types, is added to the file type list. If
Learn New File Types
 is set to
Compact
,
Always
 or
Selective
 then, during the enforcement readiness period, the system examines the file types in the traffic and makes learning suggestions that you can review and add the file types to the policy as needed. This way, the security policy includes the file types that are typically used. If
Learn New File Types
 is set to
Always
, when you think all the file types are included in the security policy, you can remove the * wildcard from the allowed file types list. . If
Learn New File Types
 is set to
Compact
,
Selective
 or
Never
, the * wildcard is designed to stay in the policy and represent all file types that are not listed in
Allowed File Types
.

Adding allowed file types

You can manually add allowed file types, which are file types that the security policy accepts in traffic to the web application being protected.
  1. On the Main tab, click
    Security
    Application Security
    File Types
    .
    The Allowed File Types screen opens.
  2. In the
    Current edited security policy
     list near the top of the screen, verify that the security policy shown is the one you want to work on.
  3. Click
    Create
    .
    The Add Allowed File Type screen opens.
  4. For
    File Type
    , choose a type:
    Option
    Description
    Explicit
    Specifies a unique file type, such as JPG or HTML. Type the file type (from 1 to 255 characters) in the adjacent box.
    No Extension
    Specifies that the web application has a URL with no file type. The system automatically assigns this file type the name
    no_ext
    . The slash character (/) is an example of a
    no_ext
     file type.
    Wildcard
    Specifies that the file type is a wildcard expression. Any file type that matches the wildcard expression is considered legal. The pure wildcard (*) is automatically added to the security policy so you do not need to add it. But you can add other wildcards such as
    htm*
    . Type a wildcard expression in the adjacent box.
  5. For the length settings, adjust the values as needed. This is optional.
    Option
    Specifies
    URL Length
    The maximum acceptable length, in bytes, for a URL in the context of an HTTP request containing this file type. The default is
    100
     bytes.
    Request Length
    The maximum acceptable length, in bytes, for the whole HTTP request that applies to this file type. The default is
    5000
     bytes.
    Query String Length
    The maximum acceptable length, in bytes, for the query string portion of a URL that contains the file type. The default is
    1000
     bytes.
    POST Data Length
    The maximum acceptable length, in bytes, for the POST data of an HTTP request that contains the file type. The default is
    1000
     bytes
  6. By default, the
    Perform Staging
     check box is selected. We recommend that you keep it selected.
  7. If you want the system to validate responses for this file type, select the
    Apply Response Signatures
     check box.
    Selecting this option enables attack signatures (that are designed to inspect server responses) to filter responses.
  8. Click
    Create
    .
    The Allowed File Types screen opens and lists the new file type.
  9. To put the security policy changes into effect immediately, click
    Apply Policy
    .
The security policy allows the file type that you added. If the file type is in staging, the system informs you when learning suggestions are available or when it is ready to be enforced.

Wildcard syntax

The syntax for wildcard entities is based on shell-style wildcard characters. This table lists the wildcard characters that you can use in the names of file types, URLs, parameters, or cookies so that the entity name can match multiple objects.
Wildcard Character
Matches
*
All characters
?
Any single character
[abcde]
Exactly one of the characters listed
[!abcde]
Any character not listed
[a-e]
Exactly one character in the range
[!a-e]
Any character not in the range

Adding disallowed file types

For some web applications, you may want to deny requests for certain file types. In this case, you can create a set of disallowed file types. Adding disallowed file types is useful for file types that you know should never appear on your site (such as
.exe
files), or for files on your site that you never want users from the outside to reach (such as
.bak
 files).
Note that in the Learning and Blocking Settings, when
Learn New File Types
 is set to
Compact
 or
Always
, the system automatically adds the following disallowed file types:
  • Server side technologies or source code: php, aspx, ashx, jsp, lua, cgi, do, java, py, pl
  • Certificate files: pem, crt, cer, key, der, p7b, p7c, pfx, p12
  • Backup files: bak, bkp, bck, old, tmp, temp, sav, save
  • Configuration files: ini, conf, reg, cfg, config,
  • Data files: dat, eml, log, exe1, hta, htr, htw, ida, idc, idq, nws, pol, printer, shtm, shtml, stm, wmz
  • Executable files: exe, msi, bin, cmd, com, bat, dll, sys
  1. On the Main tab, click
    Security
    Application Security
    File Types
    Disallowed File Types
    .
    The Disallowed File Types screen opens.
  2. In the
    Current edited security policy
     list near the top of the screen, verify that the security policy shown is the one you want to work on.
  3. Click
    Create
    .
    The New Disallowed File Type screen opens.
  4. In the
    File Type (Explicit only)
     field, type the file type that the security policy does not allow (for example,
    jpg
     or
    exe
    ).
    File types are case-sensitive unless you cleared
    Security Policy is case sensitive
     when you created the policy.
  5. Click
    Create
    .
    The Disallowed File Types screen opens and lists the new file type.
  6. To put the security policy changes into effect immediately, click
    Apply Policy
    .
The system categorizes both disallowed file types, and requested file types not configured in the security policy as illegal file types. When the Application Security Manager receives a request with a disallowed file type, the system ignores, learns, logs, or blocks the request depending on the settings you configure for the
Illegal File Type
 violation on the Learning and Blocking Settings screen.

Adding potential disallowed file types

Potential disallowed file types
 are candidates for addition to the Disallowed File Types list in a security policy. These file types might occur in malicious requests such as information leakage, remote code execution, and other attacks. Potential disallowed file types are applied globally to all traffic while disallowed files types are configured per security policy. You must accept each potential disallowed file type suggestion manually while the system automatically enforces all Disallowed File Types suggestions automatically.
  1. On the Main tab, click
    Security
    Options
    Application Security
    Advanced Configuration
    Potential Disallowed File Types
    .
  2. Click
    Create
    .
    The New Potential Disallowed File Type properties screen opens.
  3. In the
    File Type (Explicit only)
     field, type the potentially malicious file type to add.
  4. Click
    Create
    .
    The Potential Disallowed File Types screen opens and lists the new file type as
    Yes
    in the User-defined column.
The system automatically checks all traffic for all policies against this list. If a potential disallowed file type is not observed in traffic, the Policy Builder generates a suggestion to tighten the policy by adding the potential disallowed file type to the Disallowed File Types list. If a disallowed file type is later observed in traffic, the Policy Builder generates a suggestion to remove the disallowed file type from the policy.
You must manually accept all suggestions to remove a file type from the Disallowed File Types list. Policy Builder does not automatically implement the suggestion.

Adding Parameters to a Security Policy

About adding parameters to a security policy

Parameters are an integral part of any web application, and they need to be protected so clients cannot access them, modify them, or view sensitive data. When you define parameters in a security policy, you increase the security of the web application and prevent web parameter tampering.
Application Security Manager™ evaluates parameters, meta characters, query string lengths, and POST data lengths as part of a positive security logic check. When the security policy includes known parameters, you are creating a whitelist of acceptable parameters. The system allows traffic that includes the parameters that you configure in a security policy.
Security policies can include parameters defined as global parameters, URL parameters, and flow parameters. You can further specify parameters as being particular value types: static content, dynamic content, dynamic parameter name, user-input, JSON, or XML. You can also create parameters for which the system does not check or verify the value.

Creating global parameters

Global parameters
 are parameters that are not associated with specific URLs or application flows. The advantage of using global parameters is that you can configure a global parameter once, and the system enforces the parameter wherever it occurs. You create a global parameter to address these conditions:
  • The web application has a parameter that appears in several URLs or flows.
  • You want the Application Security Manager to enforce the same parameter attributes on all parameters.
  1. On the Main tab, click
    Security
    Application Security
    Parameters
    .
  2. In the
    Current edited security policy
     list near the top of the screen, verify that the security policy shown is the one you want to work on.
  3. Click
    Create
    .
    The Add Parameter screen opens.
  4. In the Create New Parameter area, for the
    Parameter Name
     setting, specify the type of parameter you want to create.
    • To create a named parameter, select
      Explicit
      , then type the name.
    • To use pattern matching, select
      Wildcard
      , then type a wildcard expression. Any parameter name that matches the wildcard expression is permitted by the security policy.
    • To create an unnamed parameter, select
      No Name
      . The system creates a parameter with the label,
      UNNAMED
      .
  5. For the
    Parameter Level
     setting, select
    Global
    .
    The parameter can occur anywhere and is not associated with a specific URL or flow.
  6. Leave the
    Perform Staging
     check box selected if you want the system to evaluate traffic before enforcing this parameter.
    Staging helps reduce the occurrence of false positives.
  7. Specify whether the parameter requires a value:
    • If the parameter is acceptable without a value, leave the
      Allow Empty Value
       setting enabled.
    • If the parameter must always include a value, clear the
      Allow Empty Value
       check box.
  8. To allow users to send a request that contains multiple parameters with the same name, select the
    Allow Repeated Occurrences
     check box.
    Before enabling this check box, consider that requests containing multiple parameters of the same name could indicate an attack on the web application (HTTP Parameter Pollution).
  9. If you want to treat the parameter you are creating as a sensitive parameter (data not visible in logs or the user interface), enable the
    Mask Value in Logs
     setting.
  10. For the
    Parameter Value Type
     setting, select the format of the parameter value.
    Depending on the value type you select, the screen refreshes to display additional configuration options.
  11. Click
    Create
     to add the new parameter to the security policy.
  12. To put the security policy changes into effect immediately, click
    Apply Policy
    .
When you first create a global parameter, the system places the parameter in staging by default and does not block requests even if a violation occurs and the system is configured to block the violation. The system makes learning suggestions that you can accept or clear.

Creating URL parameters

URL parameters
 are parameters that are defined in the context of a URL. You can use a URL parameter when it does not matter where users were before they accessed this URL, or whether the parameter was in a GET or POST request. You can create a parameter that goes with a URL that already exists in the security policy.
  1. On the Main tab, click
    Security
    Application Security
    Parameters
    .
  2. In the
    Current edited security policy
     list near the top of the screen, verify that the security policy shown is the one you want to work on.
  3. Click
    Create
    .
    The Add Parameter screen opens.
  4. In the Create New Parameter area, for the
    Parameter Name
     setting, specify the type of parameter you want to create.
    • To create a named parameter, select
      Explicit
      , then type the name.
    • To use pattern matching, select
      Wildcard
      , then type a wildcard expression. Any parameter name that matches the wildcard expression is permitted by the security policy.
    • To create an unnamed parameter, select
      No Name
      . The system creates a parameter with the label,
      UNNAMED
      .
  5. For the
    Parameter Level
     setting, select
    URL
    , then for the
    URL Path
     setting, select a protocol from the list, and then type the URL in this format:
    /url_name.ext
    .
    When you begin to type the URL, the system lists all URLs that include the character you typed, and you can select the URL from the list.
  6. Leave the
    Perform Staging
     check box selected if you want the system to evaluate traffic before enforcing this parameter.
    Staging helps reduce the occurrence of false positives.
  7. Specify whether the parameter requires a value:
    • If the parameter is acceptable without a value, leave the
      Allow Empty Value
       setting enabled.
    • If the parameter must always include a value, clear the
      Allow Empty Value
       check box.
  8. To allow users to send a request that contains multiple parameters with the same name, select the
    Allow Repeated Occurrences
     check box.
    Before enabling this check box, consider that requests containing multiple parameters of the same name could indicate an attack on the web application (HTTP Parameter Pollution).
  9. If you want to treat the parameter you are creating as a sensitive parameter (data not visible in logs or the user interface), enable the
    Mask Value in Logs
     setting.
  10. For the
    Parameter Value Type
     setting, select the format of the parameter value.
    Depending on the value type you select, the screen refreshes to display additional configuration options.
  11. Click
    Create
     to add the new parameter to the security policy.
  12. To put the security policy changes into effect immediately, click
    Apply Policy
    .
When you define a URL parameter, the system applies the security policy to the parameter attributes in the context of the associated URL, and ignores the flow information. When you first create a URL parameter, the system places the parameter in staging by default and does not block requests even if a violation occurs and the system is configured to block the violation. The system makes learning suggestions that you can accept or clear.

Creating flow parameters

Before you can create a flow parameter, you need to first have created the flow to which the parameter applies. If the source URL is a referrer URL, that HTTP URL must already be defined in the security policy as well.
You define parameters in the context of a flow when it is important to enforce that the target HTTP URL receives a parameter only from a specific referrer URL. Flow parameters provide very tight, flow-specific security for web applications. With this increased protection comes an increase in maintenance and configuration time. Note that if your application uses dynamic parameters, you need to manually add those to the security policy.
  1. On the Main tab, click
    Security
    Application Security
    Parameters
    .
  2. In the
    Current edited security policy
     list near the top of the screen, verify that the security policy shown is the one you want to work on.
  3. Click
    Create
    .
    The Add Parameter screen opens.
  4. In the Create New Parameter area, for the
    Parameter Name
     setting, specify the type of parameter you want to create.
    • To create a named parameter, select
      Explicit
      , then type the name.
    • To use pattern matching, select
      Wildcard
      , then type a wildcard expression. Any parameter name that matches the wildcard expression is permitted by the security policy.
    • To create an unnamed parameter, select
      No Name
      . The system creates a parameter with the label,
      UNNAMED
      .
  5. In the
    Parameter Level
     setting, select
    Flow
    , and then for
    From URL
     define where the flow must come from:
    • If the source URL is an entry point, click
      Entry Point
      .
    • If the source URL is a referrer URL (already defined in the policy), click
      URL Path
      , select the protocol used for the URL, then type the referrer URL associated with the flow.
    When you begin to type the URL, the system lists all referrer URLs that include the character you typed, and you can select the URL from the list.
  6. In the
    Parameter Level
     setting, for
    Method
    , select the HTTP method (
    GET
     or
    POST
    ) that applies to the target referrer URL (already defined in the policy).
  7. In the
    Parameter Level
     setting, for
    To URL
    , select the protocol used for the URL, then type the target URL.
  8. Leave the
    Perform Staging
     check box selected if you want the system to evaluate traffic before enforcing this parameter.
    Staging helps reduce the occurrence of false positives.
  9. If the parameter is required in the context of the flow, select the
    Is Mandatory Parameter
     check box.
    Note that only flows can have mandatory parameters.
  10. Specify whether the parameter requires a value:
    • If the parameter is acceptable without a value, leave the
      Allow Empty Value
       setting enabled.
    • If the parameter must always include a value, clear the
      Allow Empty Value
       check box.
  11. To allow users to send a request that contains multiple parameters with the same name, select the
    Allow Repeated Occurrences
     check box.
    Before enabling this check box, consider that requests containing multiple parameters of the same name could indicate an attack on the web application (HTTP Parameter Pollution).
  12. If you want to treat the parameter you are creating as a sensitive parameter (data not visible in logs or the user interface), enable the
    Mask Value in Logs
     setting.
  13. For the
    Parameter Value Type
     setting, select the format of the parameter value.
    Depending on the value type you select, the screen refreshes to display additional configuration options.
  14. Click
    Create
     to add the new parameter to the security policy.
  15. To put the security policy changes into effect immediately, click
    Apply Policy
    .
When you create a parameter that is associated with a flow, the system verifies the parameter in the context of the flow. For example, if you define a parameter in the context of a GET request, and a client sends a POST request that contains the parameter, the system generates an
Illegal Parameter
 violation.

Creating sensitive parameters

The Application Security Manager stores incoming requests in plain text format. Some requests include sensitive data in parameters, such as an account number, that you want to hide from system users. You can create sensitive parameters as described in the procedure, following, or by enabling the
Sensitive Parameter
 setting when creating or editing any parameter. All parameters defined as sensitive, regardless of how you configured them, appear in the Sensitive Parameters list.
  1. On the Main tab, click
    Security
    Application Security
    Parameters
    Sensitive Parameters
    .
  2. In the
    Current edited security policy
     list near the top of the screen, verify that the security policy shown is the one you want to work on.
  3. Click
    Create
    .
    The New Sensitive Parameter screen opens.
  4. In the
    Parameter Name
     field, type the name of the user-input parameter, exactly as it occurs in the HTTP request, for which you do not want the system to store the actual value.
    In this example,
    account
     is the sensitive parameter:
    http://www.siterequest.com/bank.php?account=12345
    If a parameter of this name already exists in the security policy, click it in the parameter list, and enable the
    Sensitive Parameter
     setting instead of creating a new sensitive parameter.
  5. Click
    Create
     to add the new parameter to the security policy.
  6. To put the security policy changes into effect immediately, click
    Apply Policy
    .
When you create sensitive parameters, the system replaces the sensitive data, in the stored request and in logs, with asterisks (***).

Disallowing file uploads in parameters

Because most web applications do not legitimately allow users to upload executable code, you can disallow parameters containing binary executable content. To do this, you add a user-input parameter with the file upload data type to a security policy, and use the option to prevent uploading of executable files. You can also specify a maximum length for the parameter.
  1. On the Main tab, click
    Security
    Application Security
    Parameters
    .
  2. Click
    Create
    .
    The Add Parameter screen opens.
  3. Type the name for the new explicit parameter.
  4. For the
    Parameter Level
     setting, select where in a request the parameter is located.
    Global
    The parameter can occur anywhere and is not associated with a specific URL or flow.
    URL
    The parameter occurs in the specific URL that you provide.
    Flow
    The parameter occurs in the specific entry point URL or referrer URL that you provide.
  5. Leave the
    Perform Staging
     check box selected if you want the system to evaluate traffic before enforcing this parameter.
    Staging helps reduce the occurrence of false positives.
  6. Specify whether the parameter requires a value:
    • If the parameter is acceptable without a value, leave the
      Allow Empty Value
       setting enabled.
    • If the parameter must always include a value, clear the
      Allow Empty Value
       check box.
  7. To allow users to send a request that contains multiple parameters with the same name, select the
    Allow Repeated Occurrences
     check box.
    Before enabling this check box, consider that requests containing multiple parameters of the same name could indicate an attack on the web application (HTTP Parameter Pollution).
  8. For the
    Parameter Value Type
     setting, select
    User-input value
    .
  9. On the Data Type tab, for the
    Data Type
     setting, select
    File Upload
    .
  10. To enforce limits on the size of the parameter, in the
    Maximum Length
     setting, select
    Value
     and type the maximum number of bytes for a parameter value.
  11. Ensure that
    Disallow File Upload of Executables
     is selected.
  12. Click
    Create
    .
    The screen refreshes, and the new parameter appears in the parameters list.
  13. To put the security policy changes into effect immediately, click
    Apply Policy
    .
If a client sends an HTTP request that includes a user-input parameter containing a binary executable file, the system issues the
Disallowed file upload content detected
 violation. This is considered
parameter tampering
. If the violation is set to block (it is, by default) and the enforcement mode is set to blocking, the request is blocked.
If a parameter in a request exceeds the maximum length specified, the system presents an
Illegal parameter value length violation
. By default it is set to alarm; that means if a request triggers this violation, the system records the request in the Charts screen, the Syslog (
/var/log/asm
), and may record the request in the local log (the Requests screen) and/or in a remote log, according to the logging profile.

Creating navigation parameters

If you want the security policy to differentiate between pages in the web application that are generated by requests with the same URL name but with different parameter and value pairs, and to build the appropriate flows, you must specify the exact names of the parameters that trigger the creation of the pages in the web application. These parameters are called
navigation parameters
. A navigation parameter cannot be a wildcard.
  1. On the Main tab, click
    Security
    Application Security
    Parameters
    Navigation Parameters
    .
  2. In the
    Current edited security policy
     list near the top of the screen, verify that the security policy shown is the one you want to work on.
  3. Click
    Create
    .
    The New Navigation Parameter screen opens.
  4.
  5. In the
    Navigation Parameter
    field, type the name of the parameter passed to the web server for dynamic page-building purposes.
  6. Click
    Create
     to add the new parameter to the security policy.
  7. To put the security policy changes into effect immediately, click
    Apply Policy
    .

Creating parameters with dynamic content

Dynamic content value (DCV) parameters
 are parameters where the web application sets the value on the server side (so, for example, the content can change depending on who the user is). When you create a DCV parameter, you also specify where and how to get the dynamic information. For example, in an auction application, you can configure the price parameter as a DCV parameter to keep users from tampering with the price.
You can also use DCV parameters for user identities in web applications that use sessions. As an example, user identity is often passed between pages as a hidden parameter, which could be exploited by malicious users, unless protected.
  1. On the Main tab, click
    Security
    Application Security
    Parameters
    .
  2. In the
    Current edited security policy
     list near the top of the screen, verify that the security policy shown is the one you want to work on.
  3. Click
    Create
    .
    The Add Parameter screen opens.
  4. In the Create New Parameter area, for the
    Parameter Name
     setting, specify the type of parameter you want to create.
    • To create a named parameter, select
      Explicit
      , then type the name.
    • To use pattern matching, select
      Wildcard
      , then type a wildcard expression. Any parameter name that matches the wildcard expression is permitted by the security policy.
    • To create an unnamed parameter, select
      No Name
      . The system creates a parameter with the label,
      UNNAMED
      .
  5. For the
    Parameter Level
     setting, select the appropriate type, typically
    Global
     or
    URL
    .
  6. For the
    Parameter Value Type
     setting, select
    Dynamic content value
    .
  7. Click
    Create
    .
    You should define the extractions for a DCV parameter before you apply the security policy that includes the parameters. Otherwise, the system warns you that the security policy contains dynamic parameters with no extractions defined.
    A popup screen opens asking if you want to define extractions.
  8. Click
    OK
    .
    The Create New Extraction screen opens. The
    Name
     field shows the name of the parameter you created.
  9. From the
    Extracted Items Configuration
     list, select
    Advanced
    .
  10. Use the
    Extract From
     setting to specify which items the system searches for dynamic parameter values.
    Use This Option
    When
    File Types
    You want the system to extract dynamic parameters from responses to requests for certain file types that exist in the security policy. Select the file type and click
    Add
    .
    URLs
    You want the system to extract dynamic parameters from responses to requests for the listed URLs. To add the URLs, select the protocol, type the URL and click
    Add
    . If the URL is not in the security policy, it is added.
    RegExp
    You want the system to extract dynamic parameters from responses to requests that match a regular expression pattern.
    Extract From All Items
    You want the system to extract dynamic parameters from all text-based URLs and file types.
  11. From the
    Extracted Methods Configuration
     list, select
    Advanced
    .
  12. Select the appropriate check boxes to specify how to get the dynamic parameter values.
    Select This Option
    When
    Search in Links
    You want the system to extract dynamic parameter values from links (href tags) within the server response to a URL.
    Search Entire Form
    You want the system to extract dynamic parameter values from all parameters in a form in the HTML response to a requested URL.
    Search Within Form
    You want the system to extract dynamic parameter values from a specific parameter within in a form. Also specify the
    Form Index
     and the
    Parameter Index
    .
    Search in XML
    You want the system to extract dynamic parameter values from within XML entities. Type the XPath specification in the
    XPath
     field.
    Search in Response Body
    You want to the system to search for dynamic parameter values in the body of the response. You can also specify how many incidents the system should find, a prefix, a RegExp value, or a prefix to search for.
  13. Click
    Create
     to add the extraction properties to the parameter.
  14. Click
    Update
     to save the changes.
  15. To put the security policy changes into effect immediately, click
    Apply Policy
    .
When the Application Security Manager receives a request that contains an entity (for example, a file extension or URL) with a dynamic content value parameter, the system extracts the parameter value from the web application response and stores it away. The next time the system receives a request containing that parameter, it uses the stored value to validate the dynamic content value parameter. The system verifies that the client is not changing the parameter value that the server sets from one request to the next, or using the values from a different user.
By default, the system saves up to 950 values that it finds for a dynamic content value parameter. If the number of values exceeds 950, the system replaces the first-extracted values with the new values.

Creating parameters with dynamic names

Before you can make a parameter with a dynamic name, you must have created a flow parameter.
In some web applications, flow parameters have dynamic names. When you create a parameter with a dynamic name, you also specify the manner in which Application Security Manager discovers the parameter names.
  1. On the Main tab, click
    Security
    Application Security
    Parameters
    .
  2. In the Parameters List, click the name of the flow parameter that you want to have a dynamic name.
    The Parameter Properties screen opens where you can edit the flow parameter.
  3. For the
    Parameter Value Type
     setting, select
    Dynamic parameter name
    .
  4. On the Dynamic Parameter Properties tab, for the
    Extract Parameter from URL
     setting, select the protocol to use and type the URL from which you want the system to extract the dynamic parameter.
  5. Specify whether the system searches for the parameter name in a form or the response body:
    • To search in forms, select
      Search Within Form
      , and specify values for
      Form Index
       and
      Parameter Index
      .
    • To search in the response body, select
      Search parameters in response body (in form elements names only)
      . In the
      By Pattern
       field, type a regular expression to search for parameter names in input elements in the forms. Select
      Check parameter value
       to verify the parameter value in addition to the name matched in the
      By Pattern
       field.
  6. Click
    Update
     to save the changes.
  7. To put the security policy changes into effect immediately, click
    Apply Policy
    .
The system extracts the parameters from the web server responses and then uses the extracted parameters to enforce the dynamic parameter associated with the flow.

Changing character sets for parameter values

The character sets for parameter values are the characters and meta characters that the security policy accepts in a parameter value. You can view and modify the character set that is allowed in a parameter value.
  1. On the Main tab, click
    Security
    Application Security
    Parameters
    Character Sets
    Parameter Value
    .
  2. In the
    Current edited security policy
     list near the top of the screen, verify that the security policy shown is the one you want to work on.
  3. Use the
    View
     option to filter the character set.
  4. For each character or meta character, change the state, as required.
    State
    Description
    Allow
    The security policy permits this character or meta character in parameter values.
    Disallow
    The security policy does not permit this character or meta character in parameter values.
  5. Click
    Save
     to save the changes.
  6. To put the security policy changes into effect immediately, click
    Apply Policy
    .
If a request includes a parameter with a disallowed character, the system generates an
Illegal parameter
 violation (if that violation is set to Alarm or Block).

Changing character sets for parameter names

The character sets for parameter names are the characters and meta characters that the security policy accepts in a parameter name. You can view and modify the character set that is allowed in a parameter name.
  1. On the Main tab, click
    Security
    Application Security
    Parameters
    Character Sets
    Parameter Name
    .
  2. In the
    Current edited security policy
     list near the top of the screen, verify that the security policy shown is the one you want to work on.
  3. Use the
    View
     option to filter the character set.
  4. For each character or meta character, change the state, as required.
    State
    Description
    Allow
    The security policy permits this character or meta character in parameter names.
    Disallow
    The security policy does not permit this character or meta character in parameter names.
  5. Click
    Save
     to save the changes.
  6. To put the security policy changes into effect immediately, click
    Apply Policy
    .
If a request includes a parameter name with a disallowed character, the system generates an
Illegal parameter
 violation (if that violation is set to Alarm or Block).

Adjusting the parameter level

You can adjust how the system determines what parameters it adds (automatic policy building) or suggests you add (manual learning) to the security policy. In most cases, you do not need to change the default values of these settings.
  1. On the Main tab, click
    Security
    Application Security
    Policy Building
    Learning and Blocking Settings
    .
    The Learning and Blocking Settings screen opens.
  2. In the
    Current edited security policy
     list near the top of the screen, verify that the security policy shown is the one you want to work on.
  3. Expand
    Parameters
     and for the
    Parameter Level
     setting, select the level of parameter to add.
    Global
    Add parameters at the global level for all URLs in the security policy. Make learning suggestions based on the properties of entities that already exist in the security policy. Default value for
    Fundamental
     policy template.
    URL
    Add parameters at the URL level, only for specific URLs. Make learning suggestions based on real traffic. Default value for
    Comprehensive
     policy template.
    This option applies only to the attack signature and illegal meta character violations.
  4. Click
    Save
     to save your settings.
  5. To put the security policy changes into effect immediately, click
    Apply Policy
    .
The security policy now adds parameters according to the level you specified.

Parameter Value Types

When you add a parameter to the security policy, you specify its parameter value type. The parameter value type indicates the format of the parameter. You can configure global, URL, and flow parameters as any value type, except the dynamic parameter name type. You can configure only flow parameters as dynamic parameter names.
Parameter Value Type
Description
Dynamic content value
Dynamic parameters
 are parameters whose values can change, and are often linked to a user session. When you create a new parameter of this type, you must also define dynamic parameter extraction properties. The server sets the value for dynamic content value (DCV) parameters. DCV parameters are often associated with applications that use session IDs for client sessions.
Dynamic parameter name
If using flow parameters with names that change dynamically, you can use this parameter type. If you select this type, you also need to specify the URL from which the system can extract dynamic parameter name parameters.
Ignore value
If you do not want the system to perform validity checks on the parameter value, select this value type. Regarding signatures, this value type prevents the system from performing parameter-based signature checks on the parameter value, but it does perform other relevant signature checks.
JSON value
The JSON value type is for parameters that contain JSON data that is validated according to a JSON profile that defines the format of the data. Select an existing JSON profile or create a new one.
Static content value
Static parameters are those that have a known set of values. A list of country names or a yes/no form field are both examples of static parameters. If you select this type, you also need to specify the static values for the parameter in the Parameter Static Values list. For example, a credit card payment parameter in a shopping application may be static and have the static values MasterCard, Visa, and American Express.
User-input value
User-input parameters are those that require users to enter or provide some sort of data. This is the most commonly used parameter value type. Comment, name, and phone number fields on an online form are all examples of user-input parameters. You can also configure user-input parameters even if the parameter is not really user input. For example, if a parameter has a wide range of values or many static values, you may want to configure the parameter as a user-input parameter instead of as a static content parameter. By default, the system looks for attack patterns within all alpha-numeric user-input parameters. For each parameter, you can enable or disable a specific attack signature.
XML value
XML parameters are those whose parameter value contains XML data that is validated according to an XML profile that defines the format of the data. Select an existing XML profile or create a new one.

How the system processes parameters

When you create any type of parameter, the system automatically places the parameter in staging and does not block requests even if a violation occurs and the system is configured to block that violation. Based on examining traffic, the system makes learning suggestions that you can accept or clear. If you create wildcard parameters, you also have the option of enabling learning for explicit entities.
The system enforces parameters in the following order:
  • Flow parameters
  • URL parameters
  • Global parameters
If a parameter is defined more than once in the request context, the system applies only the more specific definition. For example, parameter
param_1
 is defined as a static content global parameter, and also defined as a user-input URL parameter. When the Application Security Manager™ receives a request for the parameter in a URL that matches a URL defined in the security policy, and the parameter is defined on both the global and URL level, the system generates any violations based on the URL parameter definition.

About path parameters

Path parameters are parameters that are attached to path segments in the URI. You can configure Application Security Manager™ (ASM) to enforce path parameters as needed in your organization. Path parameters can be ignored, or treated as parameters, or as an integral part of URLs.
Although path parameters are not widely used, they could serve as covert back doors to potential attacks even for server applications that do not use path parameters. For example, an application could copy a URI with path parameters containing attack signatures to the body of the response.
Path parameters can have multiple parameters in the same path segment separated by semicolons. A semicolon also separates the path segment from the parameters; for example,
/path/name;param1;p2;p3
. Each parameter can optionally equal a value; for example,
param=value;p2
. If a path parameter has more than one value, the values are separated by commas, such as
param=val1,val2,val3
.
Path parameters are extracted from requests, but not from responses.

Enforcing path parameter security

A URI path parameter is the part of a path segment that occurs after its name. You can configure how a security policy handles path parameters that are attached to path segments in URIs. You can enforce different levels of security based on your needs.
  1. On the Main tab, click
    Security
    Application Security
    Security Policies
    .
    The Policies List screen opens.
  2. Click the name of the security policy you want to work on.
    The Policy Summary opens.
  3. From the list, select
    Advanced
    .
  4. Scroll down to
    Handle Path Parameters
    , and select how you want to treat path parameters in URIs.
    Option
    Description
    As Parameter
    The system normalizes and enforces path parameters. For each path parameter, the system removes it from the URL as part of the normalization process, finds a corresponding parameter in the security policy (first at the matching URL level, and if not found, then at the Global level), and enforces it according to its attributes like any other parameter.
    As URL
    The system does not normalize or enforce path parameters, and treats them as an integral part of the URL.
    Ignore
    The system removes path parameters from URLs as part of the normalization process, but does not enforce them.
  5. Click
    Save
    .
  6. In the editing context area, click
    Apply Policy
     to put the changes into effect.
Path parameters in URIs are handled as specified in the security policy properties
The maximum number of path parameters collected in one URI path is 10. All the rest of the parameters (from the eleventh on, counting from left to right) are ignored as parameters, but are still stripped from the URI as part of the normalization process.
.

Overview: Securing Base64-Encoded Parameters

Base64 encoding
 is a convenient encoding method that uses a compact presentation, and is relatively unreadable to the casual observer. Many applications apply base64 encoding to binary data, for inclusion in URLs or in hidden web form fields. Unfortunately, it is also possible to mask application attacks in base64-encoded data. To provide better security for applications that use base64 encoding, Application Security Manager™ can decode user-input parameter values that are base64-encoded.

Adding base64 decoding to a new user-input parameter

If your application uses base64 encoding, the system can apply base64 decoding to a user-input parameter. When the decoding is successful, the system applies the parameter checks specified in the security policy. When the decoding is not successful, the system issues the
Illegal base64 encoded value
 violation and responds to the offending request according the associated blocking policy.
  1. On the Main tab, click
    Security
    Application Security
    Parameters
    .
  2. In the
    Current edited security policy
     list near the top of the screen, verify that the security policy shown is the one you want to work on.
  3. Click
    Create
    .
    The Add Parameter screen opens.
  4. Type the name for the new explicit parameter.
  5. For the
    Parameter Level
     setting, select where in a request the parameter is located.
    Global
    The parameter can occur anywhere and is not associated with a specific URL or flow.
    URL
    The parameter occurs in the specific URL that you provide.
    Flow
    The parameter occurs in the specific entry point URL or referrer URL that you provide.
  6. Leave the
    Perform Staging
     check box selected if you want the system to evaluate traffic before enforcing this parameter.
    Staging helps reduce the occurrence of false positives.
  7. For the
    Parameter Value Type
     setting, select
    User-input value
    .
  8. On the Data Type tab, for the
    Data Type
     setting, select either
    Alpha-Numeric
     or
    File Upload
    .
  9. Select the
    Base64 Decoding
     check box if you want the system to apply base64 decoding to values for this parameter.
  10. Configure any other properties that apply to this new parameter.
  11. Click
    Create
    .
    The screen refreshes, and the new parameter appears in the parameters list.
  12. To put the security policy changes into effect immediately, click
    Apply Policy
    .

Adding base64 decoding to an existing user-input parameter

When enabled, the system can decode base64 encoding in a user-input parameter. If the decoding is successful, the system applies the parameter checks specified in the security policy. If the decoding is not successful, the system issues the
Illegal base64 encoded value
 violation and responds to the offending request according to the associated blocking policy.
  1. On the Main tab, click
    Security
    Application Security
    Parameters
    Parameters List
    .
  2. In the Parameters List filter, select
    Parameter Value Type
     in the left list,
    User-input value
     in right list, and click
    Go
    .
    The screen refreshes and lists only user-input parameters.
  3. In the Parameter Name column, click the name of the parameter to which you want to add base64 decoding.
    The Parameter Properties screen opens.
  4. On the Data Type tab, select the
    Base64 Decoding
     check box so the system applies base64 decoding to values for this parameter.
    The base64 decoding setting is available only for user-input parameters of the alpha-numeric or file upload data type.
  5. Click
    Update
    .
    The screen refreshes, and displays the parameters list.
  6. To put the security policy changes into effect immediately, click
    Apply Policy
    .

Adding URLs to a Security Policy

About adding URLs

In a security policy, you can manually specify the HTTP or WebSocket URLs that are allowed (or disallowed) in traffic to the web application being protected. If you are using automatic policy building (and the policy includes learning URLs), Application Security Manager™ (ASM) can determine which URLs to add, based on legitimate traffic. If a WebSocket profile is associated with the security policy virtual server, ASM can also add WebSocket URLs to the policy.
When you create a security policy, wildcard URLs of * (representing all HTTP or WebSocket URLs) are added to the Allowed HTTP and WebSocket URLs lists. During the enforcement readiness period, the system examines the URLs in the traffic and makes learning suggestions that you can review and add the URLs to the policy as needed. This way, the security policy includes the HTTP and WebSocket URLs that are typically used. When you think all the URLs are included in the security policy, you can remove the * wildcards from the allowed URLs lists.

About referrer URLs

Referrer URLs
 are web pages that request other URLs within a web application. For example, an HTML page can request a GIF, JPG, or PNG image file. The HTML page is the referrer, and the GIF, JPG, and PNG files are non-referrers. In lists of URLs, non-referrer URLs appear in blue and referrer URLs appear in gold.
A referrer in Application Security Manager™ is similar to the HTTP Referer header. Use referrers for complex objects, such as HTML pages, but not for embedded objects, such as GIF files.

Adding allowed HTTP URLs

You can manually add
allowed HTTP URLs
, which are URLs from which the security policy accepts traffic en route to the web application being protected.
  1. On the Main tab, click
    Security
    Application Security
    URLs
    .
    The Allowed HTTP URLs screen opens.
  2. In the
    Current edited security policy
     list near the top of the screen, verify that the security policy shown is the one you want to work on.
  3. Click
    Create
    .
    The New Allowed HTTP URL screen opens.
  4. For
    URL
    , choose a type, protocol and method (optional), and then type the URL name or wildcard.
    Option
    Description
    Explicit
    Specifies a unique URL, such as
    /index.html
    . Choose
    HTTP
     or
    HTTPS
    , and type the URL in the adjacent field.
    Wildcard
    Specifies that the URL is a wildcard expression. Any URL that matches the wildcard expression is considered legal. The pure wildcard (*) is automatically added to the security policy so you do not need to add it. But you can add other wildcards such as
    /main/*
    . Select
    HTTP
     or
    HTTPS
    , and type a wildcard expression in the adjacent field.
  5. Optional. Choose a method from the drop down list to create an API endpoint: URL + Method.
  6. By default, the
    Perform Staging
     check box is selected. F5 recommends that you keep it selected.
  7. If the URL is a Wildcard, select
    Positional Parameters
     if you want to create positional parameters in the URL.
    The Add Segment... button appears in the URL field above.
  8. Click
    Add Segment...
     in the URL field and select which to add:
    Text
     or
    Parameter
     and enter your desired segments. You can add multiple text and parameter segments.
  9. If you want to view more options, next to
    Create New Allowed URL
    , select
    Advanced
    .
  10. If the attack signatures included in the security policy apply differently to this allowed URL, you can adjust them on the Attack Signatures tab.
    1. Ensure that
      Check attack signatures on this URL
       is selected.
    2. From the
      Global Security Policy Settings
       list, move any attack signatures whose global settings you want to override into the
      Overridden Security Policy Settings
       and adjust the state as needed (from
      Enabled
       to
      Disabled
       or vice versa).
    The most common action you perform here is to disable an attack signature for a specific URL.
    Overridden attack signatures are preceded with a yellow alert triangle in the attack signature list, and you can filter the list to view them.
  11. To process requests for this URL according to the header content, create header-based content profiles.
    The task,
    Enforcing requests for HTTP URLs based on header content
    , provides details on how to do this.
  12. To protect the application from being able to harbor illegitimate frames and iframes (inline frames) with malicious code in the application, set up protection from clickjacking:
    1. For
      Clickjacking Protection
      , select the
      Enabled
       check box.
    2. From the
      Allow Rendering in Frames
       list, select an option to determine whether to allow this URL to be rendered in a frame or iframe.
  13. For wildcard URLs, leave
    Wildcard Match Includes Slashes
     selected.
    When this option is selected, an asterisk in a wildcard matches any number of path segments (separated by slashes); when cleared, an asterisk matches at most one segment.
  14. For wildcard URLs, in the Meta Characters tab, you can specify whether to check for meta characters in the URL, and which ones to allow or disallow.
    1. The
      Check characters on this URL
       setting is enabled by default so that the system verifies meta characters in the URL. (If you do not want to check for meta characters, clear the check box and skip to the next step.)
    2. To specify which meta characters to allow or disallow, from the
      Global Security Policy Settings
       list, select any meta characters that you want to specifically allow or disallow, and move them to the
      Overridden Security Policy Settings
       list.
    3. For each meta character that you moved, set the state to
      Allow
       or
      Disallow
      .
    The Overridden Security Policy Settings take precedence over the global settings for the web application character set.
  15. Click
    Create
    .
    The Allowed URLs screen opens and lists the new URL.
  16. To put the security policy changes into effect immediately, click
    Apply Policy
    .
The security policy allows requests for the URL or URLs matching the wildcard that you added. If the URL is in staging, the system informs you when learning suggestions are available or when it is ready to be enforced.

Wildcard syntax

The syntax for wildcard entities is based on shell-style wildcard characters. This table lists the wildcard characters that you can use in the names of file types, URLs, parameters, or cookies so that the entity name can match multiple objects.
Wildcard Character
Matches
*
All characters
?
Any single character
[abcde]
Exactly one of the characters listed
[!abcde]
Any character not listed
[a-e]
Exactly one character in the range
[!a-e]
Any character not in the range

Allowed HTTP URL properties

These tables describe the properties (both Basic and Advanced settings) that define HTTP URLs that the security policy will allow.

New allowed HTTP URL properties

Property
Description
URL
Specifies an HTTP URL that the security policy allows. The available types are:
  • Explicit
    : Specifies that the URL is a unique HTTP URL. Type the URL in the adjacent field using the format
    /index.html
    .
  • Wildcard
    : Specifies a wildcard expression. Any HTTP URL that matches is considered legal. For example, typing
    *
     specifies that any HTTP URL is allowed by the security policy. Type a wildcard expression in the adjacent field.
Protocol
Specifies whether the protocol for the URL is HTTP or HTTPS.
Perform Staging
Specifies that the system places this URL in staging. Learning suggestions produced by requesting staged URLs are logged in the Learning screens. Review staging status on the Allowed HTTP URLs screen. If a URL is in staging, point to the icon to display staging information. When you are no longer getting learning suggestions, you can disable this setting. If you enforce a URL, this setting is cleared.
Check Flows to this URL
Specifies that the security policy validates flows to the URL (if configured). If this setting is disabled, the system ignores the flows to the URL. When you select this check box, additional settings appear.
URL is Entry Point
(Visible when
Check Flows to this URL
 is selected.) Specifies that this URL is a page through which a visitor can enter the web application.
URL is Referrer
(Visible when
Check Flows to this URL
 is selected.) Specifies that the URL is a URL from which a user can access other URLs in the web application.
URL can change Domain Cookie
Specifies that the security policy does not block an HTTP request where the domain cookie was modified on the client side. Note that this setting is applicable only if the URL is a referrer.
URL with Navigation Parameter
Specifies that you want to associate a navigation parameter with this URL. You must have a navigation parameter defined in the security policy to view this option.
Select Navigation Parameter
Specifies a list of navigation parameters that you can associate with this URL.
Navigation Parameter Value
Indicates the value of the navigation parameter.
Clickjacking Protection
Specifies that the system adds the
X-Frame-Options
 header to the domain cookie’s response header. This is done to protect the web application against clickjacking.
Clickjacking
 occurs when attacker lures a user to click illegitimate frames and iframes because the attacker hid them on legitimate visible website buttons. Therefore, enabling this option protects the web application from other web sites hiding malicious code behind them. The default is disabled. After you enable this option, you can select whether, and under what conditions, the browser should allow this URL to be rendered in a frame or iframe.
Allow Rendering in Frames
Specifies the conditions for when the browser should allow this URL to be rendered in a frame or iframe.
  • Never
    : Specifies that this URL must never be rendered in a frame or iframe. The web application instructs browsers to hide, or disable, frame and iframe parts of this URL.
  • Same Origin Only
    : Specifies that the browser may load the frame or iframe if the referring page is from the same protocol, port, and domain as this URL. This limits the user to navigate only within the same web application.
  • Only From URL
    : Specifies that the browser may load the frame or iframe from a specified domain. Type the protocol and domain in URL format for example,
    http://www.mywebsite.com
    . Do not enter a sub-URL, such as
    http://www.mywebsite.com/index
    .
Wildcard Match Includes Slashes
Specifies that an asterisk in a wildcard URL matches any number of path segments (separated by slashes); when cleared, specifies that an asterisk matches at most one segment. For example: the wildcard
/art/*
 matches
/art/abc/index.html
 if the wildcard match includes slashes (default value), but does not match it if the check box is cleared. In that case, it matches
/art/go.html
 (only one segment below
/art
).
HTML5 Cross-Domain Request Enforcement
CORS (Cross-Origin Resource Sharing) lets one website access the resources of another website using JavaScript (within the browser). Web applications may share resources with other websites hosted on a different domain. When the option is selected, the system protects a specific URL in your web application from cross-origin resource sharing. You can configure which domains can access the response generated by requesting this URL (the resource), and how to overwrite CORS response headers returned by the web server.
URL Description
Describes the URL (optional).

Header-Based Content Profiles

Property
Description
Request Header Name
Specifies an explicit header name that must appear in requests for this URL. This field is not case-sensitive.
Request Header Value
Specifies a simple pattern string (glob pattern matching) for the header value that must appear in legal requests for this URL; for example,
*json*
,
xml_method?
, or
method[0-9]
. If the header includes this pattern, the system assumes the request contains the type of data you select in the
Request Body Handling
 setting. This field is case-sensitive.
Request Body Handling
Indicates how the system parses the content of requests for the allowed URL:
  • Apply Content Signatures
    : Do not parse the content; scan the entire payload with full-content attack signatures.
  • Apply Value and Content Signatures
    : Do not parse the content or extract parameters; process the entire payload with value and full-content attack signatures.
  • Disallow
    : Block requests for an URL containing this header content. Log the Illegal Request Content Type violation.
  • Do Nothing
    : Do not inspect or parse the content. Handle the header of the request as specified by the security policy.
  • Form Data
    : Parse content as posted form data in either URL-encoded or multi-part formats. Enforce the form parameters according to the policy.
  • GWT
    : Perform checks for data in requests, based on the configuration of the GWT (Google Web Toolkit) profile associated with this URL.
  • JSON
    : Review JSON data using an associated JSON profile, and use value attack signatures to scan the element values.
  • XML
    : Review XML data using an associated XML profile.
Profile Name
Specifies the XML, JSON, or GWT profile the security policy uses when examining requests for this URL if the header content is parsed as XML, JSON, or GWT. You can also create or view the XML, JSON, or GWT profile from this option.

HTML5 Cross-Domain Request Enforcement

Property
Description
Allow HTML5 Cross-Origin Requests
Allows all CORS requests to this URL, and displays additional settings.
Allowed Origins
Allows you to specify a list of origins allowed to share data returned by this URL.
Allowed Methods
Allows you to specify a list of methods that other web applications hosted in different domains can use when requesting this URL.
Allowed Headers
Allows you to specify a list of request headers that other web applications hosted in different domains can use when requesting this URL. Or you can delete non-simple headers returned in response to requests.
Exposed Headers
Allows you to specify a list of response headers that are safe to expose to JavaScript, and can be shared with web applications hosted in different domains. Or you can allow only simple headers to be exposed.
Allow Credentials
Specifies whether requests from other web applications hosted in different domains may include user credentials.
Maximum Age
Specifies how long (in seconds) to cache in the browser the results of a preflight request (a special request that the browser sends to your web application to determine if JavaScript from another domain may access your resource).

Meta Characters

Property
Description
Check characters on this URL
Specifies that the system verifies meta characters on this wildcard URL. You can change which meta characters are allowed or disallowed.

Methods Enforcement

Property
Description
Override policy allowed methods
Specifies that the system allows you to override allowed methods for this URL. When selected, global policy settings for methods are listed, and you can change what is allowed or disallowed for this URL.

Learning Settings for HTTP URLs

These settings are on the Learning and Blocking Settings screen.
Setting
Description
Learn New HTTP URLs
Specifies how to add, or suggests that you add URLs to the security policy if you are creating a wildcard URL.
  • Add All Entities
    : The system suggests you add explicit URLs that match the wildcard to the security policy creating a comprehensive whitelist of all the URLs on the web site. You can review suggestions on the Traffic Learning screen.
  • Selective
    : When false positives occur, the system adds or suggests adding an explicit URL with relaxed settings that avoid the false positive. This option is a good balance between security, policy size, and ease of maintenance.
  • Never (wildcard only)
    : The system does not add URLs that match the wildcard to the security policy, and suggests changing the attributes of matched wildcard entities.
Maximum Learned HTTP URLs
Limits the number of URLs that the security policy allows. The default is
10000
.
Learn Allowed Methods on URLs
If selected, when the system learns a new URL with a method, it selects the override methods enforcement setting. If using automatic learning, suggestions are made for the new URL only. For manual learning, suggestions are made to add the method to the URL and to the policy as well.
Classify Request Content of Learned HTTP URLs
If the system detects legitimate XML or JSON data for URLs in the security policy, the system adds or suggests you add XML or JSON profiles to the security policy and configures their attributes according to the data it detects.
Collapse many common URLs into one wildcard URL
Collapses many common explicit URLs into one wildcard URL with a common prefix and suffix. The system collapses URLs only in the same directory (with the same prefix path) and the same file extension. The system creates a wildcard with no slash.
File types for which wildcard URLs will be configured (e.g. *.jpg)
Specifies the file types for which to create a wildcard URL instead of adding explicit URLs. The system includes several by default.

Adding disallowed HTTP URLs

For some web applications, you may want to deny requests for certain URLs. In this case, you can create a set of disallowed URLs. A disallowed URL can be an explicit URL or a wildcard. Adding disallowed URLs is useful, for example, to prevent access to an administrative interface to the web application such as
/admin/config.php
.
  1. On the Main tab, click
    Security
    Application Security
    URLs
    Disallowed URLs
    Disallowed HTTP URLs
    .
    The Disallowed HTTP URLs screen opens.
  2. In the
    Current edited security policy
     list near the top of the screen, verify that the security policy shown is the one you want to work on.
  3. Click
    Create
    .
    The New Disallowed HTTP URL screen opens.
  4. For the
    URL
     setting, select
    Explicit
     or
    Wildcard.
     If you select Wildcard, select if to leave
    Wildcard Match Includes Slashes
     enabled (default) or to disable it.
  5. Select
    HTTP
     or
    HTTPS
     as the protocol for the URL, and type the URL that the security policy considers illegal; for example,
    /index.html
    .
    URLs are case-sensitive unless you cleared the
    Security Policy is case sensitive
     option when you created the policy.
  6. Optional. Choose a method from the drop down list to create an API endpoint: URL + Method.
  7. Click
    Create
    .
    The Disallowed HTTP URLs screen opens and lists the URL.
  8. To put the security policy changes into effect immediately, click
    Apply Policy
    .
If a requested URL is on the disallowed HTTP URLs list, the system ignores, learns, logs, or blocks the request depending on the settings you configure for the
Illegal URL
 violation on the Learning and Blocking Settings screen. You can view learning suggestions for disallowed HTTP URLs on the Traffic Learning screen.

Creating allowed WebSocket URLs

You can manually create
allowed WebSocket URLs
, which are URLs from which the security policy accepts messages over WebSocket connections. You do this if you have a short list of WebSocket URLs to protect and you know their paths.
If you are using automatic learning, the security policy protects WebSocket URLs automatically, and you do not have to add them. Learning settings for WebSocket URLs are on the Learning and Blocking Settings screen.
  1. On the Main tab, click
    Security
    Application Security
    URLs
    Allowed URLs
    Allowed WebSocket URLs
    .
    The Allowed WebSocket URLs screen opens.
  2. Click
    Create
    .
    The New Allowed WebSocket URL screen opens.
  3. In the
    Current edited security policy
     list near the top of the screen, verify that the security policy shown is the one you want to work on.
  4. Next to
    Create New Allowed WebSocket URL
    , select
    Advanced
    .
  5. For
    WebSocket URL
    , choose a type and protocol, and then type the URL name or wildcard.
    Type
    Description
    Explicit
    Specifies a specific WebSocket URL, such as
    /chat.room.com/websocket
    . Select
    WS
     (for unencrypted text) or
    WSS
     (for encrypted text), and type the URL in the adjacent field.
    Wildcard
    Specifies a wildcard expression to represent a number of URLs. Any URL that matches the wildcard expression is considered legal. The pure wildcard (*) is automatically added to the security policy so you do not need to add it. But you can add other wildcards such as
    /main/*
    . Select
    WS
     (for unencrypted text) or
    WSS
     (for encrypted text), and type a wildcard expression in the adjacent field.
  6. Retain the default selected
    Perform Staging
     check box.
    Keep it selected so you can check for false positives before enforcing the new URL.
  7. For wildcard WebSocket URLs, leave
    Wildcard Match Includes Slashes
     selected.
    When this option is selected, an asterisk in a wildcard matches any number of path segments (separated by slashes); when cleared, an asterisk matches at most one segment.
  8. On the Message Handling tab, leave
    Check Message Payload
     enabled.
    Based on the traffic and the selections in the
    Payload Enforcement
     setting, the
    Check Message Payload
     setting causes the system to validate the format of WebSocket messages.
  9. For the
    WebSocket Extensions
     list, leave the default value
    Remove Headers
     to select what happens to messages that have WebSocket extensions.
    Other options to ignore extensions (Dangerous! Not recommended.) or block messages with extensions are available, but F5 recommends using the default.
    The system removes the
    Sec-WebSocket-Extensions
     header from the message and allows the WebSocket to be established so messages can be exchanged.
  10. For
    Allowed Message Payload Formats
    , select the format or formats that you want to enforce for WebSocket messages: click
    JSON
     or
    Binary
    .
    At least one format must be selected. (Initially,
    Plain Text
     is always selected.) If you are using a different format and not verifying plain text in messages, you can clear
    Plain Text
    .
  11. For
    Payload Enforcement
    , choose how to validate the message content.
    • To verify plain text or JSON formatting, select the previously created content profile, or create a new one.
    • To enforce binary messages, for
      Maximum Binary Message Size
      , click
      Length
       and type the largest binary message (in bytes) to allow. The default value is
      10000
       bytes.
  12. For
    Maximum Frame Size
    , adjust the frame size, if necessary.
    The default value is
    10000
     bytes.
  13. For
    Maximum Frames per Fragmented Message
    , adjust the number, if necessary.
    The default value is
    100
     frames.
  14. For wildcard WebSocket URLs, on the Meta Characters tab, you can overwrite the global URL character set, and allow or disallow specific meta characters in the WebSocket URL if you need to.
    1. The
      Check characters on this URL
       setting is enabled by default so that the system verifies meta characters in the URL. (If you do not want to check for meta characters, clear the check box and skip to the next step.)
    2. To specify which meta characters to allow or disallow, from the
      Global Security Policy Settings
       list, select any meta characters that you want to specifically allow or disallow, and move them to the
      Overridden Security Policy Settings
       list.
    3. For each meta character that you moved, set the state to
      Allow
       or
      Disallow
      .
    The Overridden Security Policy Settings take precedence over the global settings for the web application character set.
  15. If your web site uses CORS (Cross-Origin Resource Sharing), click the HTML5 Cross-Domain Request Enforcement tab.
    1. For
      Enforcement Mode
      , select
      Enforce on ASM
      .
    2. On the HTML5 Cross-Domain Request Enforcement tab, specify how to enforce CORS on this WebSocket URL. For details, see
      Setting Up Cross-Domain Request Enforcement
      .
  16. Click
    Create
    .
    The Allowed WebSockets URLs screen opens and lists the new WebSocket URL.
  17. To put the security policy changes into effect immediately, click
    Apply Policy
    .
The security policy allows requests for the WebSocket URLs that you added. If the WebSocket URL is in staging, the system informs you when learning suggestions are available or when it is ready to be enforced.

Adding disallowed WebSocket URLs

For some web applications, you might want to deny requests for certain WebSocket URLs. In this case, you can create a set of disallowed WebSocket URLs. Disallowed WebSocket URLs can be explicit or a wildcard.
  1. On the Main tab, click
    Security
    Application Security
    URLs
    Disallowed URLs
    Disallowed WebSocket URLs
    .
    The Disallowed WebSocket URLs screen opens.
  2. In the
    Current edited security policy
     list near the top of the screen, verify that the security policy shown is the one you want to work on.
  3. Click
    Create
    .
    The New Disallowed WebSocket URL screen opens.
  4. For the
    WebSocket URL (Explicit only)
     setting, select
    Explicit
     or
    Wildcard
    . If you select Wildcard, select if to leave
    Wildcard Match Includes Slashes
     enabled (default) or to disable it.
  5. Select
    WS
     or
    WSS
     as the protocol for the URL, and type the WebSocket URL that the security policy considers illegal; for example,
    /index.html
    .
    URLs are case-sensitive unless you cleared the
    Security Policy is case sensitive
     option when you created the policy.
  6. Click
    Create
    .
    The Disallowed WebSocket URLs screen opens and lists the URL.
  7. To put the security policy changes into effect immediately, click
    Apply Policy
    .
If a requested URL is on the disallowed WebSocket URLs list, the system ignores, learns, logs, or blocks the request depending on the settings you configure for the
Illegal URL
 violation on the Learning and Blocking Settings screen. You can view learning suggestions for disallowed WebSocket URLs on the Traffic Learning screen.

Enforcing requests for HTTP URLs based on header content

Before you can enforce requests for URLs using header content, you need to have added an allowed HTTP URL.
When you manually create a new allowed HTTP URL, the system reviews requests for the URL using HTTP parsing. The system automatically creates a default header-based content profile for HTTP, and you cannot delete it. However, requests for an URL may contain other types of content, such as JSON, XML, or other proprietary formats.
You can use header-based content profiles to configure how the system recognizes and enforces requests for this URL according to the header content in the request. You can also use header-based content profiles to block traffic based on the type of header and header value in requests for a URL.
  1. On the Main tab, click
    Security
    Application Security
    URLs
    .
    The Allowed HTTP URLs screen opens.
  2. In the
    Current edited security policy
     list near the top of the screen, verify that the security policy shown is the one you want to work on.
  3. In the Allowed URLs List, click the name of the URL for which you want to specify legal header content.
    The Allowed HTTP URL Properties screen opens where you can modify the properties of the URL.
  4. From the
    Allowed URL Properties
     list, select
    Advanced
    .
  5. On the Header-Based Content Profiles tab, specify the header and value as follows:
    1. In the
      Request Header Name
       field, type the explicit header name that must appear in requests for this URL. This field is not case-sensitive.
    2. In the
      Request Header Value
       field, type the pattern string for the header value to find in legal requests for this URL, for example,
      *json*
      ,
      xml_method?
      , or
      method[0-9]
      . This field is case-sensitive.
      If a header value includes this pattern, the system assumes that the request contains the type of data you select in the
      Request Body Handling
       setting.
    3. From the
      Request Body Handling
       list, specify how the system recognizes and enforces requests for this URL according to the requests’ header content:
      Option
      Result
      Apply Content Signatures
      Do not parse the content; scan the entire payload with full-content attack signatures.
      Apply Value and Content Signatures
      Do not parse the content or extract parameters; process the entire payload with value and full-content attack signatures. This option provides basic security for protocols other than HTTP, XML, JSON, and GWT; for example, use
      *amf*
       as the header value for a content-type of Action Message Format.
      Disallow
      Block requests for an URL containing this header content. The system logs the
      Illegal Request Content Type
       violation.
      Do Nothing
      Do not inspect or parse the content. Handle the header of the request as specified by the security policy.
      Form Data
      Parse content as posted form data in either URL-encoded or multi-part formats. Enforce the form parameters according to the policy.
      GWT
      Examine data in requests, based on the configuration of a GWT (Google Web Toolkit) profile associated with this URL.
      JSON
      Examine JSON data using an associated JSON profile, and use value attack signatures to scan the element values.
      XML
      Examine XML data using an associated XML profile.
    4. If the content is GWT, JSON, or XML, for
      Profile Name
      , select an existing profile or click the Create (+) button to create one. (The other options do not require special profiles.)
    5. Click
      Add
      .
  6. Click
    Update
    .
  7. To put the security policy changes into effect immediately, click
    Apply Policy
    .
If the system detects a request for a URL that contains header content that is disallowed in the URL's Header-Based Content Profile, the
Illegal request content type
 violation occurs.

Specifying characters legal in URLs

When you create a security policy, you select a language encoding (or let the system determine it automatically) that determines the characters that can be used in URLs. You can view or modify which characters the security policy allows or disallows in URLs.
  1. On the Main tab, click
    Security
    Application Security
    URLs
    Character Set
    .
    The URLs Character Set screen opens, where you can view the character set, and state of each character.
  2. In the
    Current edited security policy
     list near the top of the screen, verify that the security policy shown is the one you want to work on.
  3. Use the
    View
     filter to display the set of characters that you want to see.
    To restore the default character set definitions, you can click the
    Restore Defaults
     button at any time.
  4. To modify which characters the system should permit or prohibit in the name of a wildcard URL, click
    Allow
     or
    Disallow
     next to the character.
  5. Click
    Save
     to save the changes.
  6. To put the security policy changes into effect immediately, click
    Apply Policy
    .
The security policy checks that URLs in requests do not include any disallowed characters. For example, by disallowing the characters <, >, ', and |, a security policy protects against many cross-site scripting attacks and injection attacks.

Overriding methods on URLs

You can define a list of methods that are allowed or disallowed for a specific URL. The list overrides the list of methods allowed or disallowed globally at the policy level.
If you are using automatic learning, on the Learning and Blocking Settings screen, under URLs, you can select
Learn Methods on URLs
; the system automatically learns overridden methods at the URL level. In that case, you do not need to perform this task.
  1. On the Main tab, click
    Security
    Application Security
    URLs
    .
    The Allowed HTTP URLs screen opens.
  2. In the
    Current edited security policy
     list near the top of the screen, verify that the security policy shown is the one you want to work on.
  3. From the Allowed HTTP URLs List, click the name of the URL you want to modify.
    The Allowed HTTP URL Properties screen opens.
  4. From the
    Allowed URL Properties
     list, select
    Advanced
    .
  5. Toward the bottom of the screen, click the Methods Enforcement tab.
  6. Select the
    Override policy allowed methods
     check box.
  7. In the Method Enforcement tab, from the
    Global Security Policy Settings
     list, select any specific methods that you want to enable or disable for this URL, and then move them into the
    Overridden Security Policy Settings
     list.
    The screen lists the methods in the state opposite from the global setting.
  8. If the method you want to override is not listed, click
    Create Custom Method
     to add a new method to the security policy. Type the method name, and select whether the new method should act as GET or POST.
  9. Click
    Update
    .
  10. To put the security policy changes into effect immediately, click
    Apply Policy
    .
The methods you selected are treated differently for this URL than for the rest of the security policy. If the method causes an
Illegal method
 violation due to URL level enforcement, the description reads
Illegal method for URL
. (If the violation is caused at the policy level, the description reads
Illegal method for policy
.) If the URL is in staging, and the violation is due to override, the violation does not block even if it is in blocking mode.

Configuring flows to URLs

Before you can configure a flow, you should have created the explicit HTTP URL for which you want to add the flow.
A
flow
 defines the access path leading from one explicit HTTP URL to another, between a referrer URL and a target URL in a web application. For example, a basic web page may include a graphic and hyperlinks to other pages in the application. The calls from the basic page to the other pages make up the flow. You can configure flows to a URL.
Configuring flows is an optional task. Unless you need the enhanced security of configured flows, F5 Networks recommends that you do not configure flow-based security policies due to their complexity.
  1. On the Main tab, click
    Security
    Application Security
    URLs
    .
    The Allowed HTTP URLs screen opens.
  2. In the
    Current edited security policy
     list near the top of the screen, verify that the security policy shown is the one you want to work on.
  3. From the Allowed HTTP URLs List, click the name of the URL you want to modify.
    The Allowed HTTP URL Properties screen opens.
  4. From the
    Allowed URL Properties
     list, select
    Advanced
    .
  5. If you want the system to verify flows to this URL, select the
    Check Flows To URL
     check box.
  6. On the menu bar, click
    Flows to URL
    .
    The Flows to URL screen opens and shows the flows to that specific URL.
  7. Above the Flows to URL area, click
    Create
    .
    The Create a New Flow popup screen opens.
  8. For the
    Referrer URL
     setting, specify how the client enters the application.
    • If you want the client to enter the application from this URL, select
      Entry Point
      .
    • To specify the path of a referrer URL that refers to other URLs in the application, select
      URL Path
      ; for example, type
      /index.html
      .
  9. From the
    Protocol
     list, select the appropriate protocol,
    HTTP
     or
    HTTPS
    .
  10. From the
    Method
     list, select the HTTP method that the URL expects a visitor to use to access the authenticated URL, for example,
    GET
     or
    POST
    .
  11. In the
    Frame Target
     field, type the index (
    0
    -
    29
    , or
    99
    ) of the HTML frame in which the URL belongs, if the web application uses frames.
    If your web application does not use frames, type the value
    1
    .
  12. If this flow can contain a query strings or POST data, select the
    Allow QS/PD
     check box.
  13. If you want the system to verify query strings or POST data for this flow, select the
    Check QS/PD
     check box.
  14. Click
    OK
    .
    The popup screen closes, and on the Flows to URL screen, you see the HTTP URLs from which the URL can be accessed.
  15. To view the entire application flow, click
    Security
    Application Security
    URLs
    Flows List
    .
  16. To view the flow or modify the flow properties, click the URL in the Flows list.
  17. To put the security policy changes into effect immediately, click
    Apply Policy
    .
You now have the option of creating parameters that are associated with the flow.

Creating flow parameters

Before you can create a flow parameter, you need to first have created the flow to which the parameter applies. If the source URL is a referrer URL, that HTTP URL must already be defined in the security policy as well.
You define parameters in the context of a flow when it is important to enforce that the target HTTP URL receives a parameter only from a specific referrer URL. Flow parameters provide very tight, flow-specific security for web applications. With this increased protection comes an increase in maintenance and configuration time. Note that if your application uses dynamic parameters, you need to manually add those to the security policy.
  1. On the Main tab, click
    Security
    Application Security
    Parameters
    .
  2. In the
    Current edited security policy
     list near the top of the screen, verify that the security policy shown is the one you want to work on.
  3. Click
    Create
    .
    The Add Parameter screen opens.
  4. In the Create New Parameter area, for the
    Parameter Name
     setting, specify the type of parameter you want to create.
    • To create a named parameter, select
      Explicit
      , then type the name.
    • To use pattern matching, select
      Wildcard
      , then type a wildcard expression. Any parameter name that matches the wildcard expression is permitted by the security policy.
    • To create an unnamed parameter, select
      No Name
      . The system creates a parameter with the label,
      UNNAMED
      .
  5. In the
    Parameter Level
     setting, select
    Flow
    , and then for
    From URL
     define where the flow must come from:
    • If the source URL is an entry point, click
      Entry Point
      .
    • If the source URL is a referrer URL (already defined in the policy), click
      URL Path
      , select the protocol used for the URL, then type the referrer URL associated with the flow.
    When you begin to type the URL, the system lists all referrer URLs that include the character you typed, and you can select the URL from the list.
  6. In the
    Parameter Level
     setting, for
    Method
    , select the HTTP method (
    GET
     or
    POST
    ) that applies to the target referrer URL (already defined in the policy).
  7. In the
    Parameter Level
     setting, for
    To URL
    , select the protocol used for the URL, then type the target URL.
  8. Leave the
    Perform Staging
     check box selected if you want the system to evaluate traffic before enforcing this parameter.
    Staging helps reduce the occurrence of false positives.
  9. If the parameter is required in the context of the flow, select the
    Is Mandatory Parameter
     check box.
    Note that only flows can have mandatory parameters.
  10. Specify whether the parameter requires a value:
    • If the parameter is acceptable without a value, leave the
      Allow Empty Value
       setting enabled.
    • If the parameter must always include a value, clear the
      Allow Empty Value
       check box.
  11. To allow users to send a request that contains multiple parameters with the same name, select the
    Allow Repeated Occurrences
     check box.
    Before enabling this check box, consider that requests containing multiple parameters of the same name could indicate an attack on the web application (HTTP Parameter Pollution).
  12. If you want to treat the parameter you are creating as a sensitive parameter (data not visible in logs or the user interface), enable the
    Mask Value in Logs
     setting.
  13. For the
    Parameter Value Type
     setting, select the format of the parameter value.
    Depending on the value type you select, the screen refreshes to display additional configuration options.
  14. Click
    Create
     to add the new parameter to the security policy.
  15. To put the security policy changes into effect immediately, click
    Apply Policy
    .
When you create a parameter that is associated with a flow, the system verifies the parameter in the context of the flow. For example, if you define a parameter in the context of a GET request, and a client sends a POST request that contains the parameter, the system generates an
Illegal Parameter
 violation.

Configuring dynamic flows to URLs

Before you can configure a dynamic flow, you must have created the explicit HTTP URL for which you want to add the dynamic flow.
Some web applications contain HTTP URLs with dynamic names, for example, the links to a server location for file downloads, where the file name may be unique to each user. You can configure the system to detect these URLs by creating a dynamic flow. For the dynamic flow, you specify a regular expression that describes the dynamic name, and associate the flow with the URL.
  1. On the Main tab, click
    Security
    Application Security
    URLs
    .
    The Allowed HTTP URLs screen opens.
  2. In the
    Current edited security policy
     list near the top of the screen, verify that the security policy shown is the one you want to work on.
  3. From the Allowed HTTP URLs List, click the name of the URL you want to modify.
    The Allowed HTTP URL Properties screen opens.
  4. On the menu bar, click
    Dynamic Flows from URL
    .
    The Flows to URL screen opens and shows the flows to that specific URL.
  5. Above the Dynamic Flows to URL area, click
    Create
    .
    The Create a New Dynamic Flow popup screen opens.
  6. In the
    Prefix
     field, type a fixed substring that appears near the top of the HTML source page before the dynamic URL.
    The prefix may be the name of a section in combination with HTML tags, for example,
    <title>Online Banking</title>
    .
  7. For the
    RegExpValue
     setting, type a regular expression that specifies the set of URLs that make up the dynamic flow, for example, a set of archive files.
  8. For the
    Suffix
     setting, type a fixed string that occurs in the referring URL’s source code, and is physically located after the reference to the dynamic name URL.
  9. Click
    OK
    .
    The popup screen closes, and on the Dynamic Flows from URL screen, you see the dynamic flow extraction properties.
  10. To put the security policy changes into effect immediately, click
    Apply Policy
    .
The regular expression describes the dynamic URL name. The Application Security Manager extracts dynamic URL names from the URL responses associated with the dynamic flow.

Configuring dynamic session IDs in URLs

If an application uses dynamic information in URLs (for example, user names), the Application Security Manager cannot use its normal functions to extract and enforce HTTP URLs or flows because the URI contains a dynamic element. If the web application that you are securing could contain dynamic information in a URL, you can allow dynamic session IDs in URLs. (You only need to configure this setting if you know that your application works this way.)
  1. On the Main tab, click
    Security
    Application Security
    Security Policies
    Policies List
    .
    The Policies List screen opens.
  2. Click the name of the security policy you want to work on.
    The Policy Summary screen opens.
  3. From the list, select
    Advanced
    .
  4. For the
    Dynamic Session ID in URL
     setting, specify how the security policy should process URLs that use dynamic sessions.
    Use this option
    When
    Custom pattern
    The security policy uses a user-defined regular expression to recognize a dynamic session ID in URLs. Type a regular expression in the
    Value
     field, and a description in the
    Description
     field.
    Default pattern
    The security policy uses the default regular expression (
    \/sap\([^)]+\)
    ) for recognizing dynamic session IDs in URLs.
    Disabled
    The security policy does not enforce dynamic session IDs in URLs. This is the default value.
  5. Click
    Save
     to save your settings.
  6. To put the security policy changes into effect immediately, click
    Apply Policy
    .
Normally, if the system receives a request in which the dynamic session information does not match the settings in the security policy, the system issues the
Illegal session ID in URL
 violation. When you allow dynamic session IDs in URLs, ASM extracts the dynamic session information from requests or responses, based on the pattern that you configure. For requests, the system applies the pattern to the URI up to, but not including, the question mark (?) character in a query string.
The system can extract dynamic information only from illegal URLs.

Adding Cookies

About cookies

Many web-based applications use cookies to help users navigate the web site efficiently and perform certain functions. For example, web servers may use cookies to authenticate users logging in to secure applications, or an application can use cookies to store user preferences. Whether using automatic policy building or manually creating a security policy, you may want to add cookies that the web application uses.
You may want a security policy to ignore certain known and recognized cookie headers that are included in HTTP requests. For example, if cookies can change on the client side legitimately, you can create
allowed cookies
.
You may also want a security policy to prevent changes to specific cookies, such as session-related cookies that are set by the application. If so, you can create
enforced cookies
. The cookie in the request must not be modified, or it generates the Modified Domain Cookie violation.
In addition, some PHP applications treat cookies as parameters and use the value of the cookie as input to the application. For that reason, you can have the system check attack signatures on the cookie (as you can for parameters). You can apply attack signatures only to allowed cookies, because enforced cookies are set by the server, and therefore, are considered to be secure.
Both allowed and enforced cookies can be put in staging when they are created so that you can make sure that they do not cause false positives during the staging period.
If you are using automatic policy building, the security policy adds cookies automatically. If manually building a security policy, the manual traffic learning screens suggest cookies to add.

About pure wildcard cookies

When you create a security policy, it includes a pure wildcard (*) and it is created as an allowed cookie in the Allowed Cookies list. You cannot delete the pure wildcard from the security policy but you can change its type from allowed to enforced. The allowed cookie wildcard allows all cookies, and you can specify which cookies the users cannot change in the enforced cookies list .This is considered a negative security model, because you allow all cookies except the ones you specify.
However, new cookies are added to the security policy (or not) based on the
Learn New Cookies
 value of the matched wildcard in the Learning and Blocking settings. The value can be
Never (wildcard only)
 or
Selective
. The default value differs depending on the deployment scenario you use to create the policy.
The following deployments create pure wildcard cookies using the value
Never (wildcard only)
, thus they do not add (or suggest to add) explicit cookies to the security policy:
  • All templates (including Rapid Deployment policy)
  • Automatic policy building with Fundamental policy template
  • Vulnerability assessment
All other policy templates create the pure wildcard cookie with
Learn New Cookies
 set to
Selective
. So it adds (if building the policy automatically) or suggests to add (if building the policy manually) explicit cookies encountered in the traffic to the security policy.
In
Selective
 mode, the system learns cookies that violate the settings of the wildcard. In particular, cookies that do not change are learned as enforced cookies. Most cookies are added to the security policy as allowed cookies, and are checked for the configured signature set. These are captured by the * pure wildcard. The exceptions are the enforced cookies and cookies that need to be exempted from some of the signature checks. These are whitelisted.

Wildcard syntax

The syntax for wildcard entities is based on shell-style wildcard characters. This table lists the wildcard characters that you can use in the names of file types, URLs, parameters, or cookies so that the entity name can match multiple objects.
Wildcard Character
Matches
*
All characters
?
Any single character
[abcde]
Exactly one of the characters listed
[!abcde]
Any character not listed
[a-e]
Exactly one character in the range
[!a-e]
Any character not in the range

About cookies and learning

When you create a security policy that includes cookies, the system adds new cookies (or suggests that you add them) to the security policy (or not) based on the Learn New Cookies value. The value can be Never (do not add cookies) or Selective (add cookies that match the wildcard). The default value differs depending on the policy template you use to create the policy.
The following deployments create pure wildcard cookies using the value Never, thus they do not add (or suggest to add) explicit cookies to the security policy by default:
  • Rapid Deployment policy
  • Automatic policy building with Fundamental policy type
  • Vulnerability assessment
All other templatex create the pure wildcard cookie with Learn New Cookies set to Selective. So the system adds (if building the policy automatically) or suggests to add (if building the policy manually) explicit cookies encountered in the traffic to the security policy.
You could start by having the wildcard set to selective in the allowed cookies, get a list of all the cookies that your web application uses, then move them to the enforced list. This would make it easier to add the cookies that your web application uses and that you want to enforce to the security policy.

About adding cookies

Application Security Manager™ (ASM) allows you to add cookies with different characteristics to security policies.
You can specify the cookies that you want to allow, and the ones you want to enforce in a security policy:
  • Allowed cookies: The system allows these cookies and clients can change them.
  • Enforced cookies: The system enforces the cookies in the list (not allowing clients to change them) and allows clients to change all others.
If the cookies in the web application change, you can edit or delete the cookies.

Adding allowed cookies

You manually add allowed cookies to a security policy when you want a security policy to ignore those cookies. You may want to add allowed cookies for certain known and recognized cookie headers that are often included in HTTP requests. For example, if clients can change certain cookies legitimately and they are not session-related (like cookies assigned by single sign-on servers), you can specify these cookies as allowed in the security policy.
  1. On the Main tab, click
    Security
    Application Security
    Headers
    .
    The Cookies List screen opens.
  2. In the
    Current edited security policy
     list near the top of the screen, verify that the security policy shown is the one you want to work on.
  3. Click
    Create
    .
    The New Cookie screen opens.
  4. For
    Cookie Name
     identify the cookie.
    1. From the list, select whether the system identifies the cookie by a specific name (
      Explicit
      ), or by a regular expression (
      Wildcard
      ).
      The pure wildcard (*) is automatically added to the security policy so you do not need to add it. But you can add other wildcards such as
      *site.com
      .
    2. In the field, type either the name of the cookie, or the pattern string for the wildcard to match cookie names.
  5. For
    Cookie Type
    , select
    Allowed
    .
  6. Leave the
    Perform Staging
     check box selected if you want the security policy to evaluate traffic before enforcing this entity.
    Staging helps reduce the occurrence of false positives.
  7. If you want the system to add the HttpOnly attribute to the response header of the domain cookie, select the
    Insert HttpOnly attribute
     check box.
    This attribute prevents the cookie from being modified or intercepted on the client side, by unwanted third parties that run scripts on the web page. The client's browser allows only pure HTTP or HTTPS traffic to access the protected cookie.
  8. If you want the system to add the SameSite attribute to the response header of the domain cookie, select
    Insert SameSite attribute
    .
    This attribute allows servers to instruct the browser not to send cookies along with cross-site requests. This assertion allows mitigation of CSRF attacks. The Strict option instructs the browser not to send the cookie with any cross-site request, even when the user follows a link. The Lax option allows some cross-site usage.
    If multiple SameSite attributes are present, the browser will implement the strictest value. If the SameSite attribute was set by an application, the system will add another attribute-value pair at the end only if the policy setting is more strict than all SameSite attribute values in the request. If the last attribute value is the same as in the policy, no insertion will be done. The system allows making enforcement more strict, but not more relaxed.
  9. If you want the system to add the Secure attribute to the response header of the domain cookie, select the
    Insert Secure attribute
     check box.
    This attribute ensures that cookies are returned to the server only over SSL, which prevents the cookie from being intercepted. It does not, however, guarantee the integrity of the returned cookie.
  10. If this is a custom cookie that may include base64 encoding, select the
    Base64 Decoding
     check box.
    If the cookie contains a Base64 encoded string, the system decodes the string and continues with its security checks.
  11. To adjust the attack signature settings for this cookie, use the Attack Signatures tab. Tip: The most common action you perform here is to disable a specific attack signature for a specific cookie.
    1. If you want to override the attack signature settings for this cookie, select the
      Check attack signatures on this cookie
       check box.
      When this option is selected, the system displays a list of attack signatures.
    2. From the
      Global Security Policy Settings
       list, move any attack signatures whose global settings you want to override into the
      Overridden Security Policy Settings
       and adjust the state as needed.
  12. Click
    Create
    .
    The new cookie is created and added to the list.
  13. To put the security policy changes into effect immediately, click
    Apply Policy
    .
The system ignores allowed cookies in requests, and allows clients to change allowed cookies in the list.

Adding enforced cookies

You manually add enforced cookies to a security policy when you want a security policy to prevent clients from changing those cookies.
  1. On the Main tab, click
    Security
    Application Security
    Headers
    .
    The Cookies List screen opens.
  2. In the
    Current edited security policy
     list near the top of the screen, verify that the security policy shown is the one you want to work on.
  3. Click
    Create
    .
    The New Cookie screen opens.
  4. For
    Cookie Name
     identify the cookie.
    1. From the list, select whether the system identifies the cookie by a specific name (
      Explicit
      ), or by a regular expression (
      Wildcard
      ).
      The pure wildcard (*) is automatically added to the security policy so you do not need to add it. But you can add other wildcards such as
      *site.com
      .
    2. In the field, type either the name of the cookie, or the pattern string for the wildcard to match cookie names.
  5. For
    Cookie Type
    , select
    Enforced
    .
  6. Leave the
    Perform Staging
     check box selected if you want the security policy to evaluate traffic before enforcing this entity.
    Staging helps reduce the occurrence of false positives.
  7. If you want the system to add the HttpOnly attribute to the response header of the domain cookie, select the
    Insert HttpOnly attribute
     check box.
    This attribute prevents the cookie from being modified or intercepted on the client side, by unwanted third parties that run scripts on the web page. The client's browser allows only pure HTTP or HTTPS traffic to access the protected cookie.
  8. If you want the system to add the Secure attribute to the response header of the domain cookie, select the
    Insert Secure attribute
     check box.
    This attribute ensures that cookies are returned to the server only over SSL, which prevents the cookie from being intercepted. It does not, however, guarantee the integrity of the returned cookie.
  9. Click
    Create
    .
    The new cookie is created and added to the list.
  10. To put the security policy changes into effect immediately, click
    Apply Policy
    .
If a request contains a modified or unsigned enforced cookie header and the Modified domain cookie(s) violation is set to alarm or block, the system logs and/or blocks the request (when the system is in blocking mode). Note that the request is not blocked if the enforced cookie is in staging, or if the security policy is in transparent mode.

Changing the order in which wildcard cookies are enforced

If you create several wildcard cookies, the security policy adds each new one to the top of the wildcard cookies list. The cookie wildcards are enforced from the top of the list down. You can change the order in which a security policy enforces wildcard cookies.
  1. On the Main tab, click
    Security
    Application Security
    Headers
    Cookie Wildcards Order
    .
    The Cookie Wildcards Order screen opens.
  2. In the
    Current edited security policy
     list near the top of the screen, verify that the security policy shown is the one you want to work on.
  3. In the
    Wildcard Cookies
     list, adjust the order of the cookie wildcards by using the
    Up
     and
    Down
     buttons putting the cookies you want to enforce first at the top of the list.
  4. Click
    Save
     to save the changes.
  5. To put the security policy changes into effect immediately, click
    Apply Policy
    .
The system enforces the cookie wildcards from the top down.

Editing cookies

You can edit cookies as required by changes in the web application that the security policy is protecting.
  1. On the Main tab, click
    Security
    Application Security
    Headers
    .
    The Cookies List screen opens.
  2. In the
    Current edited security policy
     list near the top of the screen, verify that the security policy shown is the one you want to work on.
  3. Select either the Enforced Cookies or Allowed Cookies tab to locate the cookie you want to edit.
  4. In the Cookie Name column, click the cookie name.
    The Edit Cookie screen opens.
  5. In the Cookie Properties area, make the required changes to the cookie.
  6. Click
    Update
     to save the changes.
  7. To put the security policy changes into effect immediately, click
    Apply Policy
    .

Deleting cookies

You can delete cookies that are no longer needed in your security policy. If a cookie changes in your application, you may want to delete the old cookie and let Application Security Manager add the new cookie (or suggest adding it).
  1. On the Main tab, click
    Security
    Application Security
    Headers
    .
    The Cookies List screen opens.
  2. In the
    Current edited security policy
     list near the top of the screen, verify that the security policy shown is the one you want to work on.
  3. Select either the Enforced Cookies or Allowed Cookies tab to locate the cookie you want to edit.
  4. In the Enforced Cookies or Allowed Cookies list, select the check box next to the cookie you want to delete.
  5. Click
    Delete
     to delete the entity, and click
    OK
     when asked to confirm.
  6. To put the security policy changes into effect immediately, click
    Apply Policy
    .

Specifying when to add explicit cookies

You can specify the circumstances under which Application Security Manager adds, or suggests you add, explicit cookies to the security policy.
  1. On the Main tab, click
    Security
    Application Security
    Policy Building
    Learning and Blocking Settings
    .
    The Learning and Blocking Settings screen opens.
  2. In the
    Current edited security policy
     list near the top of the screen, verify that the security policy shown is the one you want to work on.
  3. Expand
    Cookies
    , in the
    Learn New Cookies
     setting, select the option you want.
    Option
    Description
    Never (wildcard only)
    The system does not add or suggest that you add cookies that match the wildcard to the policy. When false positives occur, the system suggests relaxing the settings of the wildcard entity. This option results in a security policy that is easy to manage but may not be as strict.
    Selective
    The system adds or suggests that you add cookies that match the wildcard to the policy. When false positives occur, the system adds or suggests that you add an explicit entity with relaxed settings that avoid the false positive. This option provides a good balance between security, policy size, and ease of maintenance.
  4. Click
    Save
     to save the changes.
  5. To put the security policy changes into effect immediately, click
    Apply Policy
    .

Configuring the maximum cookie header length

You specify a maximum cookie header length so that the system knows the acceptable maximum length for the cookie header in an incoming request. This setting is useful primarily in preventing buffer overflow attacks.
  1. On the Main tab, click
    Security
    Application Security
    Security Policies
    .
    The Policies List screen opens.
  2. Click the name of the security policy you want to work on.
    The Policy Summary opens.
  3. From the list, select
    Advanced
    .
  4. For the
    Maximum Cookie Header Length
     setting, select one of the options.
    Option
    Description
    Any
    Specifies that the system accepts requests with cookie headers of any length.
    Length
     with a value in bytes
    Specifies that the system accepts cookie headers up to that length. The default maximum length is
    8192
     bytes.
  5. Click
    Save
     to save your settings.
  6. To put the security policy changes into effect immediately, click
    Apply Policy
    .
The system calculates and enforces the cookie header length based on the sum of the length of the cookie header name and value. Requests with headers that are longer than the maximum length cause an Illegal header length violation.

Overview: Configuring advanced cookie protection

Many of the Application Security Manager™ (ASM) security features store ASM™ cookies on clients as part of the traffic security enforcement. Examples of security features that use cookies for validation are cookie enforcement, parameter enforcement, CSRF protection, login enforcement, session tracking, and anomaly detection. Cookie enforcement is also called
domain cookies
; cookies for the other features are called
other ASM cookies
.
The system applies a random security key unique to each deployment and uses it in conjunction with an encryption algorithm. The combination of the randomly generated key and the selected algorithms is called the
security context
. Normally, you do not have to change the cookie protection settings. However, in cases where you suspect a security breach has occurred, or if you want a different balance between speed and security, you can reconfigure cookie protection.
By default, when you initially start the system, it automatically generates a security key and sets the cookie security level to secure. You can change the encryption schema to provide faster cookie protection by reconfiguring cookie protection.
If you want to use the same security context on other systems, you can set up advanced cookie configuration settings on one BIG-IP system and export them. You can then import the settings on the other systems. You can configure all your systems to use the same cookie protection, or apply different settings to the systems. However, if you have multiple ASM-enabled devices that share traffic (and are not synchronized using device groups), it is recommended that those systems should all use the same cookie protection settings.
If synchronizing multiple ASM systems using device groups, you can configure the settings you want to use for all systems on one and then synchronize the systems.

Reconfiguring cookie protection

Application Security Manager (ASM) automatically configures cookie protection. If you need to adjust cookie protection due to a security breach or because you want to change the current protection level, you can reconfigure cookie protection.
This is an advanced configuration task that is required only in special circumstances.
  1. On the Main tab, click
    Security
    Options
    Application Security
    Advanced Configuration
    Cookie Protection
    .
    The Cookie Protection screen opens.
  2. Review the data and time specified in the
    Latest Generation/Import Configuration Time
     setting to see when cookie protection was last configured.
  3. To review the details of the cookie protection, click
    View Algorithms Configuration
    .
    The screen shows the specific algorithms the system uses to protect domain and other ASM cookies.
  4. If you decide that you want to change the cookie configuration, click
    Reconfigure Cookie Protection.
    The Reconfigure Cookie Protection screen opens.
  5. For
    Grace Period Until signing with new Security Context
    , type the amount of time in minutes that must pass before the system begins signing ASM cookies with the new key and algorithm that you are configuring.
    The default value is
    30
     minutes. Initially when you start the system, this is the period the system waits to apply the new security context for the new release.
  6. For
    Grace Period To Accept Old Cookies
    , type the amount of time in minutes that must pass before the system stops accepting traffic with ASM cookies that use the old key and algorithm.
    The default value is
    2880
     minutes (48 hours).
  7. For
    Algorithm Selection
    , select the overall cookie security level to apply:
    Secure
     or
    Fast
    .
    The
    Secure
     setting uses more system resources.
    Changing this setting changes the Scramble and Mac algorithms used for cookie protection.
  8. If you want to review the actual algorithms used for the cookies, you can do this:
    1. For the
      Cookie Protection Configuration
       setting, select
      Advanced
      .
      The screen shows additional settings.
    2. Review the scramble and Mac algorithms used for the domain cookies and other ASM cookies, and adjust them if needed.
      If you use settings other than the defaults, the
      Algorithm Selection
       changes to
      Custom
      .
  9. Click
    Reconfigure
    .
    The system regenerates a new security context but waits to start using it until it surpasses the grace period until signing value.
  10. If you need to extend either of the grace periods, click
    Extend
     and type the number of minutes to add and click
    Save
    .

Importing cookie protection configuration

If you want to use the same cookie configuration settings on more than one Application Security Manager (ASM) system (especially systems that share traffic), you can export the settings from one system and import them onto another one. This task explains how to import the settings.
  1. On the Main tab, click
    Security
    Options
    Application Security
    Advanced Configuration
    Cookie Protection
    .
    The Cookie Protection screen opens.
  2. Click
    Import
    .
    The Import Cookie Protection Configuration screen opens.
  3. From the
    Import Method
     list, select
    Upload file
     and locate the previously exported configuration file.
    The exported file has a name such as
    ASM_Cookie_Protection_Configuration_2013-08-15_08-22.txt
    .
  4. To review the details of the cookie protection, click
    View Algorithms Configuration
    .
    The screen shows the specific algorithms the system uses to protect domain and other ASM cookies.
  5. For
    Grace Period Until signing with new Security Context
    , type the amount of time in minutes that must pass before the system begins signing ASM cookies with the new key and algorithm that you are configuring.
    The default value is
    30
     minutes. Initially when you start the system, this is the period the system waits to apply the new security context for the new release.
  6. For
    Grace Period To Accept Old Cookies
    , type the amount of time in minutes that must pass before the system stops accepting traffic with ASM cookies that use the old key and algorithm.
    The default value is
    2880
     minutes (48 hours).
  7. Click
    Import
    .
    The system imports the security context but waits to start using it until the grace period until signing is up.
  8. If you need to extend either of the grace periods, click
    Extend
     and type the number of minutes to add and click
    Save
    .

Exporting cookie protection configuration

If you want to use the same cookie configuration settings on more than one Application Security Manager system, you can export the settings from one system and import them onto another one. This task explains how to export the settings to a file.
  1. On the Main tab, click
    Security
    Options
    Application Security
    Advanced Configuration
    Cookie Protection
    .
    The Cookie Protection screen opens.
  2. Click
    Export
    .
    The system exports the cookie protection configuration to a file with a name such as
    ASM_Cookie_Protection_Configuration_2013-08-15_08-22.txt
    .

Adding Allowed Methods to a Security Policy

Adding allowed methods

All security policies accept standard HTTP methods by default. If your web application uses HTTP methods other than the default allowed methods (GET, HEAD, and POST), you can add them to the security policy.
  1. On the Main tab, click
    Security
    Application Security
    Headers
    Methods
    .
    The Methods screen opens.
  2. In the
    Current edited security policy
     list near the top of the screen, verify that the security policy shown is the one you want to work on.
  3. Click
    Create
    .
  4. For the
    Method
     setting, select the type of method to allow:
    • To use an existing HTTP method to act as a GET or POST action, select
      Predefined
       then select the system-supplied method to add to the allowed methods list.
    • To add an option that is not predefined, select
      Custom
      , and then in the
      Custom Method
       field, type the name of a method.
  5. If using flows in the security policy, from the
    Allowed Method Properties
     list, select
    Advanced
    , then from the
    Act as Method
     list, select an option:
    • If you do not expect requests to contain HTTP data following the HTTP header section, select
      GET
      .
    • If you expect requests to contain HTTP data following the HTTP header section, select
      POST
      .
  6. Click
    Create
    .
  7. To put the security policy changes into effect immediately, click
    Apply Policy
    .
The method is added to the allowed methods list. The system treats any incoming HTTP request that uses an HTTP method other than an allowed method as an invalid request. The system ignores, learns, logs, or blocks the request depending on the settings configured for the
Illegal Method
 violation under Headers on the Learning and Blocking Settings screen.
Contact Support Contact Support

Have a Question?

Support and Sales >

About F5

Education

F5 Sites

Support Tasks




©2023 F5, Inc. All rights reserved.


Trademarks Policies Privacy California Privacy Do Not Sell My Personal Information