Zapewnia dogłębną eksplorację ataków Cross-Site Request Forgery (CSRF), wyjaśniając ich mechanikę, demonstrując przykłady i szczegółowo opisując różne metody zapobiegania w celu zwiększenia bezpieczeństwa aplikacji internetowych.
Podczas pracy nad tworzeniem stron internetowych, zwłaszcza z ciasteczkami, często słyszymy takie frazy jak „to ustawienie pomaga zapobiegać CSRF”. Jednak wiele osób ma tylko mgliste pojęcie, co naprawdę oznacza „CSRF”.
Dzisiaj zagłębimy się w CSRF (Cross-Site Request Forgery), powszechną lukę w zabezpieczeniach sieciowych. To pomoże nam skuteczniej radzić sobie z problemami związanymi z CSRF.
CSRF (Cross-Site Request Forgery) to rodzaj ataku sieciowego, w którym atakujący oszukują uwierzytelnionych użytkowników, aby wykonywali niezamierzone działania. W prostych słowach, to „hakerzy udający użytkowników, aby przeprowadzać nieautoryzowane działania”.
Aby zrozumieć CSRF, musimy pojąć kilka kluczowych pojęć:
Polityka tej samej domeny to funkcja bezpieczeństwa w przeglądarkach, która ogranicza, w jaki sposób dokument lub skrypt z jednego pochodzenia może wchodzić w interakcję z zasobami z innego pochodzenia.
Pochodzenie składa się z protokołu (takiego jak HTTP lub HTTPS), nazwy domeny i numeru portu. Na przykład https://example.com:443 to jedno pochodzenie, podczas gdy https://demo.com:80 to inne.
Polityka tej samej domeny ogranicza dostęp do danych między stronami z różnych pochodzeń, co oznacza:
Jednakże, aby utrzymać otwartość i interoperacyjność Internetu (jak ładowanie zasobów z CDNs lub wysyłanie żądań do zewnętrznych API do logowania), polityka tej samej domeny nie ogranicza żądań sieciowych między różnymi pochodzeniami:
<script>, <img>, <link>, <iframe> tags)Mechanizm automatycznego wysyłania ciasteczek to ważna funkcja przeglądarek. Gdy przeglądarka wysyła żądanie do domeny, automatycznie dołącza do niego wszystkie ciasteczka dla tej domeny. Ten proces jest automatyczny i nie wymaga żadnego kodu JavaScript ani interakcji użytkownika.
Ten mechanizm pozwala stronom internetowym łatwo pamiętać status logowania użytkowników, ponieważ każde żądanie automatycznie przekazuje informacje tożsamości użytkownika.
Pogrubienie
Na przykład, gdy zalogujesz się na stronie bankowej (bank.com) i otrzymasz ciasteczko tożsamości, wtedy gdy klikniesz, aby zobaczyć swoje zestawienie, przeglądarka automatycznie odnajduje wszystkie ciasteczka pasujące do bank.com i dołącza je do żądania zestawienia. Serwer banku może wtedy zidentyfikować cię z backendu i zwrócić informacje o zestawieniu.
Użytkownik loguje się na docelowej stronie internetowej (np. stronie bankowej) i otrzymuje ciasteczko uwierzytelnienia. Ten krok wykorzystuje mechanizm automatycznego wysyłania ciasteczek. Po ustawieniu ciasteczka uwierzytelnienia tożsamości przez stronę bankową, przeglądarka automatycznie dołącza to ciasteczko do każdego żądania wysłanego do tej strony.
Bez wylogowywania się, użytkownik odwiedza złośliwą stronę internetową. W tym momencie, z powodu polityki tej samej domeny, złośliwa strona nie może bezpośrednio odczytać ani zmodyfikować ciasteczka strony bankowej. Chroni to przed bezpośrednim kradzieżą informacji tożsamości użytkownika.
Złośliwa strona zawiera żądanie do docelowej strony (jak operacja przelewu).
Choć polityka tej samej domeny ogranicza dostęp między różnymi pochodzeniami, pozwala na żądania sieciowe między różnymi pochodzeniami, takie jak żądania inicjowane za pomocą <img>, <form> tags. Atakujący wykorzystują tę „linię załamania”.
Przeglądarka użytkownika automatycznie wysyła to żądanie, wraz z ciasteczkiem docelowej strony. To jest sedno ataku CSRF. Wykorzystuje zarówno politykę tej samej domeny, pozwalającą na żądania między różnymi pochodzeniami, jak i mechanizm automatycznego wysyłania ciasteczek (nawet żądania inicjowane przez złośliwe strony załadują ciasteczka pasujące do domeny).
Docelowa strona odbiera żądanie, weryfikuje, że ciasteczko jest ważne, i wykonuje operację. Serwer nie może powiedzieć, czy to żądanie pochodzi od prawdziwej akcji użytkownika, ponieważ dołączone ciasteczko jest ważne.
Zilustrujmy, jak dochodzi do ataku CSRF, za pomocą konkretnego przykładu. Użyjemy fikcyjnej strony bankowej bank.com jako przykładu.
Po pierwsze, użytkownik odwiedza https://bank.com i loguje się na swoje konto.
Po pomyślnym zalogowaniu, serwer ustawia ciasteczko uwierzytelnienia, na przykład:
Użytkownik wykonuje operację przelewu na stronie bankowej, powiedzmy, przesyłając 1000$ do Alicji. Ta operacja może wysłać żądanie takie jak:
Teraz, załóżmy, że atakujący tworzy złośliwą stronę internetową https://evil.com, zawierającą następujący HTML:
Gdy użytkownik kliknie link https://evil.com bez wylogowania się ze swojego konta bankowego, ponieważ jest już zalogowany do bank.com, przeglądarka ma ważne ciasteczko session_id.
Po załadowaniu złośliwej strony automatycznie wysyła ona ukryty formularz, wysyłając żądanie o przelew do https://bank.com/transfer.
Przeglądarka użytkownika automatycznie dołącza ciasteczko bank.com do tego żądania. Serwer bank.com odbiera żądanie, weryfikuje, że ciasteczko jest ważne, a następnie wykonuje tę nieautoryzowaną operację przelewu.
Oto kilka powszechnie używanych metod obrony przed CSRF. Wyjaśnimy szczegółowo zasadę każdej metody i jak skutecznie zapobiega ona atakom CSRF:
Tokeny CSRF są jednym z najczęściej stosowanych i skutecznych sposobów obrony przed atakami CSRF. Oto jak to działa:
Ponieważ token CSRF jest unikalną wartością związaną z sesją użytkownika, a atakujący nie może znać ani zgadnąć tej wartości (ponieważ jest inna dla każdej sesji), nawet jeśli atakujący oszuka użytkownika, aby wysłał żądanie, serwer odrzuci je z powodu braku ważnego tokenu CSRF.
Przykład wdrożenia:
Na stronie serwera (używając Node.js i Express):
W JavaScript na frontendzie:
RefererNagłówek Referer zawiera URL strony, która zainicjowała żądanie. Poprzez sprawdzenie nagłówka Referer, serwer może określić, czy żądanie pochodzi z legalnego źródła.
Ponieważ ataki CSRF zwykle pochodzą z różnych domen, nagłówek Referer pokaże domenę atakującego. Poprzez weryfikację, czy Referer jest oczekiwaną wartością, można zablokować żądania z nieznanych źródeł.
Warto jednak zaznaczyć, że ta metoda nie jest całkowicie niezawodna, ponieważ niektóre przeglądarki mogą nie wysyłać nagłówka Referer, a użytkownicy mogą wyłączyć ten nagłówek przez ustawienia przeglądarki lub wtyczki.
Przykład wdrożenia:
SameSiteSameSite to atrybut ciasteczka używany do kontrolowania, czy ciasteczka są wysyłane z żądaniami między różnymi stronami. Ma trzy możliwe wartości:
Strict: Ciasteczka są wysyłane tylko w żądaniach z tej samej strony.Lax: Ciasteczka są wysyłane w żądaniach z tej samej strony i nawigacji na najwyższym poziomie.None: Ciasteczka są wysyłane we wszystkich żądaniach między różnymi stronami (musi być używane z atrybutem Secure).Gdy SameSite jest ustawione na Strict, może całkowicie zapobiec wysyłaniu ciasteczek przez strony trzecie, co skutecznie zapobiega atakom CSRF. Jeśli SameSite jest ustawione na Lax, chroni operacje wrażliwe, jednocześnie pozwalając na niektóre typowe przypadki użycia między różnymi stronami (jak wejście na stronę z zewnętrznych linków).
Przykład wdrożenia:
Dla żądań AJAX mogą być dodane niestandardowe nagłówki żądań. Ze względu na ograniczenia polityki tej samej domeny, atakujący nie mogą ustawiać niestandardowych nagłówków w żądaniach między różnymi stronami. Serwer może sprawdzić obecność tego niestandardowego nagłówka, aby zweryfikować legalność żądania.
Przykład wdrożenia:
Na froncie:
Na stronie serwera:
Podwójna weryfikacja ciasteczek jest skuteczną techniką obrony przed CSRF. Jej główną zasadą jest to, że serwer generuje losowy token, ustawia go zarówno jako ciasteczko, jak i osadza na stronie (zazwyczaj jako ukryte pole formularza). Gdy przeglądarka wysyła żądanie, automatycznie dołącza ciasteczko, podczas gdy JavaScript z strony wysyła token jako parametr żądania. Serwer weryfikuje, czy token w ciasteczku pasuje do tokenu w parametrach żądania.
Chociaż atakujący mogą dołączać ciasteczko strony docelowej w żądaniach między różnymi stronami, nie mogą odczytywać ani modyfikować wartości ciasteczka, ani uzyskać dostępu do wartości tokenu na stronie. Wymagając, aby żądanie zawierało tokeny zarówno w ciasteczku, jak i parametrach, zapewnia, że żądanie pochodzi z źródła, które ma uprawnienia do odczytu ciasteczka, co skutecznie broni przed atakami CSRF.
Dla szczególnie wrażliwych operacji (jak zmiana haseł czy wykonywanie dużych przelewów) można wymagać ponownego uwierzytelnienia użytkowników. To zapewnia użytkownikom dodatkowy krok zabezpieczający. Nawet jeśli użytkownik z powodzeniem zainicjuje atak CSRF, nie może przejść kroku ponownego uwierzytelnienia.
Sugestie implementacyjne:
Dzięki tej dogłębnej dyskusji mamy nadzieję, że teraz masz bardziej wszechstronne zrozumienie ataków CSRF. Nie tylko dowiedzieliśmy się, jak działa CSRF, ale także poznaliśmy różne skuteczne środki obrony. Wszystkie te metody mogą skutecznie zwiększyć bezpieczeństwo aplikacji internetowych.
Mamy nadzieję, że ta wiedza pomoże ci lepiej radzić sobie z problemami związanymi z CSRF w codziennym rozwoju i budować bardziej bezpieczne aplikacje internetowe.