1. CSRF Tokens
- How it works: A unique token is sent with each form/request and must match what the server expects.
- Bypass Tips:
- Token leakage: Check for tokens exposed in URLs, referrers, or logs.
- Weak token validation: Some apps accept predictable or outdated tokens.
- Replay old tokens: If tokens aren’t properly tied to user sessions or actions, reuse might work.
- Token Omission: Remove the token entirely from the request, keeping the valid session cookie.
- Token Misappropriation:
- Use another user’s token
- Use another application’s token from within the same domain
- May not work if site is using
SameSite=Strict,Lax
- Change Method: Tokens may be validated for expected methods such as
POST, yet they are not checked when using a GET request.
2. SameSite Cookies
- How it works: Cookies are restricted based on the SameSite attribute:
- Strict: No cross-site requests include cookies.
- Lax: Cookies included only on top-level navigations (e.g., links).
- None: Allows all, but must be secure (HTTPS).
- Bypass Tips:
- Upgrade HTTP to HTTPS: If the site doesn’t enforce HTTPS, you might trigger cookie inclusion.
- Use top-level redirects: Some Lax SameSite settings allow cross-site behavior under specific navigation flows.
3. Referer-Based Validation
- How it works: The server checks if the
Referer matches the expected domain.
- Bypass Tips:
- No Referer header: Leverage browsers or configurations that strip Referer headers.
- Origin header fallback: Some apps accept
Origin instead, which may be spoofable.
- Open redirects: Exploit redirect vulnerabilities on the domain to fake a valid referer.
4. Burp Suite CSRF PoC Generation
- Submit the form: Using Burp Suite Proxy and a browser, visit the page with the element you are targeting. Submit the form and capture the request.
- Generate the PoC:
- Right-click the Request: From within the HTTP history tab or Intercept tab, right-click on the body of the Request.
- Engagement Tools -> POC: From the pop-up right-click menu, select
Engagement Tools -> Generate CSRF PoC.
- Edit and Upload to HTTP Server: Upload the PoC to a locally hosted web server, or alternatively place it in the body of a comment, similar to Stored XSS.
- PoC Example:
<html>
<!-- CSRF PoC - generated by Burp Suite Professional -->
<body>
<form action="https://0a5d0027041f941081d39e26001f00e7.web-security-academy.net/my-account/change-email" method="POST">
<input type="hidden" name="email" value="foo@gmail.com" />
<input type="submit" value="Submit request" />
</form>
<script>
history.pushState('', '', '/');
document.forms[0].submit();
</script>
</body>
</html>
5. Mitigations
- Validate CSRF Tokens on All Methods:
- Always validate CSRF tokens for all state-changing operations (not just POST but also PUT, DELETE, and even GET if misused for state changes).
- For purely informational GET requests, enforce an explicit policy to never modify state.
- Disallow State-Changing Actions via GET:
- Follow REST principles strictly: use GET for data retrieval and POST/PUT/DELETE for changes.
- Implement server-side routing and HTTP method checks to block unexpected use of GET for state changes.
- Additional Security Measures:
- SameSite Cookies: Configure session cookies with
SameSite=Strict or SameSite=Lax to limit cross-origin requests.
- CSRF Mitigation Improvement:Tying the CSRF token to the session cookie would unify the security context, mitigating such issues where attackers rely on separately scoped cookies.
- Content Security Policy (CSP): Use CSP to reduce the risk of CSRF attacks via malicious scripts.
- Isolation of Staging and Production Environments: Ensure staging environments are on separate DNS domains, not subdomains, to prevent cross-environment cookie pollution.
- Prevent Re-use of CSRF keys: Scope the
csrfKey cookie to the specific domain.
- Logging and Monitoring:
- Log unusual request patterns, like GET requests for actions that typically use POST.
