notes
web security vulnerability that allows an attacker to induce users to perform actions that they do not intend to perform.
allows an attacker to partly circumvent the same origin policy, which is designed to prevent different websites from interfering with each other
Impact
the attacker causes the victim user to carry out an action unintentionally
eg - change email address, change password, make a funds transfer
How does it work?
Relevant action - eg - privileged action (such as modifying permissions for other users) or any action on user-specific data (such as changing the user's own password)
Cookie-based session handling(session cookies) - performing the action involves issuing one or more HTTP requests and the application relies solely on session cookies to identify the user who has made the requests.
No unpredictable request parameters - requests that perform the action do not contain any parameters whose values the attacker cannot determine or guess.
eg - an application contains a function that lets the user change the email address. When the user performs this action, they make an HTTP request like:
This meets the conditions required for CSRF
action of changing email address
session cookie to identify which user issued the request
values of request parameters can be easily determined
Then the attacker can construct a web page containing the following HTML
when the victim user visits the attacker's web page,
the attacker's page will trigger an HTTP request to the vulnerable web site
if the user is logged in to the vulnerable web site, their browser will automatically include their session cookie in the request (assuming SameSite cookies are not being used)
the vulnerable web site will process the request in the normal way, treat it as having been made by the victim user and change their email address to attacker's email
How to construct CSRF attack
select a request anywhere in Burp that you want to test or exploit
Right-click > Select Engagement tools > Generate CSRF PoC
will generate some HTML that will trigger the selected request (without cookies, that will be added automatically by the victim's browser)
copy the generated HTML into a web page, view it in the browser that is logged in to the vulnerable web site and test whether the intended request is issued successfully and the desired action occurs
How to deliver CSRF exploit
delivery mechanisms is same as that of reflected XSS
attacher will place the malicious HTML onto a web site that they control and induce victims to visit that web-site by feedin the user a link to the web site via the email or social media message
some simple CSRF exploits employ the GET method and can be fully self-contained with a single URL on the vulnerable web site and can directly feed victims a malicious URL on the vulnerable domain eg -
<img src="https://vuln-website.com/email/change?email=attacker@email.com">
XSS Vs CSRF
XSS - allows an attacker to execute arbitary JS within the browser of the victim user
CSRF - allows an attacker to induce a victim user to perform actions that they do not intend to
CSRF - only applies to a subset of actions that the user is able to perform, and those that are overlooked CSRF defenses
XSS can normally induce a user to perform any action that the user is able to perform
Defend
CSRF Token
most robust way to defend against CSRF attacks is to include a CSRF token within relevant requests and the token should be
unpredictable with high entropy as for the session tokens in general
tied to the user's session
strictly validated in every case before the relevant action is executed
SameSite cookies
SameSiteattribute can be used to control whether and how cookies are submitted in cross-site requeststwo values :
StrictorLaxeg
Set-Cookie: SessionId=some-random-string; SameSite=Strictif strict, the browser will not include the cookie in any requests that originate from another site
if lax, the browser will include the cookie in requests that originate from another site but only if two conditions are met
the reqest uses the GET method (with other methods like POST will not include the cookie)
the request resulted from a top-level navigation by the user, such as clicking a link
Common CSRF vulnerabilities
CSRF validation only occurs at certain method eg - CSRF token validation takes place only in POST method and not in GET method
Validation of CSRF token depends on token being present - some applications correctly validate the token only when it is present but skip the validation if the token is omitted. (try to remove the token)
CSRF token is not tied to the user session - some applications do not validate that the token belongs to the same session as the user who is making the request. (application maintains a global pool of tokens that it has issued and accepts any token that appears in this pool)
CSRF token tied to a non-session cookie eg -
harder to exploit
if web site contains any behavior that allows an attacker to set a cookie in a victim's browser, then an attack is possible
CSRF token - simply duplicated in a cookie
some applications do not maintain any server-side record of tokens that have been issued, but instead duplicate each token within a cookie and a request parameter
Referer-based defences
some applications make use of the HTTP Referer header to attempt to defend against CSRF attacks
when it is present in requests, validate the token and if the header is omitted, skip the validation
easiest way to do is adding META tag with no referer
Testing CSRF Tokens
Remove the CSRF token and see if the application accepts the request
Change request method - eg - from POST to GET method
Swap the CSRF token with other account and test it
Testing CSRF Tokens and CSRF cookies
Check if the CSRF token is tied to the CSRF cookie
Submit an invalid CSRF token
Submit a valid CSRF token from another user
Submit valid CSRF token and cookie from another user
Last updated