💻
Application Security Cheat Sheet
  • Application Security Cheat Sheet
  • Android Application
    • Overview
      • Application Data & Files
      • Application Package
      • Application Sandbox
      • Application Signing
      • Deployment
      • Package Manager
    • Intent Vulnerabilities
      • Deep Linking Vulnerabilities
    • WebView Vulnerabilities
      • WebResourceResponse Vulnerabilities
      • WebSettings Vulnerabilities
  • CI/CD
    • Dependency
      • Dependency Confusion
      • Dependency Hijaking
      • Typosquatting
    • GitHub
      • GitHub Actions
      • Code owners
      • Dependabot
      • Redirect
      • Releases
  • Cloud
    • AWS
      • Amazon API Gateway
      • Amazon Cognito
      • Amazon S3
  • Container
    • Overview
      • Container Basics
      • Docker Engine
    • Escaping
      • CVE List
      • Exposed Docker Socket
      • Excessive Capabilities
      • Host Networking Driver
      • PID Namespace Sharing
      • Sensitive Mounts
    • Container Analysis Tools
  • Framework
    • Spring
      • Overview
      • Mass Assignment
      • Routing Abuse
      • SpEL Injection
      • Spring Boot Actuators
      • Spring Data Redis Insecure Deserialization
      • Spring View Manipulation
    • React
      • Overview
      • Security Issues
  • Linux
    • Overview
      • Philosophy
      • File
      • File Descriptor
      • I/O Redirection
      • Process
      • Inter Process Communication
      • Shell
      • Signals
      • Socket
      • User Space vs Kernel Space
    • Bash Tips
  • iOS Application
    • Overview
      • Application Data & Files
      • Application Package
      • Application Sandbox
      • Application Signing
      • Deployment
    • Getting Started
      • IPA Patching
      • Source Code Patching
      • Testing with Objection
  • Resources
    • Lists
      • Payloads
      • Wordlists
    • Researching
      • Web Application
      • Write-ups
    • Software
      • AWS Tools
      • Azure Tools
      • Component Analysis
      • Docker Analysis
      • Dynamic Analysis
      • Fuzzing
      • GCP Tools
      • Reverse Engineering
      • Static Analysis
      • Vulnerability Scanning
    • Training
      • Secure Development
  • Web Application
    • Abusing HTTP hop-by-hop Request Headers
    • Broken Authentication
      • Two-Factor Authentication Vulnerabilities
    • Command Injection
      • Argument Injection
    • Content Security Policy
    • Cookie Security
      • Cookie Bomb
      • Cookie Jar Overflow
      • Cookie Tossing
    • CORS Misconfiguration
    • File Upload Vulnerabilities
    • GraphQL Vulnerabilities
    • HTML Injection
      • base
      • iframe
      • link
      • meta
      • target attribute
    • HTTP Header Security
    • HTTP Request Smuggling
    • Improper Rate Limits
    • JavaScript Prototype Pollution
    • JSON Web Token Vulnerabilities
    • OAuth 2.0 Vulnerabilities
      • OpenID Connect Vulnerabilities
    • Race Condition
    • Server Side Request Forgery
      • Post Exploitation
    • SVG Abuse
    • Weak Random Generation
    • Web Cache Poisoning
Powered by GitBook
On this page
  • Cookie attributes
  • Secure attribute
  • HttpOnly attribute
  • Path attribute
  • Domain attribute
  • Expires attribute
  • Max-Age attribute
  • SameSite
  • Cookie prefix
  • Cookie-list sorting
  • References
  1. Web Application

Cookie Security

Cookie attributes

Ultimate cookie:

Set-Cookie: __Host-SessionID=3h93...;Path=/;Secure;HttpOnly;SameSite=Strict

Secure attribute

The Secure attribute indicates that the cookie is sent to a server only when a request is made with the https: scheme (except on localhost). It only protects the confidentiality of a cookie against MitM attackers - there is no integrity protection. Therefore, cookies with this attribute can still be modified either with access to the client's hard disk or from JavaScript.

