Manual Chapter : Adding Cookies

Applies To:

Show Versions Show Versions

BIG-IP ASM

  • 11.6.5, 11.6.4, 11.6.3, 11.6.2, 11.6.1
Manual Chapter

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 Explicit Entities value of the matched wildcard. The value can be Never (do not add cookies) or Selective (add cookies that match the wildcard). 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, 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 type
  • Vulnerability assessment

All other deployment scenarios create the pure wildcard cookie with Learn Explicit Entities 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 Explicit Entities value of the matched wildcard. The value can be Never (do not add cookies) or Selective (add cookies that match the wildcard). 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, 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 deployment scenarios create the pure wildcard cookie with Learn Explicit Entities 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 policy list near the top of the screen, verify that the edited security policy 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. For wildcard cookies, from the Learn Explicit Entities list, select whether the system adds explicit entities that match a wildcard entity to the security policy.
    Option Description
    Never (wildcard only) The system does not add or suggest that you add entities 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 entities 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.
    For pure wildcard cookies (*), you specify Explicit Entities Learning on the Policy Building Settings screen.
  8. 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.
  9. If you want the system to add the Secure attribute to the response header of the domain cookie, select the Insert Secure attribute check box.
    This attribute ensures that cookies are returned to the server only over SSL, which prevents the cookie from being intercepted. It does not, however, guarantee the integrity of the returned cookie.
  10. If this is a custom cookie that may include base64 encoding, select the Base64 Decoding check box.
    If the cookie contains a Base64 encoded string, the system decodes the string and continues with its security checks.
  11. To adjust the attack signature settings for this cookie, use the Attack Signatures tab. Tip: The most common action you perform here is to disable a specific attack signature for a specific cookie.
    1. If you want to override the attack signature settings for this cookie, select the Check attack signatures on this cookie check box.
      When this option is selected, the system displays a list of attack signatures.
    2. From the Global Security Policy Settings list, move any attack signatures whose global settings you want to override into the Overridden Security Policy Settings and adjust the state as needed.
  12. Click Create.
    The new cookie is created and added to the list.
  13. To put the security policy changes into effect immediately, click Apply Policy.
The system ignores allowed cookies in requests, and allows clients to change allowed cookies in the list.

Adding enforced cookies

You manually add enforced cookies to a security policy when you want a security policy to prevent clients from changing those cookies.
  1. On the Main tab, click Security > Application Security > Headers .
    The Cookies List screen opens.
  2. In the Current edited policy list near the top of the screen, verify that the edited security policy 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. For wildcard cookies, from the Learn Explicit Entities list, select whether the system adds explicit entities that match a wildcard entity to the security policy.
    Option Description
    Never (wildcard only) The system does not add or suggest that you add entities 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 entities 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.
    For pure wildcard cookies (*), you specify Explicit Entities Learning on the Policy Building Settings screen.
  8. 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.
  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. Click Create.
    The new cookie is created and added to the list.
  11. 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 policy list near the top of the screen, verify that the edited security policy 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 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.
  5. Click Save to save the changes.
  6. 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 policy list near the top of the screen, verify that the edited security policy 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 policy list near the top of the screen, verify that the edited security policy 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 > Settings .
    The Settings screen opens.
  2. In the Current edited policy list near the top of the screen, verify that the edited security policy is the one you want to work on.
  3. In the Explicit Entities Learning setting, for Cookies, 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 Active Policies screen opens.
  2. Click the name of the security policy you want to work on.
    The Properties screen opens.
  3. From the Configuration 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.