Red Teaming Guide

Cookies

beginner
cookies session httponly secure

Cookies in HTTP are managed through specific headers, mainly used for storing and sending small pieces of data between the client (browser) and the server. Here are the main cookie-related HTTP headers and their purposes:

  • Purpose: The server uses this header to send a cookie to the client. The browser will store this cookie and send it back in future requests to the same server.

  • Example:

      Set-Cookie: sessionId=abc123; Path=/;    HttpOnly; Secure; SameSite=Strict

  • Why: Allows the server to instruct the browser to store a cookie with specific attributes (like expiration, scope, security).

  • Purpose: The browser sends this header to the server with all cookies that belong to the requested domain and path.

  • Example:

      Cookie: sessionId=abc123; theme=dark

  • Why: To pass stored cookies back to the server for maintaining session state, personalization, or tracking.

Why these headers exist?

Cookies are essential for maintaining state in the otherwise stateless HTTP protocol. They allow:

  • Session Management: Login sessions, shopping carts, user preferences.

  • Personalization: Theme, language settings.

  • Tracking: Analytics, advertising, user behavior.

Summary:

Header Sent By Purpose
Set-Cookie Server Send a cookie with attributes to store on the client
Cookie Client Send stored cookies back to the server

Cookie attributes define how cookies behave, what security measures they have, and when they’re sent. Here’s a rundown of the most common cookie attributes and their purposes:

Attribute Description & Purpose
Expires Sets a specific date/time when the cookie expires. After this date, the cookie is deleted by the browser. Used for persistent cookies.
Max-Age Sets the lifetime of the cookie in seconds. When it reaches 0, the cookie is deleted. Overrides Expires if both are set.
Domain Specifies the domain for which the cookie is valid. Allows sharing cookies across subdomains if set correctly. If omitted, defaults to the origin domain.
Path Specifies the URL path for which the cookie is valid. The cookie will be sent only if the request URL matches this path. Defaults to the request path that set the cookie.
Secure When set, the cookie is only sent over secure HTTPS connections. Prevents sending cookies over unencrypted HTTP, enhancing security.
HttpOnly Prevents JavaScript running in the browser from accessing the cookie via document.cookie. Helps mitigate cross-site scripting (XSS) attacks.
SameSite Controls whether cookies are sent with cross-site requests, helping to prevent Cross-Site Request Forgery (CSRF) attacks. It has three possible values:
  - Strict: Cookie sent only in first-party context (never with cross-site requests). Strongest CSRF protection.
  - Lax: Cookie sent with top-level navigations and GET requests initiated by third parties. Balanced security/usability. Default in many browsers.
  - None: Cookie sent with all requests, including cross-site. Requires Secure attribute to be set.

Why These Attributes Matter

  • Security: HttpOnly, Secure, and SameSite reduce the risk of cookie theft, XSS, and CSRF attacks.

  • Scope Control: Domain and Path control where cookies are sent, preventing unnecessary exposure.

  • Persistence: Expires and Max-Age define how long cookies last, distinguishing between session and persistent cookies.

Set-Cookie: sessionId=abc123; Path=/; Domain=example.com; Expires=Wed, 21 Oct 2025 07:28:00 GMT; Secure; HttpOnly; SameSite=Strict

This cookie:

  • Is valid for all paths on example.com

  • Expires on Oct 21, 2025

  • Sent only over HTTPS (Secure)

  • Not accessible to JavaScript (HttpOnly)

  • Sent only on same-site requests (SameSite=Strict)

If you want, I can dive into how these attributes impact security in real-world scenarios or how browsers handle them!