Recently, I have been getting more interested in Web Penetration Testing, especially topics like authentication, session management, CSRF, and access control.

Compared to simply memorising payloads, I want to better understand the root causes behind web vulnerabilities:

  • Why do they happen?
  • Why do defensive mechanisms sometimes fail?
  • How should a pentester think about these issues in practice?

Because of that, I started reading some web security papers. While looking for papers, I came across this interesting USENIX Security 2023 paper:

Cookie Crumbles: Breaking and Fixing Web Session Integrity
Marco Squarcina, Pedro Adão, Lorenzo Veronese, Matteo Maffei
Paper: https://www.usenix.org/system/files/usenixsecurity23-squarcina.pdf

What caught my attention is that the paper does not simply repeat the usual advice like “set HttpOnly, Secure, and SameSite on cookies.” Instead, it asks a more fundamental question:

If an attacker cannot steal a cookie, but can influence which cookies are sent by the victim’s browser, can we still trust the web session?

This perspective was quite useful for me. When learning web security, it is easy to reduce cookie security to something like:

XSS steals cookie → session hijacking

But this paper reminded me that cookie security is not only about confidentiality. It is also about integrity.

When I used to think about cookie security, the first things that came to mind were:

  • HttpOnly prevents JavaScript from reading the cookie
  • Secure ensures the cookie is only sent over HTTPS
  • SameSite helps reduce CSRF risk

These protections are important, but the paper focuses on another layer of the problem:

ConceptMeaningCommon example
Cookie confidentialityThe attacker can read the cookie valueXSS stealing a session cookie
Cookie integrityThe attacker can cause the browser to send attacker-controlled cookiesSession fixation, cookie tossing, CSRF/CORF token fixation

I think this distinction is very important.

HttpOnly can stop JavaScript from reading a cookie, but it does not necessarily stop a cookie from being influenced, shadowed, evicted, or fixated through other mechanisms.

In other words:

Just because a cookie was not stolen does not mean the session is safe.

For web pentesting, this mindset matters. Instead of only checking whether a response contains HttpOnly, I should also ask:

  • Is the cookie scope too broad?
  • Is Domain=.example.com being used unnecessarily?
  • Is the session ID rotated after login?
  • Are CSRF secrets refreshed after authentication?
  • Can a sibling subdomain influence cookies used by the main application?

2. SameSite Is Not the Same as Same-Origin

Another useful part of the paper is how clearly it separates same-origin from same-site.

For example:

https://app.example.com
https://auth.example.com
https://dev.example.com

These are not necessarily same-origin, but they may still be same-site because they belong to the same registrable domain: example.com.

This distinction is very practical.

In real company environments, a single main domain often has many subdomains:

www.example.com
api.example.com
auth.example.com
staging.example.com
dev.example.com
old-campaign.example.com

If one sibling subdomain has a weakness, such as:

  • subdomain takeover
  • XSS on an old staging site
  • misconfigured third-party SaaS
  • abandoned cloud resources

an attacker may not need to compromise the main application directly. They may be able to abuse their same-site position to influence cookie behaviour.

This is an important point for pentesters:

Web application security should not only focus on the main app. Subdomain hygiene is also part of session security.

Many junior testers do subdomain enumeration mainly to find more targets. After reading this paper, I see another reason to care about subdomains: they help define the same-site attack surface.

One of the core ideas in the paper is cookie tossing / cookie shadowing.

A simplified example:

A legitimate application sets:

Set-Cookie: sid=good; Path=/

But if an attacker can set a domain cookie from a sibling domain, they may be able to set something like:

Set-Cookie: sid=evil; Path=/login; Domain=example.com

When the victim visits:

https://app.example.com/login

the browser may send:

Cookie: sid=evil; sid=good

At this point, how the server-side framework parses duplicate cookie names becomes very important. Some implementations may use the first value, while others may behave differently.

The issue is that the browser and the server may not interpret cookies in exactly the same way.

This reminds me of a broader theme in web security:

Security issues often appear when two components interpret the same data differently.

For example, HTTP request smuggling can happen when a frontend and backend disagree about request boundaries. In this case, the interpretation gap is between the browser, server, framework, and cookie parsing logic.

This perspective is useful for me because it reminds me to look for interpretation gaps between different components during web testing.

4. CORF Token Fixation: CSRF Tokens Can Also Be Bypassed

