Cross site request forgery (CSRF)

Cross-site request forgery, also known as one-click attack or session riding and abbreviated as CSRF or XSRF, is a type of malicious exploit of a website where unauthorized commands are submitted from a user that the web application trusts.

-- Wikipedia

• PortSwigger - Web Security Academy - Cross-site request forgery (CSRF)

Conditions

Following three conditions must apply to a CSRF attack to be possible:

• A relevant action (changing email, password, etc.)

• Cookie-based session handling (app relies solely on session cookies to identify the user)

• No upredictable request parameters (CSRF-token, password, etc.)

Burp Suite

Right click (on request) -> Engagement tools -> Generate CSRF PoC

Vulnerabilities

Request method

CSRF token validation depends on request method. -> Try a different method, like GET instead of POST

Token only validated when present

CSRF token is only validated when present. -> Try to completely remove the token parameter

Token not tied to session

CSRF token is not tied to user session. -> Just load the form yourself and use that very token for the attack

Token tied to a non-session cookie

CSRF token is tied to a non-session cookie (needs a way to set a cookie).

E.g. When search term is written via Set-Cookie:

<img src="https://website.com/?search=test%0d%0aSet-Cookie%3a+csrf%3dKyaV39N2JCOjQM7HSx2P7CQLJBLjIcny" onerror="document.forms[0].submit()">

Referer only validated when present

Remove referer via:

<meta name="referrer" content="never">

Referer validation "contains"

Referer validation can be circumvented (e.g. when the app only checks if the referer header "contains" the own url).

Fake referer:

history.pushState('', '', '/?<expected-referer-url>')

To avoid stripping the query string in referer header, use this HTTP header:

Referrer-Policy: unsafe-url