Session Riding
debt(d5/e3/b3/t5)
Closest to 'specialist tool catches it' (d5), because detection_hints.tools lists owasp-zap and semgrep — both specialist SAST/DAST tools. The absence of a CSRF token or missing SameSite attribute won't be caught by a compiler or default linter; it requires running one of these dedicated security scanners against the codebase or a live application.
Closest to 'simple parameterised fix' (e3), grounded in the quick_fix: add synchronizer CSRF tokens to state-changing forms/endpoints plus set SameSite cookie attributes. This is a small but deliberate fix that may touch several form templates and session configuration, but it is a well-understood, repeatable pattern rather than a multi-file architectural refactor.
Closest to 'localised tax' (b3), because the mitigation (CSRF tokens, SameSite cookies) is scoped to web/api form-submission and session configuration contexts. It imposes a recurring but bounded tax — developers must remember to include tokens on state-changing endpoints — without reshaping the broader architecture or affecting unrelated subsystems.
Closest to 'notable trap' (t5), directly grounded in the misconception field: developers commonly believe session riding and CSRF are distinct attacks and may treat them separately or not recognise one from the other. Additionally, common_mistakes show that developers frequently add a CSRF token but skip server-side validation or reuse the same token across all users, revealing that the 'obvious' partial implementation is still exploitable.
Also Known As
TL;DR
Explanation
Session riding emphasises the mechanism of CSRF: the attacker's request piggybacks on the victim's existing browser session. Unlike session hijacking (which steals the session token), session riding leaves the token with the legitimate user — it simply abuses the browser's automatic cookie inclusion in cross-origin requests. The term is used interchangeably with CSRF in some literature. Defences are identical: SameSite cookies, synchronised CSRF tokens, and Origin/Referer header validation.
Common Misconception
Why It Matters
Common Mistakes
- No CSRF token on state-changing forms and API endpoints.
- CSRF tokens that are not rotated per session or per request.
- Same CSRF token for all users — a leaked token compromises all users.
- Not validating the CSRF token server-side — client-side validation only is bypassable.
Code Examples
// No CSRF protection — any site can submit this form on behalf of the user:
<form method="POST" action="/transfer">
<input name="to" value="attacker">
<input name="amount" value="1000">
</form>
// Attacker hosts: <form id='f' ...></form><script>f.submit()</script>
// Victim visits attacker page → transfer executes using victim's session// Session riding = CSRF exploiting the session cookie
// 1. SameSite=Strict — blocks cross-site cookie submission
ini_set('session.cookie_samesite', 'Strict');
// 2. CSRF token in every state-changing form
$_SESSION['csrf'] = bin2hex(random_bytes(32));
// <input type="hidden" name="_csrf" value="<?= $_SESSION['csrf'] ?>">
if (!hash_equals($_SESSION['csrf'], $_POST['_csrf'] ?? '')) abort(403);
// 3. Verify Origin header for AJAX
$origin = $_SERVER['HTTP_ORIGIN'] ?? '';
if (parse_url($origin, PHP_URL_HOST) !== 'yourapp.com') abort(403);
// 4. Re-authenticate for sensitive actions (transfers, email change, delete)