CSRF: działanie wymuszone bez Państwa wiedzy

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ę¹.

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¹.

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¹.

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¹.

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¹. W obu przypadkach wyświetlana strona jest zwyczajna, a działanie odbywa się gdzie indziej.

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². 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².

Według OWASP kilka pomysłów na obronę nie działa¹:

• 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³. Bez tokenu atakujący nie może przygotować prawidłowego żądania³.
• W oprogramowaniu bezstanowym użyć ciasteczka podwójnego przesyłania (double-submit), najlepiej podpisanego³.
• Ustawić atrybut SameSite w ciasteczkach sesji³. 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⁴. Przy none ochrona nie jest zapewniona⁴.
• 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³.
• Nie używać żądań GET do operacji zmieniających stan³.

Te środki mają ograniczenia. SameSite=Lax przepuszcza żądania GET przy nawigacji najwyższego poziomu: punkt końcowy zmieniający stan przez GET pozostaje podatny². Starsze przeglądarki mogą nie stosować SameSite². 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¹³. 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⁴.

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¹. Ź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⁵. 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⁵. 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⁵.