{"id":4751,"date":"2026-08-11T20:58:54","date_gmt":"2026-08-11T18:58:54","guid":{"rendered":"https:\/\/www.sycope.com\/?post_type=dictionary-item&#038;p=4751"},"modified":"2026-08-12T19:01:04","modified_gmt":"2026-08-12T17:01:04","slug":"cross-site-request-forgery-csrf","status":"publish","type":"dictionary-item","link":"https:\/\/www.sycope.com\/pl\/post\/dictionary-item\/cross-site-request-forgery-csrf","title":{"rendered":"Cross-Site Request Forgery (CSRF)"},"content":{"rendered":"<p><strong>Cross-Site Request Forgery (CSRF)<\/strong> \u2014 po polsku \u201efa\u0142szowanie \u017c\u0105da\u0144 mi\u0119dzy witrynami&#8221;, znane te\u017c jako XSRF lub <em>session riding<\/em> \u2014 to podatno\u015b\u0107 aplikacji internetowych. Pozwala napastnikowi sprawi\u0107, \u017ce zalogowany u\u017cytkownik nie\u015bwiadomie wykona jak\u0105\u015b operacj\u0119: zmieni has\u0142o, zrobi przelew, nada komu\u015b uprawnienia. Sztuczka opiera si\u0119 na tym, \u017ce przegl\u0105darka do ka\u017cdego \u017c\u0105dania automatycznie dok\u0142ada ciasteczko sesyjne ofiary. Serwer widzi wa\u017cn\u0105 sesj\u0119 i wykonuje polecenie, bo ufa zalogowanemu u\u017cytkownikowi \u2014 nie sprawdza, czy \u017c\u0105danie naprawd\u0119 wysz\u0142o z jego w\u0142asnej strony.<\/p>\n<h2>Kiedy atak CSRF jest w og\u00f3le mo\u017cliwy?<\/h2>\n<p>Wed\u0142ug klasyfikacji firmy PortSwigger musz\u0105 zaistnie\u0107 jednocze\u015bnie trzy warunki:<\/p>\n<ul>\n<li><strong>Jest wa\u017cna akcja do wykonania.<\/strong> W aplikacji istnieje operacja, na kt\u00f3rej napastnikowi zale\u017cy \u2014 zmiana e-maila, zmiana has\u0142a, przelew, nadanie uprawnie\u0144.<\/li>\n<li><strong>Sesja opiera si\u0119 tylko na ciasteczku.<\/strong> Aplikacja rozpoznaje u\u017cytkownika wy\u0142\u0105cznie po ciasteczku sesyjnym, kt\u00f3re przegl\u0105darka wysy\u0142a sama. W \u017c\u0105daniu nie ma \u017cadnego dodatkowego, trudnego do zgadni\u0119cia sekretu.<\/li>\n<li><strong>Wszystkie parametry \u017c\u0105dania da si\u0119 przewidzie\u0107.<\/strong> Napastnik zna lub potrafi odgadn\u0105\u0107 ka\u017cd\u0105 potrzebn\u0105 warto\u015b\u0107. W \u017c\u0105daniu nie ma nic nieprzewidywalnego, np. tokenu CSRF ani bie\u017c\u0105cego has\u0142a.<\/li>\n<\/ul>\n<h2>Jak dzia\u0142a atak CSRF?<\/h2>\n<p>Serwer ufa zalogowanej sesji ofiary \u2014 a w\u0142a\u015bciwie jej przegl\u0105darce. CSRF nadu\u017cywa tego zaufania. Typowy przebieg wygl\u0105da tak:<\/p>\n<ol>\n<li>Ofiara jest zalogowana w jakiej\u015b aplikacji i ma w przegl\u0105darce wa\u017cne ciasteczko sesyjne.<\/li>\n<li>Napastnik przygotowuje stron\u0119 z ukrytym \u017c\u0105daniem do tej aplikacji \u2014 na przyk\u0142ad formularz, kt\u00f3ry sam si\u0119 wysy\u0142a przez JavaScript, albo znacznik <code>&lt;img&gt;<\/code> wskazuj\u0105cy na podatny adres.<\/li>\n<li>Ofiara \u2014 wci\u0105\u017c zalogowana \u2014 wchodzi na t\u0119 stron\u0119. Trafia tam z linku w e-mailu, posta na forum albo reklamy.<\/li>\n<li>Przegl\u0105darka wysy\u0142a \u017c\u0105danie do aplikacji i \u2014 jak zwykle \u2014 sama dok\u0142ada ciasteczko sesyjne ofiary.<\/li>\n<li>Serwer widzi prawid\u0142ow\u0105 sesj\u0119 i wykonuje operacj\u0119, jakby zleci\u0142 j\u0105 \u015bwiadomie sam u\u017cytkownik.<\/li>\n<\/ol>\n<p>Wa\u017cny szczeg\u00f3\u0142: napastnik <strong>nie widzi odpowiedzi<\/strong> serwera \u2014 blokuje to regu\u0142a <em>same-origin policy<\/em> (zasada tego samego \u017ar\u00f3d\u0142a). CSRF s\u0142u\u017cy wi\u0119c do wywo\u0142ania akcji, a nie do podejrzenia danych. Atak dzia\u0142a \u201ena \u015blepo&#8221; i tym r\u00f3\u017cni si\u0119 od kradzie\u017cy informacji.<\/p>\n<h2>CSRF przez GET czy POST?<\/h2>\n<p>Spos\u00f3b podrzucenia \u017c\u0105dania zale\u017cy od tego, jak\u0105 metod\u0119 przyjmuje podatny adres:<\/p>\n<ul>\n<li><strong>GET<\/strong> \u2014 naj\u0142atwiejszy do wykorzystania. Wystarczy znacznik <code>&lt;img src=\"https:\/\/bank.example\/transfer?to=attacker&amp;amount=1000\"&gt;<\/code>. Przegl\u0105darka pr\u00f3buje pobra\u0107 \u201eobrazek&#8221; i przy okazji wysy\u0142a \u017c\u0105danie razem z ciasteczkami. Operacje zmieniaj\u0105ce dane nigdy nie powinny by\u0107 dost\u0119pne przez GET.<\/li>\n<li><strong>POST<\/strong> \u2014 wymaga automatycznego wys\u0142ania ukrytego formularza, zwykle JavaScriptem. Samo POST <strong>nie chroni<\/strong> przed CSRF \u2014 to cz\u0119sty mit.<\/li>\n<\/ul>\n<p>Osobnym wariantem jest <strong>Login CSRF<\/strong>. Tu napastnik wymusza zalogowanie ofiary na <em>swoje<\/em> konto, \u017ceby p\u00f3\u017aniej podejrze\u0107 to, co ofiara tam wpisze \u2014 np. histori\u0119 czy zapisan\u0105 kart\u0119.<\/p>\n<h2>Czym grozi udany atak CSRF?<\/h2>\n<ul>\n<li>Zmian\u0105 e-maila lub has\u0142a, a w efekcie przej\u0119ciem konta.<\/li>\n<li>Nieautoryzowanym przelewem lub inn\u0105 transakcj\u0105.<\/li>\n<li>Zmian\u0105 uprawnie\u0144, usuni\u0119ciem konta, zmian\u0105 ustawie\u0144 bezpiecze\u0144stwa.<\/li>\n<li>Przej\u0119ciem kontroli nad ca\u0142\u0105 aplikacj\u0105, gdy ofiar\u0105 jest administrator \u2014 jedno \u017c\u0105danie potrafi zmieni\u0107 jej konfiguracj\u0119.<\/li>\n<\/ul>\n<h2>Czym CSRF r\u00f3\u017cni si\u0119 od XSS?<\/h2>\n<p>To dwie r\u00f3\u017cne podatno\u015bci, kt\u00f3re \u0142atwo pomyli\u0107:<\/p>\n<ul>\n<li><strong>XSS (<a href=\"https:\/\/www.sycope.com\/pl\/post\/dictionary-item\/xss-cross-site-scripting\">Cross-Site Scripting<\/a>)<\/strong> wstrzykuje i uruchamia obcy skrypt na zaufanej stronie. Daje napastnikowi kontrol\u0119 nad zachowaniem strony i pozwala <em>czyta\u0107<\/em> dane \u2014 w tym tokeny CSRF.<\/li>\n<li><strong>CSRF<\/strong> nie uruchamia \u017cadnego kodu i nie czyta odpowiedzi. Tylko wymusza wys\u0142anie sfa\u0142szowanego \u017c\u0105dania w ju\u017c istniej\u0105cej sesji.<\/li>\n<\/ul>\n<p>Ta r\u00f3\u017cnica jest wa\u017cna dla obrony: <strong>XSS pokonuje ka\u017cde zabezpieczenie anty-CSRF<\/strong>. Skrypt dzia\u0142aj\u0105cy po stronie ofiary mo\u017ce odczyta\u0107 token i wys\u0142a\u0107 prawid\u0142owe \u017c\u0105danie. Dlatego usuni\u0119cie podatno\u015bci XSS jest warunkiem, \u017ceby ochrona przed CSRF w og\u00f3le mia\u0142a sens.<\/p>\n<h2>Jak zapobiega\u0107 atakom CSRF?<\/h2>\n<p>Podstawowa zasada: ka\u017cde \u017c\u0105danie zmieniaj\u0105ce dane trzeba powi\u0105za\u0107 z sekretem, kt\u00f3rego strona napastnika nie zna i nie potrafi do\u0142\u0105czy\u0107. Poni\u017csze metody opisuje OWASP w dokumencie CSRF Prevention Cheat Sheet.<\/p>\n<h3>Token CSRF (Synchronizer Token Pattern)<\/h3>\n<p>Najcz\u0119stsza metoda dla aplikacji, kt\u00f3re trzymaj\u0105 stan sesji po swojej stronie. Serwer losuje unikalny, kryptograficznie silny token (dla ca\u0142ej sesji albo dla pojedynczego \u017c\u0105dania), zapisuje go u siebie i umieszcza w ukrytym polu formularza lub w nag\u0142\u00f3wku. Token <strong>nie jest<\/strong> zwyk\u0142ym ciasteczkiem, a serwer odrzuca \u017c\u0105dania bez poprawnej warto\u015bci. Strona napastnika nie odczyta tego tokenu \u2014 zn\u00f3w blokuje to same-origin policy \u2014 wi\u0119c nie zbuduje prawid\u0142owego \u017c\u0105dania.<\/p>\n<h3>Double Submit Cookie (dla aplikacji bez stanu)<\/h3>\n<ul>\n<li><strong>Wariant prosty<\/strong> \u2014 ta sama losowa warto\u015b\u0107 trafia jednocze\u015bnie do ciasteczka i do parametru \u017c\u0105dania, a serwer por\u00f3wnuje obie. Napastnik nie odczyta cudzego ciasteczka, wi\u0119c nie powt\u00f3rzy go w parametrze.<\/li>\n<li><strong>Wariant podpisany (HMAC) \u2014 zalecany<\/strong> \u2014 token jest kryptograficznie zwi\u0105zany z sesj\u0105. Chroni to przed podrzuceniem ciasteczka z subdomeny lub innego, s\u0142abiej odizolowanego miejsca.<\/li>\n<\/ul>\n<h3>W\u0142asne nag\u0142\u00f3wki \u017c\u0105da\u0144<\/h3>\n<p>Dobre dla interfejs\u00f3w programistycznych (<a href=\"https:\/\/www.sycope.com\/pl\/post\/dictionary-item\/api\">API<\/a>) oraz \u017c\u0105da\u0144 AJAX\/XHR wysy\u0142anych w tle. Klient dok\u0142ada w\u0142asny nag\u0142\u00f3wek, np. <code>X-CSRF-Token<\/code> albo <code>X-Requested-With<\/code>. Dodanie takiego nag\u0142\u00f3wka mi\u0119dzy witrynami wymusza dodatkowe zapytanie sprawdzaj\u0105ce (preflight CORS), kt\u00f3rego prosta strona napastnika nie przejdzie. Nie trzeba przy tym przechowywa\u0107 tokenu po stronie serwera.<\/p>\n<h3>Ciasteczka SameSite<\/h3>\n<p>Atrybut <code>SameSite<\/code> decyduje, czy ciasteczko do\u0142\u0105cza si\u0119 do \u017c\u0105da\u0144 pochodz\u0105cych z innej witryny:<\/p>\n<ul>\n<li><code>Strict<\/code> \u2014 ciasteczko nie jest wysy\u0142ane przy \u017cadnym \u017c\u0105daniu z innej witryny.<\/li>\n<li><code>Lax<\/code> \u2014 domy\u015blny w nowoczesnych przegl\u0105darkach (w Chrome od 2021). Ciasteczko leci tylko przy zwyk\u0142ym wej\u015bciu na stron\u0119 bezpieczn\u0105 metod\u0105 (GET).<\/li>\n<li><code>None<\/code> \u2014 ciasteczko wysy\u0142ane zawsze, ale wymaga atrybutu <code>Secure<\/code>.<\/li>\n<\/ul>\n<p>SameSite to warstwa dodatkowa (<strong>defense-in-depth<\/strong>), a nie samodzielne rozwi\u0105zanie. Nie ochroni przed zmianami przez GET ani przed atakiem z tej samej witryny, np. z subdomeny. Trzeba j\u0105 \u0142\u0105czy\u0107 z tokenem CSRF.<\/p>\n<h3>Sprawdzanie nag\u0142\u00f3wk\u00f3w Origin \/ Referer i Fetch Metadata<\/h3>\n<p>Serwer mo\u017ce por\u00f3wnywa\u0107 nag\u0142\u00f3wki <code>Origin<\/code> i <code>Referer<\/code> z w\u0142asnym adresem albo sprawdza\u0107 <code>Sec-Fetch-Site<\/code> i dla operacji zmieniaj\u0105cych dane odrzuca\u0107 warto\u015b\u0107 <code>cross-site<\/code>. Te nag\u0142\u00f3wki bywaj\u0105 jednak pomijane \u2014 przy przekierowaniach lub niekt\u00f3rych ustawieniach prywatno\u015bci \u2014 wi\u0119c traktuje si\u0119 je jako kontrol\u0119 uzupe\u0142niaj\u0105c\u0105, nie podstawow\u0105.<\/p>\n<h2>Dlaczego CSRF jest wa\u017cny dla monitorowania i wykrywania?<\/h2>\n<p>CSRF to atak na warstw\u0119 aplikacji, uruchamiany z przegl\u0105darki ofiary. Samo \u017c\u0105danie wygl\u0105da jak zwyk\u0142y ruch zalogowanego u\u017cytkownika \u2014 nie ma w nim sygnatury exploita ani widocznej anomalii na poziomie pakiet\u00f3w. Z perspektywy zespo\u0142u bezpiecze\u0144stwa (<a href=\"https:\/\/www.sycope.com\/pl\/post\/dictionary-item\/soc-security-operations-center\">SOC<\/a>) licz\u0105 si\u0119 wi\u0119c sygna\u0142y po\u015brednie i powi\u0105zania mi\u0119dzy zdarzeniami:<\/p>\n<ul>\n<li>Operacje zmieniaj\u0105ce dane (zmiana e-maila, has\u0142a, przelew), w kt\u00f3rych nag\u0142\u00f3wek <code>Referer<\/code>\/<code>Origin<\/code> wskazuje obc\u0105 witryn\u0119 albo brakuje oczekiwanego tokenu.<\/li>\n<li>Nietypowe sekwencje \u017c\u0105da\u0144 \u2014 wra\u017cliwa akcja bez wcze\u015bniejszego pobrania formularza, kt\u00f3ry normalnie dostarcza token.<\/li>\n<li>Nag\u0142y wzrost ruchu na konkretne adresy zmieniaj\u0105ce dane, zbie\u017cny z wizytami na zewn\u0119trznych domenach (dane z proxy, log\u00f3w <a href=\"https:\/\/www.sycope.com\/pl\/post\/dictionary-item\/waf-web-application-firewall\">WAF<\/a> i serwera aplikacji, telemetrii <a href=\"https:\/\/www.sycope.com\/pl\/post\/dictionary-item\/netflow\">NetFlow<\/a>\/<a href=\"https:\/\/www.sycope.com\/pl\/post\/dictionary-item\/ipfix\">IPFIX<\/a>).<\/li>\n<li>Dzia\u0142ania niesp\u00f3jne w czasie lub geograficznie w obr\u0119bie jednej sesji.<\/li>\n<\/ul>\n<p>Logi serwera aplikacji, logi WAF i telemetria sieciowa pozwalaj\u0105 wychwyci\u0107 masowe lub powtarzalne pr\u00f3by CSRF, ustali\u0107 zasi\u0119g incydentu po fakcie i odr\u00f3\u017cni\u0107 sfa\u0142szowane \u017c\u0105dania od zwyk\u0142ej aktywno\u015bci. To uzupe\u0142nia obron\u0119 wbudowan\u0105 w sam\u0105 aplikacj\u0119.<\/p>\n<h2>Dowiedz si\u0119 wi\u0119cej<\/h2>\n<ul>\n<li><a href=\"https:\/\/www.sycope.com\/pl\/post\/podatnosc-idor-jak-wykryc-atak-na-aplikacje-webowe-przez-analize-ruchu-http\">Podatno\u015b\u0107 IDOR \u2013 jak wykry\u0107 atak na aplikacje webowe przez analiz\u0119 ruchu HTTP<\/a> \u2014 IDOR i CSRF to r\u00f3\u017cne luki w aplikacjach webowych, cz\u0119sto analizowane wsp\u00f3lnie w kontek\u015bcie nadu\u017cy\u0107 <a href=\"https:\/\/www.sycope.com\/pl\/post\/dictionary-item\/http-https\">HTTP<\/a>.<\/li>\n<li><a href=\"https:\/\/www.sycope.com\/pl\/post\/dictionary-item\/owasp-top-10\">OWASP Top 10<\/a> \u2014 CSRF nale\u017cy do klasycznych zagro\u017ce\u0144 uwzgl\u0119dnianych w zestawieniach OWASP dla aplikacji webowych.<\/li>\n<li><a href=\"https:\/\/www.sycope.com\/pl\/post\/dictionary-item\/application-layer-attack-l7\">Application Layer Attack (L7)<\/a> \u2014 CSRF jest atakiem warstwy aplikacji, bo wykorzystuje logik\u0119 HTTP i sesj\u0119 u\u017cytkownika.<\/li>\n<\/ul>\n","protected":false},"featured_media":0,"template":"","class_list":["post-4751","dictionary-item","type-dictionary-item","status-publish","hentry"],"acf":{"tytul":"Cross-Site Request Forgery (CSRF)","ikona":"","krotki_opis":"Podatno\u015b\u0107 aplikacji webowych, w kt\u00f3rej napastnik sprawia, \u017ce zalogowany u\u017cytkownik nie\u015bwiadomie wykonuje jak\u0105\u015b operacj\u0119, bo przegl\u0105darka sama dok\u0142ada do \u017c\u0105dania jego ciasteczko sesyjne."},"_links":{"self":[{"href":"https:\/\/www.sycope.com\/pl\/wp-json\/wp\/v2\/dictionary-item\/4751","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.sycope.com\/pl\/wp-json\/wp\/v2\/dictionary-item"}],"about":[{"href":"https:\/\/www.sycope.com\/pl\/wp-json\/wp\/v2\/types\/dictionary-item"}],"wp:attachment":[{"href":"https:\/\/www.sycope.com\/pl\/wp-json\/wp\/v2\/media?parent=4751"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}