The attack type I found most memorable in the paper is CORF Token Fixation.

In the traditional understanding, a CSRF token should prevent forged requests because the attacker does not know the token.

However, the paper shows that if an attacker can fixate a pre-login session, and the application keeps the same CSRF secret after login, then a token known before authentication may still be valid after the victim logs in.

A simplified flow looks like this:

1. The attacker visits the target and obtains a pre-session + CSRF token
2. The attacker causes the victim's browser to use the attacker-controlled pre-session cookie
3. The victim logs in normally
4. The application does not refresh the CSRF secret after login
5. The attacker reuses the previously known token to trigger an authenticated action

I think this attack flow is worth remembering as a web pentester because it highlights one important idea:

Authentication is not just a single moment. It is a lifecycle.

The state before login, during login, and after login can all become part of the attack surface.

So when testing login flows, I should not only ask:

Does login work?
Is the password policy strong enough?
Is MFA enabled?

I should also ask:

Is the session ID regenerated after login?
Is the CSRF secret refreshed after login?
Is pre-login session data carried into the authenticated session?
Is session state properly cleared during logout and re-login?

This is one of my biggest practical takeaways from the paper.

5. SameSite Is Defense-in-Depth, Not a Complete Fix

Many tutorials say that SameSite=Lax or SameSite=Strict can help prevent CSRF. This is not wrong, but it can create the impression that SameSite is the ultimate fix for CSRF.

This paper made one limitation clearer to me:

SameSite mainly restricts cross-site requests, but it may not stop a same-site attacker.

For example, if an attacker controls:

evil.example.com

and the target is:

app.example.com

they may still be considered same-site.

In this situation, SameSite may not be enough.

My current understanding is:

SameSite is useful, but it should not be the only CSRF or session integrity control.

A more complete approach should include:

  • using appropriate cookie scope
  • avoiding unnecessary Domain attributes
  • considering the __Host- prefix for sensitive cookies
  • regenerating the session ID after login
  • refreshing CSRF secrets after login
  • reducing untrusted subdomains under the same registrable domain

6. Takeaways for My Pentest Checklist

After reading this paper, I think session integrity testing deserves a place in my web pentest checklist.

[ ] Does the session cookie use Secure?
[ ] Does the session cookie use HttpOnly?
[ ] Does the session cookie use SameSite?
[ ] Is the cookie using an overly broad Domain=.example.com scope?
[ ] Can sensitive cookies use the __Host- prefix?

Login transition

[ ] Does the session ID change after login?
[ ] Is the CSRF secret refreshed after login?
[ ] Is guest / pre-login session data preserved after authentication?
[ ] Is session and token state properly cleared after logout?

Same-site attack surface

[ ] Are there many staging, dev, or old subdomains?
[ ] Is there any subdomain takeover risk?
[ ] Is there XSS on sibling domains?
[ ] Can any third-party service in a same-site position set cookies?

These checks may not be fully testable in every engagement, but as a thinking framework, I find them very valuable.

7. My Summary

The biggest lesson I took from this paper is that web security problems often do not come from a single broken control. They can appear when multiple reasonable mechanisms are combined in unexpected ways.

For example:

  • the browser has its own cookie standard
  • the server framework has its own parser
  • the CSRF library has its own token handling
  • the authentication middleware has its own session lifecycle

Each layer may look reasonable on its own, but when combined, they can create session integrity issues.

As someone still learning web pentesting, this paper helped me build an important mindset:

Pentesting should not only be checklist-based testing. It should also involve understanding how application state flows, where trust boundaries exist, and whether different components interpret state differently.

I do not need to fully understand every formal verification detail or browser implementation detail in the paper yet. However, several core takeaways are already very practical for me:

  1. HttpOnly prevents cookie reading, but it does not guarantee cookie integrity.
  2. SameSite helps, but it is not a complete defense against same-site attackers.
  3. After login, applications should regenerate the session ID and refresh CSRF secrets.
  4. Subdomain security can affect the session security of the main application.
  5. Many web security issues appear at the boundary between browser, server, framework, and library behaviour.

When I do web pentest labs or bug bounty-style practice in the future, I want to pay closer attention to login flows, CSRF token lifecycle, cookie scope, and same-site attack surface.

For me, this paper is not just an academic paper. It is a useful reminder:

Valuable web testing is not just about knowing payloads. It is about understanding how an application trusts state.