Cross site request forgery (CSRF) Token
What is CSRF?
This allows an attacker to perform actions that the victim does not intend to perform.
This allows an attacker to circumvent the same-origin policy
Impact of a CSRF attack
The attacker causes the victim user to carry out an action unintentionally:
Changing the email address on their account
Changing their password
Making a fund transfer
How CSRF works
Three conditions must be in place:
A relevant action to induce:
A privileged action such as modifying permissions for users
User-specific data such as changing the user's own password
Cookie-based session handling:
Performing the action involves issuing one or more HTTP requests
The application relies solely on session cookies to identify the user who made the request
No other mechanism is in place for tracking sessions or validating user requests
Predictable request parameters:
Easy to guess or determine parameters
Easy to guess or determine values
Example of a request that meets all the conditions:
Example attacker HTML that auto-submits the change request when the victim visits the page:
Construct a CSRF attack
Burp Suite Professional: use Engagement tools → Generate CSRF PoC
Select a request in Burp
Right-click → Engagement tools → Generate CSRF PoC
Burp generates HTML that triggers the selected request (cookies are not included; the victim's browser will add them)
Tweak options if needed, copy the HTML into a web page, view in a browser logged in to the vulnerable site to test
Labs and exploit patterns
Lab: CSRF vulnerability with no defenses
Introduction
Web_Pentest: Pen-tester infiltrates a website with a CSRF vulnerability where the "Update Email" functionality lacks defenses. CSRF allows an attacker to trick a user into performing actions they didn't intend, like changing their email address by embedding a malicious request within a page the victim visits.
Vulnerability - Problem
Source:
No CSRF Protection: The server does not require any unique token or verification that would stop requests from external sites.
Sink:
Automatic Form Submission: The auto-submit script sends the request instantly without user interaction.
Challenge:
Trick the victim into visiting the malicious link.
Attack (Manual / Community Edition)
Craft a simple HTML template:
Replace YOUR_LAB_ID in the URL for the lab environment.
Use method="POST", action pointing to the vulnerable URL.
Include a hidden input for the new email.
Auto-submit via script: document.forms[0].submit();
Inject the payload:
Go to the exploit server in the lab, paste the HTML into the body, click Store.
Test:
Click View exploit to test.
Check account information to confirm email change.
Modify the email in the form to ensure it doesn't match your own email before final delivery.
Why the exploit works
The application accepts cross-origin requests that contain the victim's session cookie and there is no token or validation to prevent such requests.
Automatic submission causes the victim's browser to issue the authenticated request without user intent.
Real-world impact: account takeover, loss of privacy, financial or reputational damage.
HTML template:
Lab: CSRF where token validation depends on request method
Reconnaissance Plan
Initial Test:
Login using Burp's browser, go to Update Email and submit a new email.
Inspect:
Capture the request in Proxy and send to Repeater.
Modify the CSRF parameter → request rejected (CSRF required for POST).
Change the method to GET, remove CSRF parameter → request still works → defense only applied to POST.
Attack
Craft exploit:
Use an HTML template that causes a GET request (or otherwise avoids CSRF-protected method).
Replace YOUR-LAB-ID with the lab URL and set email to attacker-controlled value.
Inject & Test:
Paste to Exploit Server Body, Store.
View exploit to test and confirm the email changed.
Deliver:
Modify the payload to a different email, Store, Deliver to victim.
Why the exploit works
CSRF Token Bypass: The server only enforces tokens for POST requests and ignores GET requests for sensitive actions.
Automatic submission causes the victim browser to issue the request that lacks the required CSRF token for POST.
Recommendation: Validate CSRF tokens for all state-changing methods; do not use GET for state-changing actions.
Example exploit:
Lab: CSRF where token validation depends on token being present
Reconnaissance Plan
Initial Test:
Login (example credentials: wiener:peter), go to Update Email and change it.
Inspect:
Capture the request and send to Repeater.
Modify CSRF parameter → request rejected.
Remove CSRF parameter entirely → request succeeds → server does not enforce CSRF protection when the token is absent.
Why the exploit works
The server incorrectly treats missing CSRF tokens as acceptable while rejecting incorrect tokens. Attackers can omit the token entirely to bypass the check.
Prevention: Always validate CSRF tokens; avoid using GET for state changes.
Exploit example:
Lab: CSRF where token is not tied to user session
Payload:
Why the exploit works — Key takeaways
CSRF tokens must be tied to user sessions so tokens generated by one user cannot be used by another.
Single-use tokens should be enforced and validated against the logged-in user.
Real-world impact: account takeover via email change, interception of notifications, password resets.
Lab: CSRF where token is tied to non-session cookie
2024-12-01
Vulnerability - Problem
Source:
CSRF defense uses a csrfkey cookie and a matching CSRF token.
csrfkey is not strictly tied to the user session and can be injected into the victim's browser.
Sink:
Cookie injection via a search endpoint that reflects Set-Cookie headers.
Challenge:
Abuse the search functionality to inject your csrfKey into the victim's browser.
Reconnaissance Plan
Initial Test:
Log in as Wiener, submit an email change to capture request.
Inspect:
Intercept the email change request; note csrfkey cookie and CSRF token in request body.
In Repeater, modify csrfkey cookie to a random value → token rejected; modify session cookie → logged out. This shows csrfkey is independent of session.
Attack
Swap CSRF Token Between Accounts:
Log in as Carlos, capture his email-change request.
Replace Carlos's csrfkey and token with Wiener's → if accepted, csrfkey is reusable.
Inject the Cookie:
Abuse the search function to reflect a Set-Cookie header:
Example payload: test%0d%0aSet-Cookie:%20csrfKey=YOUR-KEY%3b%20SameSite=None
Send the request and check that csrfkey is injected into the victim's browser.
Create the CSRF exploit:
Craft HTML with matching csrf token and an image tag to inject the cookie then submit the form.
Host on Exploit Server, Store, View to test, then Deliver to victim.
Payload:
Why the exploit works — Key lessons
CSRF tokens must be tied to user sessions and validated against the session.
Avoid relying on independent cookies for CSRF defense.
Prevent cookie injection by validating inputs and not reflecting Set-Cookie headers from user-controlled data.
Validate Origin/Referer as defense-in-depth.
Real-world impact: account takeover, interception of notifications, sensitive data exposure.
Lab: CSRF where token is duplicated in cookie
2024-12-17
Vulnerability - Problem
Source:
The server verifies that the token in the request body matches the token in a csrf cookie.
It does not validate where the cookie originated.
Sink:
Inject a fake csrf cookie into the victim's browser and craft a request using that fake token.
Challenge:
Inject the fake token via a reflected Set-Cookie behavior and then submit a matching body token.
Attack
Inject fake csrf cookie via search endpoint:
Modify search term to include: test%0d%0aSet-Cookie:%20csrf=fake%3b%20SameSite=None
Send request; this reflects a Set-Cookie header and injects the fake csrf cookie into the victim's browser.
Craft an exploit HTML that uses csrf=fake in the body and submits the request.
Host on Exploit Server, Store, View to test, then Deliver to victim.
Payload:
Why the exploit works
The tag triggers the search endpoint with a payload that reflects a Set-Cookie header, injecting csrf=fake into the victim's cookies.
The form uses csrf=fake in the request body; because the server only checks that cookie and body values match, it accepts the request.
The image ensures cookie injection occurs before the form submission.
Real-world analogy: a bank using double-submit CSRF but not verifying cookie provenance could be tricked into accepting attacker-supplied tokens, enabling account takeover.
Key preventative measures (summary)
Always tie CSRF tokens to user sessions and validate them against the logged-in user.
Ensure CSRF tokens are unique and single-use where possible.
Validate CSRF tokens for all state-changing request methods (not just POST).
Never use GET for state-changing operations.
Do not reflect Set-Cookie headers from user-controlled input; validate inputs to prevent cookie injection.
Use defense-in-depth: Origin/Referer checks, SameSite cookies, and additional server-side verification.
Additional resources
Use Burp Suite Engagement tools → Generate CSRF PoC for quick PoC generation.
Test exploits on an exploit server instance in controlled lab environments before real-world testing.