Cyber Security Academy · Lekcja

Cross-Site Request Forgery (CSRF)

Poznać sposób, w jaki ataki CSRF fałszują uwierzytelnione żądania, oraz dowiedzieć się, jak chronią przed nimi tokeny CSRF i pliki cookie SameSite

Lekcja 3 z 413 kroki

Cross-Site Request Forgery (CSRF) to bezpłatna lekcja Cyber Security Academy na CoddyKit. To lekcja 3 z 4. Możesz przeczytać całą lekcję poniżej za darmo — a potem ćwiczyć ją interaktywnie w przeglądarce z wbudowanym edytorem kodu i tutorem AI dostępnym 24/7. To część ścieżki edukacyjnej Cyber Security Academy, a Twój postęp synchronizuje się między webem a aplikacją CoddyKit. Kurs Cyber Security Academy zawiera 4 lekcji w sumie.

Czym jest CSRF?

Cross-Site Request Forgery (CSRF) nakłania przeglądarkę uwierzytelnionego użytkownika do wykonywania nieautoryzowanych żądań wobec aplikacji internetowej. Przeglądarka automatycznie wysyła pliki cookie wraz z żądaniami, dlatego bez dodatkowych zabezpieczeń serwer nie może odróżnić żądań prawidłowych od sfałszowanych.

Jak działa CSRF

Przebieg:

Ofiara jest zalogowana w bank.com (plik cookie sesji znajduje się w przeglądarce)
Ofiara odwiedza stronę atakującego zawierającą: <img src="https://bank.com/transfer?to=attacker&amount=1000">
Przeglądarka wysyła żądanie GET wraz z plikiem cookie bank.com
Bank realizuje przelew

CSRF z żądaniami POST

CSRF wykorzystujące metodę POST wymaga formularza:

<form action="https://bank.com/transfer" method="POST" id="f">
  <input name="to" value="attacker">
  <input name="amount" value="1000">
</form>
<script>document.getElementById("f").submit()</script>

Tokeny CSRF

Podstawową ochroną jest token CSRF: losowa, tajna wartość przypisana do sesji (lub żądania), umieszczana w formularzach. Serwer weryfikuje token przy każdym żądaniu zmieniającym stan. Atakujący z innej domeny nie może odczytać tokenu (zasada tego samego źródła).

Atrybut SameSite pliku cookie

SameSite=Strict: plik cookie nie jest wysyłany z żadnymi żądaniami między witrynami. SameSite=Lax: plik cookie jest wysyłany podczas bezpiecznych nawigacji najwyższego poziomu (odsyłaczy), ale nie wraz z żądaniami POST z innych witryn. Współczesne przeglądarki domyślnie używają wartości Lax, co znacznie ogranicza ryzyko CSRF.

Wzorzec Double Submit Cookie

Alternatywa dla przechowywania tokenu po stronie serwera: należy ustawić losowy plik cookie CSRF i wymagać, aby został również przesłany jako parametr żądania. Atakujący nie może odczytać pliku cookie (zasada tego samego źródła), więc nie może dopasować go do danych formularza.

Niestandardowe nagłówki żądań

W przypadku żądań AJAX wymaganie niestandardowego nagłówka (np. X-Requested-With: XMLHttpRequest) zapewnia ochronę przed CSRF, ponieważ przeglądarki blokują skryptom między źródłami ustawianie dowolnych nagłówków (wymusza to CORS).

Kiedy tokeny CSRF nie wystarczają

Tokeny CSRF zawodzą, gdy:

występuje XSS — atakujący może odczytać token za pomocą JavaScriptu
token wycieknie w adresie URL (nagłówek Referer)
token jest przewidywalny lub używany ponownie
konfiguracja CORS pozwala na korzystanie ze źródła atakującego

Testowanie ochrony przed CSRF

Etapy testowania:

Zidentyfikować żądania zmieniające stan (POST, PUT, DELETE)
Usunąć lub zmodyfikować token CSRF i ponownie wysłać żądanie
Przygotować żądanie formularza między źródłami i sprawdzić, czy się powiedzie
Zweryfikować atrybut SameSite plików cookie sesji

CSRF w interfejsach API

Interfejsy API REST używające formatu JSON są często odporne na CSRF, jeśli:

wymagają Content-Type: application/json (formularze HTML nie mogą go ustawić)
używają uwierzytelniania opartego na tokenach (nagłówek Authorization, a nie pliki cookie)

Interfejsy API, które akceptują pliki cookie, nadal muszą implementować ochronę przed CSRF.

Współczesny obraz zagrożeń CSRF

W związku z tym, że Chrome, Firefox i Safari domyślnie stosują SameSite=Lax, wiele tradycyjnych ataków CSRF jest blokowanych. Jednak ataki z subdomen oraz niektóre wzorce nawigacji mogą nadal omijać ograniczenia Lax. Aby uzyskać solidną ochronę, należy połączyć SameSite z tokenami CSRF.

Szybkie sprawdzenie: CSRF

Jaka jest podstawowa ochrona przed atakami CSRF w aplikacjach internetowych?

Odpowiedz w interaktywnej lekcji

Podsumowanie lekcji

CSRF wykorzystuje automatyczne dołączanie plików cookie przez przeglądarkę do fałszowania uwierzytelnionych żądań wysyłanych ze złośliwych witryn. Podstawową ochroną są tokeny CSRF weryfikowane po stronie serwera. Dodatkową ochroną jest atrybut plików cookie SameSite=Strict/Lax. Interfejsy API używające uwierzytelniania za pomocą tokenów w nagłówkach (a nie plików cookie) są z natury odporne na CSRF. Należy łączyć zabezpieczenia; XSS może ominąć tokeny CSRF, jeśli występuje w aplikacji.

Bezpłatny start

Ucz się Cyber Security Academy dzięki korepetycjom AI — za darmo

Pisz i uruchamiaj kod w przeglądarce, otrzymuj natychmiastową pomoc od korepetytora AI dostępnego 24/7 i kontynuuj naukę w sieci lub w aplikacji.

Kursy: 76
Lekcje: 303

Zacznij naukę bezpłatnie Wyświetl pełny kurs

Często zadawane pytania

Czy lekcja „Cross-Site Request Forgery (CSRF)” jest bezpłatna?

Tak — pełny tekst „Cross-Site Request Forgery (CSRF)” jest dostępny za darmo tutaj w sieci. Aby ćwiczyć ją interaktywnie (wbudowany edytor kodu i tutor AI dostępny 24/7) i odblokować resztę kursu Cyber Security Academy, przejdź na CoddyKit PRO. Kurs Cyber Security Academy zawiera 4 lekcji w sumie.

Co nauczysz się w „Cross-Site Request Forgery (CSRF)”?

Poznać sposób, w jaki ataki CSRF fałszują uwierzytelnione żądania, oraz dowiedzieć się, jak chronią przed nimi tokeny CSRF i pliki cookie SameSite Ćwiczysz Cyber Security Academy z praktycznym kodem, który uruchamiasz bezpośrednio w przeglądarce, a tutor AI dostępny 24/7 odpowiada na Twoje pytania podczas pracy nad lekcją.

Czy potrzebuję doświadczenia, aby zacząć Cyber Security Academy?

Nie wymagamy żadnego doświadczenia. Cyber Security Academy w CoddyKit jest strukturyzowany dla początkujących i zaawansowanych użytkowników, więc możesz zacząć tutaj lub od początku i uczyć się w swoim tempie. To lekcja 3 z 4.

Ile czasu zajmuje lekcja „Cross-Site Request Forgery (CSRF)”?

Większość lekcji CoddyKit trwa około 5–10 minut. Każda lekcja to mały, interaktywny krok, dzięki czemu robisz systematyczne postępy i zawsze wracasz dokładnie do tego samego miejsca — na webie i w aplikacji.

Czy mogę pisać i uruchamiać kod w tej lekcji Cyber Security Academy?

Tak. Każda lekcja Cyber Security Academy zawiera wbudowany edytor kodu, więc piszesz i uruchamiasz prawdziwy kod bezpośrednio w przeglądarce i od razu otrzymujesz sprzężenie zwrotne od AI — bez konfiguracji na komputerze.

Wszystkie lekcje w tym kursie

SQL Injection: jak i dlaczego działa
Cross-Site Scripting (XSS)
Cross-Site Request Forgery (CSRF)
Błędna konfiguracja zabezpieczeń i ujawnione usługi

← Powrót do Cyber Security Academy