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

Applies To:

Show Versions Show Versions

BIG-IP ASM

  • 13.1.5, 13.1.4, 13.1.3, 13.1.1, 13.1.0
Manual Chapter
Table of Contents | << Previous Chapter | Next Chapter >>
 

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 .exefiles), 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).
    Note: 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 Yesin 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.
Note: 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.
    Important: 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 Sensitive Parameter 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.
    Important: 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 Sensitive Parameter 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.
    Important: 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 Sensitive Parameter 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
    Tip: 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.
    Option Description
    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.
    Important: 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.
    Note: 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.
    Option Description
    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.
    Note: 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
Note: 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.
    Option Description
    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.
    Note: 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 and protocol, 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. By default, the Perform Staging check box is selected. F5 recommends that you keep it selected.
  6. If you want to view more options, next to Create New Allowed URL, select Advanced.
  7. 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).
    Tip: 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.
  8. 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.
  9. 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.
  10. 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.
  11. 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.
    Note: The Overridden Security Policy Settings take precedence over the global settings for the web application character set.
  12. Click Create.
    The Allowed URLs screen opens and lists the new URL.
  13. 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. 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 (Explicit only) setting, select HTTP or HTTPS as the protocol for the URL, and type the URL that the security policy considers illegal; for example, /index.html.
    Note: URLs are case-sensitive unless you cleared the Security Policy is case sensitive option when you created the policy.
  5. Click Create.
    The Disallowed HTTP URLs screen opens and lists the URL.
  6. 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.
Note: 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.
    Note: 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.
  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 WS or WSS as the protocol for the URL, and type the WebSocket URL that the security policy considers illegal; for example, /index.html.
    Note: URLs are case-sensitive unless you cleared the Security Policy is case sensitive option when you created the policy.
  5. Click Create.
    The Disallowed WebSocket URLs screen opens and lists the URL.
  6. 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.
    Tip: 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.
Note: 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.
    Tip: 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.
    Important: 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 Sensitive Parameter 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 .
    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 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.

Note: 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.

 

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.
Note: 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.
    Tip: 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.
Table of Contents | << Previous Chapter | Next Chapter >>
Contact Support Contact Support

Have a Question?

Support and Sales >

About F5

Education

F5 Sites

Support Tasks




©2023 F5 Networks, Inc. All rights reserved.


Trademarks Policies Privacy California Privacy Do Not Sell My Personal Information