Product Documentation
ADC
14.1 - Current Release 13.1 13.0 12.1
View PDF

Cookie hijacking protection

February 9, 2024
Contributed by: 
B C S

Cookie hijacking protection mitigates cookie stealing attacks from hackers. In the security attack, an attacker takes over a user session to gain unauthorized access to a web application. When a user browses a website, for example banking application, the website establishes a session with the browser. During the session, the application saves the user details such as login credentials, page visits in a cookie file. The cookie file is then sent to the client browser in the response. The browser stores the cookies to maintain active sessions. The attacker can steal these cookies either manually from the cookie store of the browser or through some rouge browser extension. The attacker then use these cookies to gain access into the user’s web application sessions.

To mitigate cookie attacks, the Citrix ADC Web App Firewall (WAF) challenges the TLS connection from the client along with WAF cookie consistency validation. For every new client request, the appliance validates the TLS connection and also verifies the consistency of application and session cookie in the request. If an attacker tries to mix and match application cookies and session cookies stolen from the victim, the cookie consistency validation fails, and the configured cookie hijack action is applied. For more information about cookie consistency, see Cookie Consistency Check topic.

Note:

The Cookie hijacking feature supports logging and SNMP traps. For more information about logging, see ADM topic and for more information about SNMP configuration see SNMP topic.

Limitations

  • JavaScript must be enabled in the client browser.
  • Cookie Hijacking protection is not supported on TLS version 1.3.
  • Limited support for the Internet Explorer (IE) browser because the browser does not reuse the SSL connections. Results in multiple redirects sent for a request eventually leading to a “MAX REDIRECTS EXCEEDED” error in the IE browser.

The following scenarios explain how cookie hijacking protection works in a Citrix ADC appliance.

Cookie hijacking attack use case 1: user access without session cookie

  1. The user attempts to authenticate into a web application and begins to access the first webpage without any ADC session cookie in the request.
  2. When the request is received, the appliance creates an Application Firewall session with a session cookie ID.

  3. This initiates a TLS connection for the session. Since the JavaScript is not sent and ran on the client browser, the appliance marks the TLS connection as validated and no challenge is required.

    Note:

    Even if an attacker tries to send all the app cookie IDs from a victim without sending the session cookie, the appliance detects the issue and strips off all the app cookies in the request before forwarding the request to the back-end server. The back end server considers this request without no app cookie and takes necessary as per its configuration.

  4. When the back-end server sends a response, the appliance receives the response and forwards it with a JavaScript session token and seed cookie. The appliance then marks the TLS connection as verified.
  5. When the client browser receives the response, the browser runs the JavaScript and generates a morphed cookie ID using the session token and seed cookie.
  6. When a user sends a subsequent request over the TLS connection, the appliance bypasses the morphed cookie validation. This is because the TLS connection is already validated.

Cookie hijacking attack use case 2: user access over new TLS with session cookie

  1. When a user sends an HTTP request for successive pages over a new TLS connection, the browser sends session cookie ID and morphed cookie ID.
  2. Since this is a new TLS connection, the appliance detects the TLS connection and challenges the client with redirect response with seed cookie.
  3. The client upon receiving the response from the ADC, calculates the morphed cookie using the session’s token and new seed cookie.
  4. The client then sends this newly calculated morphed cookie along with a session ID.
  5. If the morphed cookie calculated within the ADC appliance and the one sent over the request matches, then the TLS connection is marked as verified.
  6. If the calculated morphed cookie differs from the one present in the client request, then validation fails. After which, the appliance sends the challenge back to the client, to send a proper morphed cookie.

Scenario 3: Attacker impersonating as a non-authenticated user

Cookie hijacking attack use case 3: attacker impersonates as non-authenticated user

  1. When a user authenticates into the web application, the attacker uses different techniques to steal the cookies and replay them.
  2. Since this is a new TLS connection from the attacker, the ADC sends a redirect challenge along with a new seed cookie.
  3. Since the attacker does not have JavaScript running, the response from the attacker for the redirected request does not contain the morphed cookie.
  4. This results in morphed cookie validation failure at the ADC appliance side. The appliance again sends a redirect challenge to the client.
  5. If the number of morphed cookie validation attempts exceeds the threshold limit, the appliance flags the status as cookie hijacking.
  6. If the attacker tries to mix and match application cookies and session cookies stolen from the victim, the cookie consistency check fails, and the appliance applies the configured cookie hijack action.

Scenario 4: Attacker impersonating as an authenticated user

Cookie hijacking attack use case 4: attacker impersonates as authenticated user

  1. Attackers can also attempt to authenticate into a web application as a genuine user and replay the victim’s cookies to gain access to the web session.
  2. The ADC appliance detects such impersonated attackers also. Although a verified TLS connection is used by the attacker in replaying a victim’s cookie, the ADC appliance still verifies if the session cookie and application cookie in the request are consistent. The appliance verifies the consistency of an application cookie using the session cookie in the request. Since the request contains an attacker’s session cookie and a victim’s app cookie, the cookie consistency validation fails.
  3. As a result, the appliance applies the configured cookie hijack action. If the configured action is set as “block,” then the appliance strips off all the application cookies and sends the request to the back-end Server.
  4. The back-end server receives a request with no application cookie and so it responds an error response to the attacker, such as “User not logged in”.

