R029. Cookies with security attributes

Requirement

The session cookies of web applications must have security attributes (HttpOnly, Secure, SameSite) and prefixes (e.g., __Host-).

Description

When you have web applications that handle sessions, you can use different attributes to improve the security related to the cookies that handle these sessions. The attributes HttpOnly and Secure prevent the theft of the session cookie by denying the browser visibility and access to it (even when Cross Site Scripting [XSS] attacks are used) and allow the cookie to be sent only when the request is encrypted (using HTTPS). In this manner, session theft is greatly mitigated.

Implementation

  1. Implement the HttpOnly attribute: If the HttpOnly attribute is present in the HTTP response header, the cookie cannot be accessed using client side scripts. As a result, and even if there is a cross-site scripting (XSS) vulnerability and a user accidentally accesses the link that exploits this vulnerability, the browser will not reveal the cookie to a third party. * If a browser does not support HttpOnly and the website tries to set the HttpOnly attribute, said attribute will be ignored by the browser, thus creating a traditional cookie accessible by scripts. Consequently, the cookie (usually a session cookie) becomes vulnerable to theft or modification by a malicious script.

  2. Implement the Secure attribute: The secure attribute is an option that can be applied from the application server when a new cookie is sent to the user in a HTTP response. The purpose of the secure attribute is to prevent cookies from being viewed by unauthorized third parties due to the plain text transmission of the cookie.

Exceptions

  1. Exceptions for the HttpOnly attribute: Web applications that use JavaScript for the majority of their operations may use an anti-Cross-Site-Request-Forgery(CSRF) technique that relies on same-origin policy. This technique consists of setting a cookie containing a random token. Client side JavaScript reads its value and copies it into a custom HTTP CSRF header sent with each request. The security of this technique is based on the assumption that only JavaScript running within the same origin will be able to access the cookie. JavaScript running from a rogue file or email will not be able to read and copy it into the custom header. Even though the CSRF cookie will be automatically sent with the rogue request, the server will be still expecting a valid CSRF header. In this implementation, the CSRF cookie must not have HttpOnly attribute, as it is intended to be read by the JavaScript by design. However, the protection provided by this technique can be thwarted if the target website disables its same-origin policy using one of the following techniques:

    • Access-Control-Allow-Origin header set to *.

    • clientaccesspolicy.xml file granting unintended access to Silverlight controls.

    • crossdomain.xml file granting unintended access to Flash.

Attacks

  1. An attacker generates a script that is executed by a valid authenticated user without their knowledge, without the HTTPOnly and Secure attributes the script sends information to the attacker containing the session cookie used for session theft.

  2. An attacker captures HTTP traffic using a Man in The Middle (MiTM) attack intercepting request and responses in plain text and extracting the session cookie used for session theft.

Attributes

  1. Layer: Application layer

  2. Asset: Session management

  3. Scope: Confidentiality

  4. Phase: Construction

  5. Type of control: Procedure

