Back to all posts
Day 17Sunday, February 8, 20264 min read

Cookies, Sessions, and Trust Boundaries

foundationscybersecuritywebfundamentalshttplabslearningprocess
View original post

🎯 Goal

Understand how HTTP authentication works in practice, focusing on:

  • how browsers prove user identity
  • what servers actually trust
  • how cookies, headers, and parameters define trust boundaries

The objective was to move beyond theory and observe real session behaviour in a live web application.

✅ What I Did

🌐 Target Selection

Used the AltoroJ (IBM TestFire) demo application, a deliberately vulnerable Java web app.

Why this target:

  • supports login and logout
  • uses server-side sessions
  • exposes clear cookie-based authentication behaviour

Deleting the session cookie reliably broke authentication, confirming correct target choice.

📡 HTTP Request Headers Analysis

Inspected the main document request using browser DevTools.

Identified and classified request headers:

Identity

  • Cookie
    • The only header representing authenticated identity

Context

  • Host
  • Referer (when present)
  • Origin (when present)

Client Fingerprinting

  • User-Agent

This clarified that only cookies identify the user, while other headers merely describe context or client properties.

🔁 HTTP Response Headers Observation

Reviewed server responses for security-relevant behaviour.

Observed:

  • Content-Type defining how the browser interprets responses

Not observed in this response:

  • Set-Cookie
  • explicit security headers (e.g. CSP, HSTS)

Learned that Set-Cookie headers are typically sent only during:

  • session creation
  • login
  • logout

Not seeing them on every response is normal.

🍪 Cookie and Session Behaviour

Identified the session cookie:

  • Name: JSESSIONID
  • Purpose: Links client requests to a server-side session

Flags observed:

  • Secure
  • HttpOnly
  • no SameSite attribute

Key experiment:

  • Deleting JSESSIONID immediately logged the user out

This demonstrated that possession of the session cookie equals authenticated identity.

🔧 Parameters and Client Control

Observed GET parameters in URLs and modified them manually.

Findings:

  • Parameters are fully client-controlled
  • Server responses changed based on parameter values

This reinforced that any parameter trusted for authorization decisions can become a vulnerability, leading to issues such as IDOR or logic flaws.

💡 Key Cybersecurity Connections

Today reinforced several core security concepts:

  • HTTP is stateless; identity is reconstructed on every request
  • Servers trust client-side tokens (cookies) for authentication
  • Headers are mostly contextual, not security guarantees
  • Parameters represent a major trust boundary

These concepts underpin vulnerabilities such as:

  • session hijacking
  • CSRF
  • IDOR
  • authentication bypass

🚧 Challenges

  • Distinguishing request headers from response headers
  • Avoiding assumptions about when cookies should appear
  • Interpreting modern web behavior without classic form submissions
  • Understanding which headers actually matter for security

🧠 What I Learned

  • Authentication is not about passwords, but about trusted tokens
  • Cookies are automatically sent and implicitly trusted
  • Deleting a cookie is a definitive test of session control
  • Security failures often stem from incorrect trust assumptions, not broken crypto

🔜 Next Steps

  • Explore CSRF attacks based on cookie trust
  • Study IDOR vulnerabilities through parameter manipulation
  • Repeat this analysis using Burp Suite for clearer visibility
  • Continue building web security mental models before exploitation

📌 Reflection

Today marked a shift from learning tools to understanding trust boundaries.

Seeing authentication fail by simply deleting a cookie made it clear how fragile web identity really is. This lab connected abstract HTTP concepts to real security consequences and set the stage for deeper web exploitation topics.

🧩 Lessons Learned

What worked

  • Using a deliberately vulnerable application
  • Proving session behavior through direct experimentation

What broke

  • Expecting login to always create new cookies
  • Expecting security behavior to be visible in every response

Why it broke

  • Modern applications often reuse sessions
  • Authentication state is frequently tracked server-side

Fix / takeaway

  • Focus on behavior, not assumptions
  • Possession of a trusted token equals identity
  • Understanding trust boundaries is more important than tools