Apprentice
← all rooms
CSRF Medium

Cross-Site Request Forgery

Forge state-changing requests. Some actions lack tokens; one is protected.

Mission briefing

SecurePanel is a self-service account console for a SaaS product. Users can update email, toggle alerts, and change passwords from the browser. Test whether a malicious site could perform those actions on a logged-in victim's behalf.

0 / 3 tasks 0 / 30 pts

Objectives

  • Change email without a CSRF token
  • Toggle notifications via a GET request
  • Confirm the password form rejects forged posts
Task 1 Email Change (no token) Medium 10 pts

Scenario

SecurePanel lets logged-in users change their email from a simple POST form. The form has no one-time token or referrer check. Change the account email without using the legitimate UI flow.

Your approach

  1. Log in with the provided demo credentials on the account panel.
  2. Use dev tools or an intercepting proxy to capture the email change request.
  3. Replay the POST from curl or a self-made HTML form without session UI.
  4. Confirm the email updates and the lab displays a success flag.
  5. Submit the flag shown after the change.

Log in (admin/admin) and change the email without any CSRF token.

Open lab →
Hint

POST to /labs/csrf/email with email=...

Task 2 Notifications via GET Medium 10 pts

Scenario

Notification preferences toggle via a GET link with an enabled parameter. Merely visiting the URL flips the setting—no confirmation step. Turn notifications on using a cross-site request.

Your approach

  1. While logged in, open the notifications page and note the GET URL pattern.
  2. Craft a request with enabled set to true outside the app UI.
  3. Optionally host an img tag pointing at that URL on another origin.
  4. Verify notifications show as enabled and the lab reveals its flag.
  5. Submit the task flag.

The notifications toggle is driven by a GET parameter.

Open lab →
Hint

An <img src> on another site could trigger this.

Task 3 Protected Password Form Medium 10 pts

Scenario

Password changes require a hidden field tied to the user's session. Posts missing that field should fail safely. Confirm the protection works, then record the lab's verification flag.

Your approach

  1. Inspect the password form for a hidden token field name.
  2. Send a POST with new password values but omit the token.
  3. Read the error indicating the token is invalid or missing.
  4. Note the lab's success message for proving the form is protected.
  5. Submit the task flag associated with this verification step.

The password form requires a signed CSRF token.

Open lab →
Hint

POST without csrf=... should show Invalid or missing CSRF token.