CSRF where token is not tied to user session

Description

This lab’s email change functionality is vulnerable to CSRF. It uses tokens to try to prevent CSRF attacks, but they aren’t integrated into the site’s session handling system.

Reproduction and proof of concept

  1. Open Burp’s browser and log in to the wiener victim account. Submit the “Update email” form, intercept the resulting request, and send it to the Repeater to check vulnerabilities: remove csrf token, change request method, change csrf token, and whether token is tied to user session.

  2. Make a note of the value of the CSRF token, then drop the request.

  3. Open a private/incognito browser window, log in to Portswigger, then on the lab site into the carlos attacker account, and copy its token (using Web Developer tools).

  4. Observe that if you swap the CSRF token with the value from the other account, then the request is accepted.

  5. Create and host a proof of concept exploit as described in the solution to the CSRF vulnerability with no defenses lab (above). The CSRF tokens are single-use, so get a fresh one from the incognito window carlos account.

CSRF

  1. Store the exploit, then click Deliver to victim.

Exploitability

An attacker needs to use the exploit server to host an HTML page that uses a CSRF attack to change the viewer’s email address. There are two accounts on the application that can be used to design the attack. The credentials are as follows, wiener:peter and carlos:montoya.