Czym jest CSRF i jak go zapobiegać?

Question

Accepted Answer

**CSRF (Cross-Site Request Forgery)** oszukuje przeglądarkę zalogowanego użytkownika, zmuszając ją do wykonania **niezamierzonych żądań** do witryny, na której użytkownik jest uwierzytelniony — wykonując akcje (przelewy, zmiany) bez jego zgody, wykorzystując automatyczne wysyłanie przez przeglądarkę poświadczeń/ciasteczek. ## Jak działa CSRF ```text The attack exploits that browsers AUTO-SEND cookies (incl. session cookies) with requests: 1. a user is LOGGED IN to a site (has a session cookie) 2. the user visits a MALICIOUS page (or clicks a crafted link) 3. that page makes a request to the target site (e.g. a hidden form auto-submitting) 4. the browser AUTOMATICALLY includes the user's session cookie → the site thinks it's a legitimate request from the user → performs the action (transfer money, change email) → the user unknowingly performs an action they didn't intend. ``` ```html ``` ## Zapobieganie ```text ✓ CSRF TOKENS → a unique, unpredictable token per session/form that the server verifies; the attacker's site can't know it → the forged request fails (the primary defense) ✓ SameSite COOKIES → SameSite=Lax/Strict → cookies NOT sent on cross-site requests → blocks CSRF (now a strong, default-ish browser defense) ✓ Check Origin/Referer headers; require re-authentication for sensitive actions ✓ Don't use GET for state-changing actions (use POST/PUT/DELETE properly) → Frameworks often provide CSRF protection built in — enable/use it. ``` ## Dlaczego to ważne Zrozumienie CSRF i sposobów jego zapobiegania jest wartościowe, ponieważ to **powszechna luka bezpieczeństwa internetowego**, która wykorzystuje sposób działania przeglądarek, pozwalając atakującym na wykonywanie akcji jako uwierzytelnieni użytkownicy, dlatego jest to ważna wiedza z zakresu bezpieczeństwa dla deweloperów internetowych. Zrozumienie **jak działa CSRF** — wykorzystywanie tego, że przeglądarki **automatycznie wysyłają ciasteczka** (w tym ciasteczka sesji) z żądaniami, więc złośliwa strona może wyzwolić żądanie do witryny, na której użytkownik jest zalogowany, a przeglądarka dołącza ciasteczko sesji, powodując, że witryna traktuje sfałszowane żądanie jako legalne i wykonuje akcję (przelewy, zmiany konta) bez zgody użytkownika — jest konieczne do zrozumienia tego subtelnego, ale niebezpiecznego ataku. CSRF jest niebezpieczny, ponieważ może wykonywać wrażliwe akcje jako ofiara bez jej wiedzy, i jest powszechną luką bezpieczeństwa internetowego. Zrozumienie **zapobiegania** jest niezbędne: **tokeny CSRF** (unikalny, nieprzewidywalny token na sesję/formularz, który serwer weryfikuje — witryna atakującego nie może go znać, więc sfałszowane żądania zawodzą; podstawowa tradycyjna obrona), **ciasteczka SameSite** (ustawianie SameSite=Lax/Strict, aby ciasteczka nie były wysyłane w żądaniach cross-site, teraz silna obrona na poziomie przeglądarki, która jest coraz bardziej domyślna), sprawdzanie nagłówków Origin/Referer, wymaganie ponownego uwierzytelnienia dla wrażliwych akcji oraz nieużywanie GET dla operacji zmieniających stan. Zrozumienie, że **frameworki często zapewniają wbudowaną ochronę CSRF** (która powinna być włączona i używana) jest praktycznie ważne. Kombinacja tokenów CSRF i ciasteczek SameSite zapewnia solidną ochronę. Ponieważ CSRF jest powszechną luką bezpieczeństwa internetowego wykorzystującą zachowanie przeglądarki do wykonywania niezamierzonych akcji jako uwierzytelnieni użytkownicy, i ponieważ zrozumienie jak to działa i jak go zapobiegać (tokeny CSRF, ciasteczka SameSite, ochrony frameworków) jest ważne dla deweloperów internetowych, zrozumienie CSRF i jego zapobiegania jest wartościową, praktycznie istotną wiedzą z zakresu bezpieczeństwa — ważna klasa ataków do zrozumienia i obrony, gdzie obrony (tokeny CSRF i ciasteczka SameSite) są kluczową wiedzą do ochrony użytkowników przed oszukaniem ich do niezamierzonych akcji, znacząca klasa ataków dla każdej aplikacji internetowej ze zmianami stanu uwierzytelnionego.