====== CSRF Testing ====== ===== Testing CSRF On Application ===== * CSRF Normal * Change Method To GET-Based * Change Value Of CSRF-Token To undefined * Delete CSRF Token Value Or Delete Token Parameter * Use The same CSRF Value In Different Accounts * Replace Value CSRF Token with Same Length Characters * Change Content-Type from application/json to text/plain * Use Vulnerable-Subdomain To Bypass CSRF Token ===== Zseano's 8-Step CSRF Test ===== - Standard CSRF test -- remove token entirely - Change method to GET - Change CSRF token value to ''undefined'' - Delete token value or entire parameter - Use same CSRF token across two different accounts - Replace token with same-length random string - Change content-type from ''application/json'' to ''text/plain'' - Use a vulnerable subdomain to bypass CSRF token validation **Blank referer bypass:** '''' **iframe data URI bypass:** '' Any victim who visits this page will have the action executed automatically. ===== Prevention ===== ==== CSRF Tokens ==== The server generates a random unpredictable token and embeds it in every form:

The server validates the token on every state-changing request. The token must be unique per session (or per form) and have sufficient entropy to prevent guessing. Frameworks often have CSRF token support built in. ==== SameSite Cookies ====


Set-Cookie: PHPSESSID=UEhQUOVTUOlE; Max-Age=86400; Secure; HttpOnly; SameSite=Strict
Set-Cookie: PHPSESSID=UEhQUOVTUOlE; Max-Age=86400; Secure; HttpOnly; SameSite=Lax

* ''SameSite=Strict'' -- cookies never sent on cross-site requests * ''SameSite=Lax'' -- cookies sent only on top-level navigation GET requests (not on cross-site POST or iframe requests) Chrome made ''SameSite=Lax'' the default in 2020 for cookies that don't specify the attribute. This reduces POST CSRF exposure significantly, but CSRF remains possible when: * State-changing actions are performed via GET requests * The site explicitly sets ''SameSite=None'' on session cookies * The victim uses Firefox, IE, or Safari (which do not default to Lax) ===== Hunting for CSRFs ===== Test with Firefox (not Chrome) when testing POST CSRF, since Chrome's Lax default will prevent cookie sending on cross-site POST. ==== Step 1: Spot State-Changing Actions ==== Browse the application and record every endpoint that alters user data. For each, note: * URL and HTTP method * Request parameters Example inventory for ''email.example.com'': * Change password: ''email.example.com/password_change'' (POST, param: ''new_password'') * Send email: ''email.example.com/send_email'' (POST, params: ''draft_id'', ''recipient_id'') * Delete email: ''email.example.com/delete_email'' (POST, param: ''email_id'') ==== Step 2: Look for CSRF Protections ==== Intercept each state-changing request in Burp. Search the request for the string "csrf" or "state". CSRF tokens can appear as: * POST body parameters * HTTP request headers (''X-CSRF-Token'') * Cookie values * URL parameters Even if a token is present, test bypass techniques -- many implementations are flawed. ==== Step 3: Confirm the Vulnerability ==== Craft a malicious HTML page and open it in a browser signed into the target site. Check whether the action was executed:

For GET-based state-changing actions, an img tag is enough:

===== Bypassing CSRF Protection ===== ==== Exploit Clickjacking ==== If the endpoint has a CSRF token but the page is frameable (see Ch8), use clickjacking to trick the user into clicking the submit button on the framed page. The browser sends the legitimate CSRF token because it originates from the real page. ==== Change the Request Method ==== Try switching POST to GET. Some endpoints accept both but only validate CSRF tokens on POST:


GET /password_change?new_password=abc123
Host: email.example.com
Cookie: session_cookie=YOUR_SESSION_COOKIE

Trigger with an img tag -- the browser sends a GET request when loading the image source. ==== Bypass Token Validation -- Delete or Blank the Token ==== Some applications only validate the token if the parameter is present and non-empty. If the token is missing or blank, they skip validation: Delete the parameter entirely:


POST /password_change
(POST body)
new_password=abc123

Send a blank token:


POST /password_change
(POST body)
new_password=abc123&csrf_token=

==== Bypass Token Validation -- Use Another Session's Token ==== Some apps verify only that the token is a valid token, not that it belongs to the current session. Obtain a valid token from your own session and substitute it in the forged request targeting another user:


POST /password_change
(POST body)
new_password=abc123&csrf_token=YOUR_OWN_TOKEN

==== Bypass Double-Submit Cookies ==== Some sites use a double-submit cookie: the ''csrf_token'' cookie value must match the ''csrf_token'' POST parameter. The server doesn't store the valid token -- it just checks that both values match. If you can plant a cookie in the victim's browser (via session fixation or a subdomain XSS), set the ''csrf_token'' cookie to any value you control and use the same value in the POST parameter:


POST /password_change
Cookie: session_cookie=YOUR_SESSION_COOKIE; csrf_token=not_a_real_token
(POST body)
new_password=abc123&csrf_token=not_a_real_token

==== Bypass Referer Check -- Remove the Referer ==== If the site validates the Referer header instead of CSRF tokens, add a meta tag to your attack page to suppress the Referer:

If the app only validates the Referer when it is present, a missing Referer bypasses the check entirely. ==== Bypass Referer Check -- Flawed Logic ==== If the app checks that the Referer **contains** the victim domain name:


Referer: example.com.attacker.com     (subdomain named "example.com")
Referer: attacker.com/example.com     (path named "example.com")

==== Bypass via XSS ==== Any XSS on the target site defeats CSRF protection. XSS can read the CSRF token from the DOM via ''XMLHttpRequest'' and embed it in a forged request -- no token bypass needed. ===== Escalating the Attack ===== ==== Leak User Information ==== CSRF on a billing email change endpoint lets the attacker redirect account summaries (containing address, phone number, credit card info) to their own inbox:


POST /change_billing_email
(POST body)
email=ATTACKER_EMAIL&csrf_token=

Once the billing email is changed, trigger "send account summary" to receive the victim's PII. ==== Create Stored Self-XSS via CSRF ==== Self-XSS (only the user themselves can trigger it) becomes exploitable when combined with CSRF. If an account nickname field is vulnerable to self-XSS but the nickname endpoint lacks CSRF protection, an attacker can use CSRF to store an XSS payload in the victim's nickname. The next time the victim views their own dashboard, the XSS fires.


POST /change_account_nickname
(POST body)
account=0
&nickname=

(No csrf_token parameter -- token validation skipped when parameter is absent.) ==== Account Takeover ==== CSRF on a set-password endpoint for accounts created via social login (no existing password) allows the attacker to assign a password to any such account:

Post the link to this page on a forum frequented by the target site's users. Any social-login account that visits the link gets a new password set. ===== Delivering the Payload ===== * **External site link**: post a link to your malicious page on any forum or feed the target site's users visit * **GET CSRF via img**: embed the request as an img src in a forum post -- fires on page load with no click * **Via stored XSS**: inject the CSRF payload into a comment/forum field visible to victims:


document.body.innerHTML += '
  
    
    
  ';
document.getElementById("csrf-form").submit();

Burp Suite Pro and OWASP ZAP both have automatic CSRF POC generation features. ===== 6-Step Checklist ===== - Spot state-changing actions and list their endpoints, HTTP methods, and parameters. - Check each for CSRF protection (search request for "csrf" or "state"). - If protection is present, try bypass techniques (clickjacking, method switch, blank/deleted token, another session's token, referer removal). - Confirm by crafting a malicious HTML page and opening it in a browser signed into the target. - Plan payload delivery: external link, img embed, or via stored XSS. - Draft the report with a working PoC.