References

  1. CAPEC-31: Accessing/Intercepting/Modifying HTTP Cookies. This attack relies on the use of HTTP Cookies to store credentials, state information and other critical data on client systems. There are several different forms of this attack. The first form of this attack involves accessing HTTP Cookies to mine for potentially sensitive data contained therein. The second form involves intercepting this data as it is transmitted from client to server.

  2. CWE-346: Origin Validation Error. The software does not properly verify that the source of data or communication is valid.

  3. CWE-352: Cross-Site Request Forgery (CSRF). The web application does not, or can not, sufficiently verify whether a well-formed, valid, consistent request was intentionally provided by the user who submitted the request.

  4. CWE-614: Sensitive Cookie in HTTPS Session Without 'Secure' Attribute. The Secure attribute for sensitive cookies in HTTPS sessions is not set, which could cause the user agent to send those cookies in plaintext over an HTTP session.

  5. CWE-1004: Sensitive Cookie Without 'HttpOnly' Flag. The software uses a cookie to store sensitive information, but the cookie is not marked with the HttpOnly flag.

  6. NIST 800-63B 7.1.1 Browser Cookies Cookies SHALL be tagged to be accessible only on secure (HTTPS) sessions.

  7. NIST 800-63B 7.1.1 Browser Cookies Cookies SHALL be accessible to the minimum practical set of hostnames and paths.

  8. NIST 800-63B 7.1.1 Browser Cookies Cookies SHOULD be tagged to be inaccessible via JavaScript (HttpOnly).

  9. OWASP Top 10 A2:2017-Broken Authentication. Application functions related to authentication and session management are often implemented incorrectly, allowing attackers to compromise passwords, keys, or session tokens, or to exploit other implementation flaws to assume other users' identities temporarily or permanently.

  10. OWASP Top 10 A3:2017-Sensitive Data Exposure. Many web applications and APIs do not properly protect sensitive data, such as financial, healthcare, and PII. Attackers may steal or modify such weakly protected data to conduct credit card fraud, identity theft, or other crimes. Sensitive data may be compromised without extra protection, such as encryption at rest or in transit, and requires special precautions when exchanged with the browser.

  11. OWASP Top 10 A7:2017-Cross-Site Scripting (XSS). XSS flaws occur whenever an application includes untrusted data in a new web page without proper validation or escaping, or updates an existing web page with user-supplied data using a browser API that can create HTML or JavaScript. XSS allows attackers to execute scripts in the victim’s browser which can hijack user sessions, deface web sites, or redirect the user to malicious sites.

  12. OWASP-ASVS v4.0.1 V3.2 Session Binding Requirements.(3.2.3) Verify the application only stores session tokens in the browser using secure methods such as appropriately secured cookies (see section 3.4) or HTML 5 session storage.

  13. OWASP-ASVS v4.0.1 V3.4 Cookie-based Session Management.(3.4.1) Verify that cookie-based session tokens have the 'Secure' attribute set.

  14. OWASP-ASVS v4.0.1 V3.4 Cookie-based Session Management.(3.4.2) Verify that cookie-based session tokens have the 'HttpOnly' attribute set.

  15. OWASP-ASVS v4.0.1 V3.4 Cookie-based Session Management.(3.4.3) Verify that cookie-based session tokens utilize the 'SameSite' attribute to limit exposure to cross-site request forgery attacks.

  16. OWASP-ASVS v4.0.1 V3.4 Cookie-based Session Management.(3.4.4) Verify that cookie-based session tokens use "__Host-" prefix (see references) to provide session cookie confidentiality.

  17. OWASP-ASVS v4.0.1 V3.4 Cookie-based Session Management.(3.4.5) Verify that if the application is published under a domain name with other applications that set or use session cookies that might override or disclose the session cookies, the path attribute in cookie-based session tokens is set using the most precise path possible.

  18. OWASP-ASVS v4.0.1 V4.2 Operation Level Access Control.(4.2.2) Verify that the application or framework enforces a strong anti-CSRF mechanism to protect authenticated functionality, and effective anti-automation or anti-CSRF protects unauthenticated functionality.

  19. OWASP-ASVS v4.0.1 V13.2 RESTful Web Service Verification Requirements.(13.2.3) Verify that RESTful web services that utilize cookies are protected from Cross-Site Request Forgery via the use of at least one or more of the following: triple or double submit cookie pattern, CSRF nonces, or ORIGIN request header checks.

  20. OWASP-ASVS v4.0.1 V14.5 Validate HTTP Request Header Requirements.(14.5.3) Verify that the cross-domain resource sharing (CORS) Access-Control-Allow-Origin header uses a strict white-list of trusted domains to match against and does not support the "null" origin.

  21. [PCI DSS 3.0] 6.5.10 Broken authentication and session management.

  22. PCI DSS v3.2.1 - Requirement 6.5.7 Address common coding vulnerabilities in software-development processes such as cross-site scripting (XSS).

  23. PCI DSS v3.2.1 - Requirement 6.5.9 Address common coding vulnerabilities in software-development processes such as cross-site request forgery (CSRF).

  24. PCI DSS v3.2.1 - Requirement 6.5.10 Address common coding vulnerabilities in software-development processes such as broken authentication and session management.

Copyright © 2020 Fluid Attacks, We hack your software. All rights reserved.

Service status - Terms of Use - Privacy Policy - Cookie Policy