0Pricing
Frontend Academy · Lekcja

CSRF: pliki cookie SameSite i tokeny

Pozna Pan/Pani, jak Cross-Site Request Forgery wykorzystuje pliki cookie, zastosuje SameSite=Strict/Lax, aby zapobiec atakom, i doda tokeny synchronizujące dla dodatkowej ochrony.

CSRF: pliki cookie SameSite i tokeny to bezpłatna lekcja Frontend Academy na CoddyKit. To lekcja 2 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 Frontend Academy, a Twój postęp synchronizuje się między webem a aplikacją CoddyKit. Kurs Frontend Academy zawiera 4 lekcji w sumie.

Czym jest CSRF?

Fałszowanie żądań między witrynami: atakujący nakłania przeglądarkę uwierzytelnionego użytkownika do wysłania żądania do Państwa witryny. Przeglądarka dołącza ciasteczka użytkownika — serwer uznaje żądanie za prawidłowe żądanie pochodzące od użytkownika.

Klasyczny atak CSRF

Użytkownik jest zalogowany w bank.com. Odwiedza evil.com. Witryna evil.com wysyła ukryty formularz do bank.com/transfer z numerem konta atakującego. Przeglądarka automatycznie wysyła ciasteczko sesyjne bank.com. Serwer przelewa pieniądze.

Problem z zaufaniem

CSRF działa, ponieważ przeglądarki automatycznie dołączają ciasteczka do żądań między źródłami. Bez dodatkowej ochrony serwer nie może stwierdzić, że żądanie pochodzi ze złośliwej witryny.

Ciasteczka SameSite — nowoczesne rozwiązanie

Atrybut ciasteczka SameSite określa, kiedy ciasteczka są wysyłane w żądaniach między źródłami. Strict: nigdy nie są wysyłane między źródłami. Lax (domyślne w Chrome): są wysyłane wyłącznie podczas nawigacji GET na najwyższym poziomie. None: są zawsze wysyłane (wymaga również atrybutu Secure).

Set-Cookie: session=abc; HttpOnly; Secure; SameSite=Lax

Domyślne SameSite=Lax

Chrome ustawia wartość Lax dla wszystkich ciasteczek, jeśli nie określono SameSite. Blokuje to większość ataków CSRF — mimo to należy jawnie określać tę wartość.

SameSite=Strict dla maksymalnego bezpieczeństwa

Wartości Strict należy używać dla najbardziej wrażliwych ciasteczek (sesji administratorów, transakcji bankowych). Wadą jest to, że użytkownik może wyglądać na wylogowanego po przejściu do witryny za pomocą łącza z innej witryny.

Tokeny CSRF (wzorzec synchronizatora)

W przypadku obsługi starszych przeglądarek lub potrzeby dodatkowej ochrony należy używać tokenów CSRF. Serwer generuje losowy token, umieszcza go na stronie i wymaga jego przesłania przy każdym żądaniu zmieniającym stan.

// Server embeds token in HTML or sets it as a non-HttpOnly cookie:
<meta name="csrf-token" content="a1b2c3...">

// Client reads token and sends in header:
const token = document.querySelector('meta[name=csrf-token]').content;
fetch('/transfer', {
  method: 'POST',
  headers: { 'X-CSRF-Token': token },
  body: JSON.stringify({ amount: 100 })
});

// Server verifies the X-CSRF-Token header matches the user's session

Ciasteczko Double-Submit

Serwer ustawia ciasteczko CSRF (bez HttpOnly, aby JavaScript mógł je odczytać). Klient odczytuje je i wysyła jego wartość w nagłówku. Serwer sprawdza, czy ciasteczko jest zgodne z nagłówkiem. Atakujący nie może odczytać ciasteczka między źródłami, więc nie może odtworzyć nagłówka.

Dlaczego to działa

Witryna evil.com atakującego nie może odczytać ciasteczek z bank.com (zasada tego samego źródła). Nie może więc ustawić nagłówka X-CSRF-Token. Żądanie nie przechodzi weryfikacji tokenu na serwerze.

CSRF w SPA z tokenami Bearer

Jeśli uwierzytelnianie odbywa się za pomocą Authorization: Bearer <jwt> przechowywanego w pamięci (a nie w ciasteczku), CSRF nie ma zastosowania — przeglądarki nie wysyłają automatycznie nagłówków. Kompromis polega na większej podatności na XSS (ponieważ tokeny dostępne dla JavaScriptu mogą zostać skradzione).

Sztuczka z niestandardowym nagłówkiem

W przypadku interfejsów API, które akceptują wyłącznie JSON z niestandardowym nagłówkiem (np. X-Requested-With), przeglądarki wysyłają żądanie wstępne OPTIONS — i nie dołączają ciasteczek do tego żądania. Skutecznie blokuje to CSRF oparte na prostych formularzach.

Endpointy idempotentne a zmieniające stan

CSRF dotyczy głównie żądań zmieniających stan (POST, PUT, DELETE). Endpointy GET powinny być idempotentne — nie powinny powodować efektów ubocznych — aby sfałszowane żądanie GET nie mogło wyrządzić szkody.

Szybkie sprawdzenie

Jaka wartość ciasteczka SameSite domyślnie uniemożliwia wysyłanie ciasteczek w większości żądań między witrynami we współczesnych przeglądarkach?

Podsumowanie: zapobieganie CSRF

Dla ciasteczek sesyjnych należy ustawić SameSite=Lax (lub Strict) — blokuje to większość ataków CSRF. Należy dodać HttpOnly + Secure. Dla dodatkowej ochrony należy używać tokenów CSRF (synchronizatora lub ciasteczka Double-Submit). Tokeny Bearer w nagłówkach eliminują CSRF, ale zwiększają ryzyko XSS. Sztuczka z niestandardowym nagłówkiem wymusza żądanie wstępne. Żądania GET powinny być idempotentne.

Często zadawane pytania

Czy lekcja „CSRF: pliki cookie SameSite i tokeny” jest bezpłatna?

Tak — pełny tekst „CSRF: pliki cookie SameSite i tokeny” 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 Frontend Academy, przejdź na CoddyKit PRO. Kurs Frontend Academy zawiera 4 lekcji w sumie.

Co nauczysz się w „CSRF: pliki cookie SameSite i tokeny”?

Pozna Pan/Pani, jak Cross-Site Request Forgery wykorzystuje pliki cookie, zastosuje SameSite=Strict/Lax, aby zapobiec atakom, i doda tokeny synchronizujące dla dodatkowej ochrony. Ćwiczysz Frontend 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ąć Frontend Academy?

Nie wymagamy żadnego doświadczenia. Frontend 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 2 z 4.

Ile czasu zajmuje lekcja „CSRF: pliki cookie SameSite i tokeny”?

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 Frontend Academy?

Tak. Każda lekcja Frontend 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

  1. Zapobieganie XSS: kodowanie danych wyjściowych i CSP
  2. CSRF: pliki cookie SameSite i tokeny
  3. Content Security Policy: nonce i hash
  4. Przepływy OAuth po stronie frontendu
← Powrót do Frontend Academy