You can select a specific application firewall profile and set one or more actions that prevent cookie hijacking.

At the command prompt, type:

set appfw profile <name> [-cookieHijackingAction <action-name> <block | log | stats | none>]

Note:

By default, the action is set to “none.”

Example:

set appfw profile profile1 - cookieHijackingAction Block

Where, action types are:

Block: Block connections that violate this security check. Log: Log violations of this security check. Stats: Generate statistics for this security check. None: Disable all actions for this security check.

  1. Navigate to Security > Citrix Web App Firewall > Profiles.
  2. On the Profiles page, select a profile and click Edit.
  3. On the Citrix Web App Firewall Profile page, go to Advanced Settings section and click Security Checks.
  4. In the Security Checks section, select Cookie Hijacking and then click Action settings.
  5. In the Cookie Hijacking Settings page, select one or more actions to prevent cookie hijacking.
  6. Click OK.

To handle false positives in cookie consistency validation, you can add a relaxation rule for cookies that can be exempted from cookie validation.

  1. Navigate to Security > Citrix Web App Firewall > Profiles.
  2. On the Profiles page, select a profile and click Edit.
  3. On the Citrix Web App Firewall Profile page, go to Advanced Settings section and click Relaxation rules.

  4. In the Relaxation Rules section, select Cookie Consistency and click Action.

  5. In the Cookie Consistency Relaxation Rule page, set the following parameters.
    1. Enabled. Select if you want to enable the relaxation rule.
    2. Is Cookie Name Regex. Select if the cookie name is a regular expression.
    3. Cookie Name. Enter the name of the cookie that can be exempted from cookie validation.
    4. Regex Editor. Click this option to provide the regular expression details.
    5. Comments. A brief description about the cookie.
  6. Click Create and Close.

View security traffic and security violation details in a tabular or graphical format.

To view security statistics:

At the command prompt, type:

stat appfw profile profile1

Appfw profile Traffic Statistics Rate (/s) Total
Requests 0 0
Request Bytes 0 0
Responses 0 0
Response Bytes 0 0
Aborts 0 0
Redirects 0 0
Long Term Ave Response Time (ms) – 0
Recent Ave Response Time (ms) – 0
HTML/XML/JSON Violation Statistic Rate (/s) Total
Start URL 0 0
Deny URL 0 0
Referer header 0 0
Buffer overflow 0 0
Cookie consistency 0 0
Cookie hijacking 0 0
CSRF form tag 0 0
HTML Cross-site scripting 0 0
HTML SQL injection 0 0
Field format 0 0
Field consistency 0 0
Credit card 0 0
Safe object 0 0
Signature Violations 0 0
Content Type 0 0
JSON Denial of Service 0 0
JSON SQL injection 0 0
JSON Cross-Site Scripting 0 0
File Upload Types 0 0
Infer Content Type XML Payload 0 0
HTML CMD Injection 0 0
XML Format 0 0
XML Denial of Service (XDoS) 0 0
XML Message Validation 0 0
Web Services Interoperability 0 0
XML SQL Injection 0 0
XML Cross-Site Scripting 0 0
XML Attachment 0 0
SOAP Fault Violations 0 0
XML Generic Violations 0 0
Total Violations 0 0
HTML/XML/JSON Log Statistics Rate (/s) Total
Start URL logs 0 0
Deny URL logs 0 0
Referer header logs 0 0
Buffer overflow logs 0 0
Buffer overflow logs 0 0
Cookie consistency logs 0 0
Cookie hijacking logs 0 0
CSRF form tag logs 0 0
HTML cross-site scripting logs 0 0
HTML cross-site scripting transform logs 0 0
HTML SQL Injection logs 0 0
HTML SQL transform logs 0 0
Field format logs 0 0
Field consistency logs 0 0
Credit cards 0 0
Credit card transform logs 0 0
Safe object logs 0 0
Signature logs 0 0
Content Type logs 0 0
JSON Denial of Service logs 0 0
JSON SQL injection logs 0 0
JSON Cross-Site Scripting logs 0 0
File upload types logs 0 0
Infer Content Type XML Payload L 0 0
HTML Command Injection logs 0 0
XML Format logs 0 0
XML Denial of Service(XDoS) logs 0 0
XML Message Validation logs 0 0
WSI logs 0 0
XML SQL Injection logs 0 0
XML cross-site scripting logs 0 0
XML Attachment logs 0 0
SOAP Fault logs 0 0
XML Generic logs 0 0
Total log messages 0 0
Server Error Response Statistics Rate (/s) Total
HTTP Client Errors (4xx Resp) 0 0
HTTP Server Errors (5xx) 0 0
  1. Navigate to Security > Citrix Web App Firewall > Profiles.
  2. In the details pane, select a Web App Firewall profile and click Statistics.
  3. The Citrix Web App Firewall Statistics page displays the cookie hijacking traffic and violation details.
  4. You can select Tabular View or switch to Graphical View to display the data in a tabular or graphical format.

Cookie hijacking violation statistics on Citrix ADC GUI

Cookie hijacking protection
February 9, 2024
Contributed by: 
B C S
February 9, 2024
Contributed by: 
B C S

In this article

Site feedback | Your privacy choices footer linkYour Privacy Choices | Privacy and legal terms | Cookie preferences | Consent settings | docs.cloud.com
© 1999- Cloud Software Group, Inc. All rights reserved.