CSRF with broken Referer validation

Description

This lab’s email change functionality is vulnerable to CSRF. It attempts to detect and block cross domain requests, but the detection mechanism can be bypassed.

Reproduction and proof of concept

  1. Open Burp’s browser and log in to your account. Submit the “Update email” form, and find the resulting request in your Proxy history.

  2. Send the request to Burp Repeater. Observe that if you change the domain in the Referer HTTP header, the request is rejected.

  3. Copy the original domain of your lab instance and append it to the Referer header in the form of a query string. The result should look something like this:

Referer: https://in-my-control.net?lab-id.web-security-academy.net

  1. Send the request and observe that it is now accepted. The website seems to accept any Referer header as long as it contains the expected domain somewhere in the string.

  2. Create a CSRF proof of concept exploit as described in the solution to the CSRF vulnerability with no defenses lab (above) and host it on the exploit server. Edit the JavaScript so that the third argument of the history.pushState() function includes a query string with your lab instance URL as follows:

history.pushState("", "", "/?0a560045032453f8c49be2be00a800b0.web-security-academy.net")

This will cause the Referer header in the generated request to contain the URL of the target site in the query string, just like we tested earlier.

  1. If you store the exploit and test it by clicking “View exploit”, you may encounter the “invalid Referer header” error again. This is because many browsers now strip the query string from the Referer header by default as a security measure. To override this behaviour and ensure that the full URL is included in the request, go back to the exploit server and add the following header to the “Head” section:

Referrer-Policy: unsafe-url

Note that unlike the normal Referer header, the word “referrer” must be spelled correctly in this case.

CSRF

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

Exploitability

An attacker needs to have an account and use an exploit server to host an HTML page that uses a CSRF attack to change the viewer’s email address.