This lab's email change functionality is vulnerable to CSRF. It uses tokens to try to prevent CSRF attacks, but they aren't fully integrated into the site's session handling system.
To solve the lab, use your exploit server to host an HTML page that uses a to change the viewer's email address.
You have two accounts on the application that you can use to help design your attack. The credentials are as follows:
wiener:peter
carlos:montoya
First, I logged in as the user wiener
and intercepted the request to change the email address:
I noticed two important cookies: session
and csrfKey
.
Altering the session
cookie redirected me to the login page, indicating it handles session management.
Changing the csrfKey
cookie resulted in an "Invalid CSRF token" error, confirming its role in CSRF protection.
Next, I logged in as carlos
in a private window, intercepted the change email request, and extracted the csrfKey
and csrf
token values. Using carlos
's csrfKey
cookie and CSRF token in wiener
's change email request worked, indicating the CSRF implementation was not tied to the user session.
Given this information, I crafted a CSRF PoC to make the victim submit the change email form using carlos
's CSRF token and csrfKey
cookie:
This PoC alone wasn't enough because the csrfKey
cookie wasn't set in the victim's browser. I needed a way to set this cookie.
While navigating through requests in Burp Suite, I found that the input passed to the search parameter at /search
was reflected in the Set-Cookie
header:
Response:
I could inject into this header to set the necessary csrfKey
cookie:
URL-encoded payload:
Combining the header injection and the CSRF form submission, I created the following final PoC:
When the victim visits this malicious HTML page, their browser attempts to fetch the image, which triggers the injection to set the csrfKey
cookie. Upon failing to load the image, the onerror
event handler submits the form, exploiting the CSRF vulnerability.
I modified the email value to avoid errors related to reused email addresses. After placing the CSRF PoC on my malicious page and delivering it to the victim, the lab was solved, confirming the successful email change.