Insecure sites http: can't set cookies with the Secure attribute (since Chrome 52 and Firefox 52). For Firefox, the https: requirements are ignored when the Secure attribute is set by localhost (since Firefox 75).

HttpOnly attribute

Cookies marked with the HttpOnly attribute are not accessible from JavaScript. The HttpOnly attribute only protects the confidentiality of a cookie. HttpOnly cookies can be replaced by overflowing the cookie jar from JavaScript.

Path attribute

The Path attribute indicates the path that must exist in the requested URL for the browser to send the Cookie header. It can be used to prevent unauthorized access to cookies from other applications on the same host.

The forward slash / character is interpreted as a directory separator, and subdirectories are matched as well. For example, for Path=/docs:

  • The request paths /docs, /docs/, /docs/Web/, and /docs/Web/HTTP will all match.

  • The request paths /, /docsets, /fr/docs will not match.

Cookie scope vs Same-Origin Policy

Isolation two different applications on shared host

Domain attribute

The Domain attribute defines the host to which the cookie will be sent.

  • If the Domain attribute unspecified, it defaults to the host of the current document location, excluding subdomains

    • IE will always send to subdomains regardless

  • If the Domain attribute is specified, cookies will be sent to that domain and all its subdomains

Expires attribute

The Expires attribute indicates the maximum lifetime of the cookie as an HTTP-date timestamp.

  • If the Expires attribute unspecified, cookie lifetime is equal to session lifetime

    • It is up to the browser to decide when the session ends

  • Non-persistent session cookies may actually be persisted to survive browser restart

References:

Max-Age attribute

The Max-Age attribute indicates the number of seconds until the cookie expires. If both Expires and Max-Age are set, Max-Age has precedence.

SameSite

The SameSite attribute prevents the browser from sending cookies along with cross-site requests. The SameSite attribute can have one of two values (case-insensitive):

  • Strict, means that the browser sends the cookie only for same-site requests, that is, requests originating from the same site that set the cookie. If a request originates from a URL different from the current one, no cookies with the SameSite=Strict attribute are sent.

  • Lax, means that the cookie is not sent on cross-site requests, such as on requests to load images or frames, but is sent when a user is navigating to the origin site from an external site using safe HTTP methods (for example, when following a link). This is the default behavior if the SameSite attribute is not specified. The safe methods: GET, HEAD, OPTIONS and TRACE.

  • None, means that the browser sends the cookie with both cross-site and same-site requests. The Secure attribute must also be set when setting this value, like so SameSite=None; Secure.

References:

Cookie prefix

The cookie prefix allows you to pass metadata about a cookie and notify a client that certain attributes have been set. The following prefixes are supported:

  • __Secure- tells the browser that the Secure attribute is required.

  • __Host- tells the browser that the Path=/ and Secure attributes are required, and at the same time that the Domain attribute should not be present (and therefore, can not be sent to subdomains).

References:

Cookie-list sorting

2.  The user agent SHOULD sort the cookie-list in the following order:

    *  Cookies with longer paths are listed before cookies with shorter paths.

    *  Among cookies that have equal-length path fields, cookies with earlier creation-times are listed before cookies with later creation-times.

Therefore, if a vulnerable application uses the first cookie, you can force it to use your cookie by adding the Path attribute with a longer path.

References

PreviousContent Security PolicyNextCookie Bomb

Last updated 2 years ago

The cookies without the SameSite in Chrome are still treated as None during the first 2 minutes and then as Lax, check out

Keep in mind that same-site and cross-site requests are not the same thing. The SameSite cookie attribute is only concerned with cross-site requests. It does not affect cross-origin requests that refer to the same-site, check out

The standard defines the order of cookies:

MDN Web Docs - Document.cookie
Bypass SameSite Cookies Default to Lax and get CSRF
The great SameSite confusion
MDN Web Docs - Set-cookie: Browser compatibility
MDN Web Docs - Set-cookie: Browser compatibility
RFC6265
MDN Web Docs - Set-cookie