Skip to content

Publish Latest 2026-10-12 #616

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
kingthorin merged 1 commit into from
Oct 12, 2026
Merged

Publish Latest 2026-10-12 #616

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
2 changes: 1 addition & 1 deletion ...ication_Security_Testing/06-Session_Management/05-Cross_Site_Request_Forgery.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -131,7 +131,7 @@ Self-vulnerable applications, i.e. applications that are used both as attack vec

Whether the PoCs above work depends on the session cookie's [`SameSite`](02-Cookies_Attributes.md#samesite-attribute) attribute and the browser's default. See that section for how `SameSite=Lax` treats top-level navigations versus subresource requests.

In short: the `img`-tag PoC is a subresource request, and the auto-submitting form PoC uses `POST` - neither qualifies for the `Lax` top-level-navigation-with-a-safe-method exception, so in a browser that defaults to `Lax` (Chromium-based browsers, since early 2020), the session cookie won't be attached and the PoC as written won't fire. A form using `method="GET"` would still succeed under `Lax`, since that is a top-level `GET` navigation. Note also that [when `Lax` is applied as a default, Chromium-based browsers relax it further for the first two minutes after the cookie is set, still including it on `POST` requests](https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Headers/Set-Cookie#samesitesamesite-value) - so a POST-based PoC fired immediately after authentication may still succeed.
In short: the `img`-tag PoC is a subresource request, and the auto-submitting form PoC uses `POST` - neither qualifies for the `Lax` top-level-navigation-with-a-safe-method exception, so in a browser that defaults to `Lax` (Chromium-based browsers, since early 2020), the session cookie won't be attached and the PoC as written won't fire. A form using `method="GET"` would still succeed under `Lax`, since that is a top-level `GET` navigation. Note also that when `Lax` is applied as a default, [Chromium-based browsers relax it further for the first two minutes after the cookie is set](https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Headers/Set-Cookie#samesitesamesite-value), still including it on `POST` requests - so a POST-based PoC fired immediately after authentication may still succeed.

Don't conclude an application is safe from CSRF just because a PoC fails to fire in one browser - check the actual `Set-Cookie` header for the session cookie, and, if needed, retest in a browser that doesn't default to `Lax` (e.g. Firefox) to confirm whether the underlying vulnerability exists.

Expand Down