---
id: CP-053
slug: csrf-sfalszowane-zadanie-miedzy-witrynami
lang: pl
title: "CSRF: działanie wymuszone bez Państwa wiedzy"
description: Podstawiona strona lub wiadomość może uruchomić w Państwa przeglądarce działanie w serwisie, w którym są Państwo zalogowani. Mechanizm i ochrona.
canonical_url: https://startbrain.io/cyberpedia/pl/articles/csrf-sfalszowane-zadanie-miedzy-witrynami/
markdown_url: https://startbrain.io/cyberpedia/pl/articles/csrf-sfalszowane-zadanie-miedzy-witrynami.md
publisher: Brain (https://startbrain.io)
license: CC BY 4.0 (https://creativecommons.org/licenses/by/4.0/)
cite_as: "Brain, „CSRF: działanie wymuszone bez Państwa wiedzy”, Cyberpedia, 2026. https://startbrain.io/cyberpedia/pl/articles/csrf-sfalszowane-zadanie-miedzy-witrynami/ (CC BY 4.0)"
wing: 1
theme: understand_hacking
reflex: cr-018
schema: G3
updated: "2026-11-03"
translations:
  pl: https://startbrain.io/cyberpedia/pl/articles/csrf-sfalszowane-zadanie-miedzy-witrynami/
  fr: https://startbrain.io/cyberpedia/fr/articles/csrf-requete-forcee-inter-sites/
  en: https://startbrain.io/cyberpedia/en/articles/csrf-cross-site-request-forgery/
  de: https://startbrain.io/cyberpedia/de/articles/csrf-websiteuebergreifende-anfragefaelschung/
  es: https://startbrain.io/cyberpedia/es/articles/csrf-falsificacion-peticiones-entre-sitios/
  it: https://startbrain.io/cyberpedia/it/articles/csrf-richiesta-contraffatta-tra-siti/
  nl: https://startbrain.io/cyberpedia/nl/articles/csrf-afgedwongen-verzoek-tussen-sites/
  pt: https://startbrain.io/cyberpedia/pt/articles/csrf-pedido-forjado-entre-sites/
sources:
  - "n": 1
    title: Cross Site Request Forgery (CSRF) | OWASP Foundation
    publisher: OWASP
    url: https://community.owasp.org/attacks/csrf
    accessed: "2026-11-03"
  - "n": 2
    title: Prevent Cross-Site Request Forgery (XSRF/CSRF) attacks in ASP.NET Core
    publisher: Microsoft
    url: https://learn.microsoft.com/en-us/aspnet/core/security/anti-request-forgery?view=aspnetcore-10.0
    accessed: "2026-11-03"
  - "n": 3
    title: Cross-Site Request Forgery Prevention - OWASP Cheat Sheet Series
    publisher: OWASP
    url: https://cheatsheetseries.owasp.org/cheatsheets/Cross-Site_Request_Forgery_Prevention_Cheat_Sheet.html
    accessed: "2026-11-03"
  - "n": 4
    title: SameSite | OWASP Foundation
    publisher: OWASP
    url: https://community.owasp.org/SameSite
    accessed: "2026-11-03"
  - "n": 5
    title: "CWE - CWE-352: Cross-Site Request Forgery (5.0)"
    publisher: MITRE
    url: https://cwe.mitre.org/data/definitions/352.html
    accessed: "2026-11-03"
---

# CSRF: działanie wymuszone bez Państwa wiedzy

CSRF (Cross-Site Request Forgery) to atak, który zmusza użytkownika do wykonania niechcianych działań w aplikacji internetowej, w której jest już uwierzytelniony [1]. Atakujący nie potrzebuje hasła ofiary: sprawia, że działa jej przeglądarka.

Dla pracownika typowy scenariusz jest prosty. W jednej karcie otwarta jest poczta albo serwis bankowy. Link otrzymany e-mailem lub przez komunikator prowadzi na inną stronę, a ta w tle wysyła żądanie do usługi, w której użytkownik pozostał zalogowany [1].

## W 30 sekund

- Gdzie to się zdarza: w większości serwisów internetowych bez zabezpieczenia przed CSRF, gdy otwierają Państwo link lub stronę z pułapką w tej samej przeglądarce [1].
- Czego chce atakujący: wywołać działanie, które coś zmienia, na przykład przelew lub zmianę hasła [1].
- Odruch: wylogować się z serwisu, gdy skończy się z niego korzystać [2].
- Skąd bierze się luka: z aplikacji, nie od użytkownika [2].

## Pytania wprost

### Czy CSRF kradnie moje hasło?

Nie, samo w sobie nie. Atak wykorzystuje tożsamość i uprawnienia ofiary, by wykonać działanie w jej imieniu [1]. Dotyczy działań, które zmieniają stan usługi, takich jak zmiana adresu e-mail lub hasła albo zakup czegoś. Zmuszenie ofiary do wyświetlenia danych nic atakującemu nie daje, ponieważ odpowiedź trafia do ofiary, a nie do niego [1].

### Dlaczego usługa wykonuje żądanie, którego nie chciałem?

Ponieważ nie potrafi go odróżnić od żądania prawidłowego. W przypadku większości witryn żądania przeglądarki automatycznie zawierają dane uwierzytelniające powiązane z witryną, takie jak ciasteczko sesji [1]. Jeśli użytkownik jest uwierzytelniony, witryna nie ma więc jak oddzielić żądania sfałszowanego od prawdziwego [1]. CWE opisuje tę słabość tak: aplikacja nie weryfikuje lub nie może zweryfikować, czy żądanie zostało świadomie przesłane przez użytkownika, który je wysłał [5].

### Czy jestem chroniony, jeśli usługa korzysta z HTTPS?

Nie. Według OWASP samo HTTPS nie chroni przed CSRF, choć pozostaje warunkiem wstępnym tego, by pozostałe środki były wiarygodne [1].

### Czy problem leży po mojej stronie, czy po stronie aplikacji?

Po stronie aplikacji. Microsoft mówi to wprost: luki CSRF to zasadniczo problem aplikacji internetowej, a nie użytkownika końcowego [2]. Działania użytkownika jedynie ograniczają narażenie: wylogowanie po zakończeniu pracy i regularne czyszczenie ciasteczek przeglądarki [2].

## W skórze atakującego

Atakujący zaczyna od wyszukania żądania, które coś zmienia w usłudze, a następnie tworzy adres lub skrypt odtwarzający je z własnymi wartościami. OWASP podaje przykład fikcyjnego banku: prawidłowe żądanie przelewa 100 dolarów wskazanemu odbiorcy, a atakujący podstawia siebie w miejsce odbiorcy i podnosi kwotę [1].

Pozostaje sprawić, by ofiara załadowała to żądanie, gdy jest zalogowana. Wymieniono dwie metody: niezamówiony e-mail z treścią HTML albo pułapkę umieszczoną na stronach, które ofiara prawdopodobnie odwiedzi, korzystając ze swojej usługi online [1].

Atak może też zostać zapisany w samej podatnej witrynie, na przykład w polu przyjmującym HTML. Staje się wtedy bardziej prawdopodobny: ofiara chętniej otwiera stronę tej witryny niż dowolną stronę w Internecie i na pewno jest tam już zalogowana [1].

## Co widać na ekranie

Często nic. Link z pułapką może udawać zwykły link, z tekstem w rodzaju „zobacz moje zdjęcia”. Może też mieć postać fałszywego obrazka o zerowym rozmiarze: jeśli znajduje się w e-mailu, ofiara niczego nie widzi, a przeglądarka mimo to wysyła żądanie, bez żadnego widocznego znaku, że operacja się odbyła [1].

```text
Ilustracja zneutralizowana, to nie jest prawdziwy adres.
Link udający zwykły: wyświetlany tekst „Zobacz moje zdjęcia”, ukryty adres
hxxp://banque[.]exemple[.]invalid/virement?dest=[konto atakującego]&montant=[wysoka kwota]
Wariant: niewidoczny obrazek w e-mailu, ładowany bez kliknięcia.
```

Jeśli usługa oczekuje żądania typu POST, atakujący może umieścić na swojej stronie formularz z ukrytymi polami. Ofiara sądzi, że formularz robi coś innego, i klika, albo skrypt wysyła go automatycznie po załadowaniu strony [1]. W obu przypadkach wyświetlana strona jest zwyczajna, a działanie odbywa się gdzie indziej.

## Pod maską

Mechanizm opiera się na normalnym zachowaniu przeglądarek. Zapisują one ciasteczka wystawione przez aplikację, w tym ciasteczka sesji uwierzytelnionych użytkowników, i wysyłają wszystkie ciasteczka danej domeny z każdym żądaniem, niezależnie od tego, w jaki sposób żądanie powstało w przeglądarce [2]. Problem nie dotyczy tylko ciasteczek: uwierzytelnianie typu Basic i Digest jest również podatne, ponieważ przeglądarka automatycznie ponownie wysyła dane uwierzytelniające aż do końca sesji [2].

Według OWASP kilka pomysłów na obronę nie działa [1]:

- tajne ciasteczko, bo wszystkie ciasteczka są wysyłane z każdym żądaniem;
- przyjmowanie wyłącznie żądań POST, bo do ich sfałszowania wystarcza ukryty formularz;
- transakcje wieloetapowe, dopóki atakujący może przewidzieć każdy etap;
- sprawdzanie samego nagłówka Referer, bo można go sfałszować, a czasem go brakuje ze względu na prywatność.

Zalecane zabezpieczenia po stronie aplikacji są następujące.

- Najpierw sprawdzić, czy framework ma już ochronę przed CSRF, i ją zastosować. Jeśli nie, dodać tokeny anty-CSRF do wszystkich żądań zmieniających stan i weryfikować je po stronie serwera [3]. Bez tokenu atakujący nie może przygotować prawidłowego żądania [3].
- W oprogramowaniu bezstanowym użyć ciasteczka podwójnego przesyłania (double-submit), najlepiej podpisanego [3].
- Ustawić atrybut SameSite w ciasteczkach sesji [3]. Przy wartości strict przeglądarka nie wysyła ciasteczka w żądaniach między witrynami, nawet po kliknięciu zwykłego linku. Przy lax wysyła je po przejściu z innej witryny przez link, ale wstrzymuje je w metodach narażonych na CSRF, takich jak POST [4]. Przy none ochrona nie jest zapewniona [4].
- Sprawdzać pochodzenie żądania za pomocą standardowych nagłówków, w szczególności Sec-Fetch-Site, obsługiwanego przez wszystkie główne przeglądarki od marca 2023 [3].
- Nie używać żądań GET do operacji zmieniających stan [3].

Te środki mają ograniczenia. SameSite=Lax przepuszcza żądania GET przy nawigacji najwyższego poziomu: punkt końcowy zmieniający stan przez GET pozostaje podatny [2]. Starsze przeglądarki mogą nie stosować SameSite [2]. Luka XSS może obejść wszystkie zabezpieczenia anty-CSRF; robak Samy na przykład użył XMLHttpRequest, aby zdobyć token CSRF i fałszować żądania [1][3]. Domyślne zachowanie SameSite jest różne: w grudniu 2024 lax było wartością domyślną w Chrome, Edge i Operze, ale w żadnej wersji Firefoksa ani Safari, stąd zalecenie, by ustawiać ją jawnie [4].

## Analizy incydentów

### 2008: exploit na uTorrent

OWASP podaje jako rzeczywisty przykład ataku CSRF na aplikację działającą na żądaniach GET exploit wymierzony w uTorrent z 2008 roku. Został on użyty na dużą skalę do pobierania złośliwego oprogramowania [1]. Źródło nie podaje nic więcej: ani liczby ofiar, ani sposobu rozpowszechniania.

### Luki skatalogowane w CWE (identyfikatory z lat 2004 do 2009)

CWE-352 podaje wybraną listę zaobserwowanych przykładów, która nie jest wyczerpująca [5]. Kilka z nich opiera się na zwykłym adresie URL w znaczniku img: CVE-2004-1703 i CVE-2004-1995 pozwalają dodawać konta użytkowników, CVE-2004-1842 uzyskać uprawnienia administratora [5]. Inne dotyczą samego zarządzania: CVE-2009-3520 pozwala zmienić hasło administratora, a CVE-2009-3759 zmieniać hasła lub wyłączyć maszynę wirtualną z poziomu interfejsu internetowego [5].

## Źródła

1. OWASP, „Cross Site Request Forgery (CSRF) | OWASP Foundation”. https://community.owasp.org/attacks/csrf (dostęp 3 listopada 2026)
2. Microsoft, „Prevent Cross-Site Request Forgery (XSRF/CSRF) attacks in ASP.NET Core”. https://learn.microsoft.com/en-us/aspnet/core/security/anti-request-forgery?view=aspnetcore-10.0 (dostęp 3 listopada 2026)
3. OWASP, „Cross-Site Request Forgery Prevention - OWASP Cheat Sheet Series”. https://cheatsheetseries.owasp.org/cheatsheets/Cross-Site_Request_Forgery_Prevention_Cheat_Sheet.html (dostęp 3 listopada 2026)
4. OWASP, „SameSite | OWASP Foundation”. https://community.owasp.org/SameSite (dostęp 3 listopada 2026)
5. MITRE, „CWE - CWE-352: Cross-Site Request Forgery (5.0)”. https://cwe.mitre.org/data/definitions/352.html (dostęp 3 listopada 2026)

---

Źródło oryginalne: Cyberpedia, publiczna encyklopedia cyberbezpieczeństwa i AI wydawana przez Brain. Wersja kanoniczna: https://startbrain.io/cyberpedia/pl/articles/csrf-sfalszowane-zadanie-miedzy-witrynami/
Możesz swobodnie wykorzystywać ten tekst na licencji CC BY 4.0 (https://creativecommons.org/licenses/by/4.0/), pod warunkiem podania „Brain, Cyberpedia” wraz z odnośnikiem do powyższego adresu.