CSRF
Basic usage
CSRF conditions:
Relevant action like change mail
cookie-based session handling
no unpredictable request parameters
Identify a Vulnerable Action
Find an action on the target web application that requires authentication and can be executed via a simple HTTP request (e.g., form submissions, changing user settings, transferring funds, etc.).
Common targets include:
Form submissions (changing email, password).
Sensitive actions like transferring funds or making purchases.
Any action that requires the user to be logged in.
2. Check for Lack of CSRF Protection
Confirm that the web application does not include anti-CSRF tokens in the request. Common CSRF protection mechanisms include:
CSRF tokens: Unique tokens embedded in forms or URLs that must be submitted with requests.
SameSite cookie: Cookies marked as
SameSite
prevent CSRF attacks because they are not sent with cross-origin requests.
If none of these protections are in place, the application might be vulnerable to CSRF.
3. Capture the Legitimate Request
Using a tool like Burp Suite or browser developer tools, capture the legitimate request that performs the sensitive action (e.g., submitting a form, changing user details).
Look at the method (
GET
,POST
), URL, and parameters. A common CSRF target is aPOST
request that changes user data, butGET
requests can also be vulnerable.
Example of a simple POST
request to change an email address:
4. Craft a Malicious HTML Form or Script
Create a malicious HTML page or script that automatically submits the request on behalf of the victim when they visit the page. This can be done by creating a hidden form that triggers a
POST
request or an image/link forGET
requests.
If you're using Burp Suite Professional, right-click on the request and select Engagement tools / Generate CSRF PoC. Enable the option to include an auto-submit script and click "Regenerate".
Referer Validation CSRF
Identify the change email function is vulnerable to CSRF by observing when the Referer header value is changed the response give message, Invalid referer header
Adding original domain of target and append
history.pushState('', '', '/?TARGET.net');
to the Referer header in the form of a query string, allow the change email to update.
No Referer needed
Add no-referrer meta tag inside body in POC to surpress no referer
CSRF where token is tied to non-session cookie
csrf and csrfKey is tied together but no session cookie
need to inject csrf in the form of POC -> easy
find a way to inject csrfKey to the user -> harder
Need an action with set-cookie parameters in response
CSRF duplicated
the value of the csrf
body parameter is simply being validated by comparing it with the csrf
cookie, so we can put any value to it, just put same value in the form and cookie set with search fn
Ignore CSRF Token
Just POC without csrf
Method change to bypass csrf token checks
GET /my-account/change-email?email=d%40d.d HTTP/2 Host: 0a2100d30342205281e74d70008b00fe.web-security-academy.net Cookie: session=EqmLZBceqoIkYKB1J1jdeWunTNUoP1Tf Cache-Control: max-age=0
Is Logged In
If cookie with the isloggedin name is identified, then a refresh of admin password POST request could be exploited. Change username parameter to administrator while logged in as low privilege user, CSRF where token is not tied to user session.
SameSite=Strict bypass
Cross-site WebSocket hijacking (also known as cross-origin WebSocket hijacking) involves a cross-site request forgery (CSRF) vulnerability on a WebSocket handshake. It arises when the WebSocket handshake request relies solely on HTTP cookies for session handling and does not contain any CSRF tokens or other unpredictable values.
SameSite=Lax bypass
Observe if you visit /social-login
, this automatically initiates the full OAuth flow. If you still have a logged-in session with the OAuth server, this all happens without any interaction., and in proxy history, notice that every time you complete the OAuth flow, the target site sets a new session cookie even if you were already logged in.
Last updated