Zrozumienie ataków CSRF i blokowanie luk CSRF

Luki w zabezpieczeniach sieci są powszechne i stale rosną. Utrzymanie bezpieczeństwa i prywatności użytkowników jest ważniejsze niż kiedykolwiek. Niezajmowanie się lukami w zabezpieczeniach sieci może prowadzić do zrujnowania reputacji i wysokich kar od organów regulacyjnych, a także utraty zaufania użytkowników.

Witryny i aplikacje internetowe są podatne na złośliwe oprogramowanie, spam i inne ataki — ten artykuł skupia się na jednym z takich wektorów ataków — atakach typu Cross-Site Request Forgery (CSRF). Ataki CSRF są szczególnie niepokojące, ponieważ mogą wystąpić bez wiedzy użytkownika. Są one również trudne do wykrycia przez programistę lub właściciela witryny, ponieważ złośliwe żądania wyglądają bardzo podobnie do prawdziwych żądań.

W tym artykule omówiono atak CSRF, sposób jego działania oraz kroki, które można podjąć, aby się do niego przygotować.

Co to jest atak CSRF?

Atak Cross-Site Request Forgery, znany również jako atak CSRF, polega na nakłonieniu uwierzytelnionego użytkownika do wykonania niezamierzonych działań poprzez przesłanie złośliwych żądań bez ich wiedzy.

Zwykle atak CSRF obejmuje żądania zmiany stanu, ponieważ osoba atakująca nie otrzymuje odpowiedzi. Przykładami takich próśb są usunięcie rekordu, zmiana hasła, zakup produktu lub wysłanie wiadomości. Wszystko to może wystąpić bez wiedzy użytkownika.

Złośliwy atakujący zwykle wykorzystuje socjotechnikę, aby wysłać niczego niepodejrzewającemu użytkownikowi łącze za pośrednictwem czatu lub e-maila.

Gdy użytkownik kliknie łącze, wykonuje polecenia ustawione przez atakującego.

Na przykład kliknięcie łącza może spowodować przelanie środków z konta użytkownika. Lub może zmienić adres e-mail użytkownika, uniemożliwiając mu odzyskanie dostępu do konta.

Jak działa atak CSRF?

Nakłonienie użytkownika do zainicjowania żądania zmiany stanu po zalogowaniu jest pierwszym i najważniejszym krokiem w ataku CSRF. W przypadku ataków CSRF atakujący ma na celu skłonienie uwierzytelnionego użytkownika do nieświadomego przesłania złośliwego żądania internetowego do witryny internetowej lub aplikacji internetowej. Żądania te mogą składać się z plików cookie, parametrów adresów URL i innych typów danych, które użytkownikowi wydają się normalne.

Aby atak CSRF zakończył się sukcesem, muszą zostać spełnione następujące warunki:

• Uwierzytelniony użytkownik musi być zalogowany do aplikacji internetowej, która wykorzystuje pliki cookie do zarządzania sesją.
• Osoba atakująca musi utworzyć sfałszowane żądanie zmieniające stan.
• Oryginalne żądania obsługiwane przez serwer docelowy nie powinny zawierać nieprzewidywalnych parametrów. Na przykład żądanie nie powinno oczekiwać hasła jako parametru do celów weryfikacji przed zainicjowaniem żądania zmiany stanu.

Najczęstszą metodą przeprowadzania ataków CSRF jest używanie plików cookie w aplikacjach ze słabą polityką plików cookie SameSite. Przeglądarki internetowe włączają pliki cookie automatycznie i często anonimowo oraz zapisują pliki cookie używane przez domenę w każdym żądaniu internetowym wysyłanym przez użytkownika do tej domeny.

Zasady dotyczące plików cookie SameSite określają, w jaki sposób przeglądarka w kontekstach przeglądania między witrynami traktuje plik cookie. W przypadku ustawienia ścisłego plik cookie nie jest udostępniany w kontekstach przeglądania między witrynami, co zapobiega atakom CSRF. Przeglądarka dołącza plik cookie we wszystkich kontekstach między witrynami, jeśli jest ustawiona na brak. Naraża to aplikację na ataki CSRF.

Gdy użytkownik nieświadomie przesyła złośliwe żądanie za pośrednictwem przeglądarki internetowej, zapisane pliki cookie powodują, że żądanie wydaje się uzasadnione na serwerze. Serwer następnie odpowiada na żądanie, zmieniając konto użytkownika, zmieniając stan sesji lub zwracając żądane dane.

Przyjrzyjmy się bliżej dwóm przykładom ataków CSRF, jednym z żądaniem GET, a drugim z żądaniem POST.

CSRF dla żądania GET

Najpierw rozważ żądanie GET używane przez aplikację internetową bankowości finansowej, w przypadku której atak wykorzystuje żądanie GET i dostarczenie hiperłącza.

Załóżmy, że żądanie GET dotyczące przelewu pieniędzy wygląda mniej więcej tak:

 GET https://xymbank.com/online/transfer?amount=1000&accountNumber=547895 HTTP/1.1

W powyższej autentycznej prośbie użytkownik żąda przelania 1000 USD na konto z 547895 jako zapłatę za zakupione produkty.

Chociaż ta prośba jest wyraźna, prosta i praktyczna, naraża posiadacza konta na atak CSRF. To dlatego, że żądanie nie wymaga szczegółów, których osoba atakująca może nie znać. Tak więc, aby zainicjować atak, osoba atakująca musiałaby jedynie zmienić parametry tego żądania (kwota i numer konta), aby utworzyć wykonywalne sfałszowane żądanie.

Złośliwa prośba byłaby skuteczna wobec każdego użytkownika banku, o ile ma on trwające sesje zarządzane przez pliki cookie.

Oto jak wyglądałoby sfałszowane żądanie przelania 500 $ na konto hakera (tutaj numer 654585 ). Zauważ, że poniższy przykład jest bardzo uproszczoną wersją kroków związanych z atakiem CSRF dla wyjaśnienia.

 GET https://xymbank.com/online/transfer?amount=500&accountNumber=654585 HTTP/1.1

Po zakończeniu ataku atakujący musi wymyślić sposób nakłonienia użytkownika do wysłania tego żądania po zalogowaniu się do aplikacji bankowości internetowej. Jednym ze sposobów na to jest utworzenie nieszkodliwego hiperłącza, które przyciągnie uwagę użytkownika. Link może wyglądać tak:

 <a href="https://xymbank.com/online/transfer?amount=500&accountNumber=654585">Click here to get more information</a>.

Biorąc pod uwagę, że atakujący znalazł prawidłowe adresy e-mail swoich celów, może wysłać je pocztą e-mail do wielu klientów banków. Ci, którzy klikną link podczas logowania, wywołają żądanie wysłania atakującemu 500 $ z zalogowanego konta.

CSRF dla żądania POST

Zobaczmy, jak ta sama instytucja finansowa doświadczyłaby CSRF, gdyby akceptowała tylko żądania POST. W takim przypadku dostarczenie hiperłącza użyte w przykładzie żądania GET nie zadziałałoby. Dlatego pomyślny atak CSRF wymagałby od osoby atakującej utworzenia formularza HTML. Prawdziwa prośba o przesłanie 1000 USD za zakupiony produkt wyglądałaby tak:

 POST /online/transfer HTTP/1.1 Host: xymbank.com Content-Type: application/x-www-form-urlencoded Cookie: session=FRyhityeQkAPzeQ5gHgTvlyxHJYhg amount=1000 account=547895

To żądanie POST wymaga pliku cookie w celu określenia tożsamości użytkownika, kwoty, którą chce wysłać, oraz konta, które chce wysłać. Atakujący mogą zmienić to żądanie, aby przeprowadzić atak CSRF.

Atakujący musi tylko dodać prawdziwy plik cookie do sfałszowanego żądania, aby serwer przetworzył transfer. Mogą to zrobić, tworząc nieszkodliwie wyglądające hiperłącze, które prowadzi użytkownika do wyzwalającej strony internetowej, która wygląda tak:

 <html> <body> <form action="https://xymbank.com/online/transfer" method="POST"> <input type="hidden" name="amount" value="500"/> <input type="hidden" name="account" value="654585" /> </form> <script> document.forms[0].submit(); </script> </body> </html>

W powyższym formularzu ustawiliśmy już parametry kwoty i rachunku. Gdy uwierzytelniony użytkownik odwiedzi stronę, przeglądarka dodaje sesyjny plik cookie przed przekazaniem żądania do serwera. Następnie serwer przekazuje 500 $ na konto hakera.

3 sposoby na powstrzymanie ataków CSRF

Istnieje kilka metod zapobiegania i drastycznego łagodzenia potencjalnych ataków CSRF na Twoją witrynę lub aplikację internetową, w tym:

• Korzystanie z tokenów CSRF
• Korzystanie z nagłówka strony odsyłającej
• Wybór rozwiązania hostingowego skoncentrowanego na bezpieczeństwie, takiego jak Kinsta

Jak zapobiegać atakom CSRF za pomocą tokenów CSRF

Witryna zabezpieczona CSRF przypisuje każdej sesji unikalny token i udostępnia go stronie serwera i przeglądarce klienta. Za każdym razem, gdy przeglądarka wysyła poufne żądanie, serwer oczekuje, że będzie ono zawierało przypisany token CSRF. Jeśli ma niewłaściwy token, serwer go odrzuca. Token CSRF nie jest przechowywany w sesyjnych plikach cookie w przeglądarce klienta ze względów bezpieczeństwa.

Potencjalne luki w zabezpieczeniach tokenów CSRF

Chociaż tokeny CSRF są doskonałym środkiem bezpieczeństwa, ta metoda nie jest odporna na ataki. Niektóre luki towarzyszące tokenom CSRF obejmują:

• Pominięcie sprawdzania poprawności — niektóre aplikacje pomijają etap weryfikacji, jeśli nie znajdą tokena. Jeśli atakujący uzyska dostęp do kodu zawierającego token, może go usunąć i pomyślnie przeprowadzić atak CSRF. Jeśli więc prawidłowe żądanie do serwera wygląda tak:

 POST /change_password POST body: password=pass123&csrf_token=93j9d8eckke20d433

Atakujący musi tylko usunąć token i wysłać go w następujący sposób, aby przeprowadzić atak:

 POST /change_password POST body: password=pass123

• Tokeny w puli — niektóre aplikacje utrzymują pulę tokenów w celu sprawdzania poprawności sesji użytkowników zamiast wyznaczania konkretnego tokena do sesji. Osoba atakująca musi tylko zdobyć jeden z tokenów znajdujących się już w puli, aby podszyć się pod dowolnego użytkownika witryny.

Osoba atakująca może zalogować się do aplikacji przy użyciu swojego konta w celu uzyskania tokena, takiego jak:

 [application_url].com?csrf_token=93j9d8eckke20d433

A ponieważ tokeny są połączone, atakujący może skopiować i użyć tego samego tokena do zalogowania się na konto innego użytkownika, ponieważ użyjesz go ponownie:

• CSRF można skopiować do pliku cookie — niektóre aplikacje kopiują parametry związane z tokenem do pliku cookie użytkownika. Jeśli atakujący uzyska dostęp do takiego pliku cookie, może łatwo utworzyć kolejny plik cookie, umieścić go w przeglądarce i przeprowadzić atak CSRF.

Tak więc osoba atakująca może zalogować się do aplikacji przy użyciu swojego konta i otworzyć plik cookie, aby zobaczyć:

 Csrf_token:93j9d8eckke20d433

Następnie mogą wykorzystać te informacje do utworzenia kolejnego pliku cookie w celu zakończenia ataku

• Nieprawidłowe tokeny — niektóre aplikacje nie dopasowują tokenów CSRF do sesji użytkownika. W takich przypadkach osoba atakująca może rzeczywiście zalogować się do sesji, uzyskać token CSRF podobny do powyższego i użyć go do zaaranżowania ataku CSRF na sesję ofiary.

Jak zapobiegać atakom CSRF za pomocą nagłówka strony odsyłającej

Inną strategią zapobiegania atakom CSRF jest użycie nagłówka strony odsyłającej. W HTTP nagłówki odsyłające wskazują pochodzenie żądań. Są one zwykle używane do przeprowadzania analiz, optymalizacji i rejestrowania.

Możesz także włączyć sprawdzanie nagłówków stron odsyłających po stronie serwera, aby zapobiec atakom CSRF. Po stronie serwera sprawdza źródłowe źródło żądania i określa docelowe źródło żądania. Jeśli są zgodne, żądanie jest dozwolone. W przypadku niezgodności serwer odrzuca żądanie.

Korzystanie z nagłówków odsyłaczy jest znacznie łatwiejsze niż używanie tokenów, ponieważ nie wymaga indywidualnej identyfikacji użytkownika.

Potencjalne luki w nagłówku strony odsyłającej

Podobnie jak tokeny CSRF, nagłówki stron odsyłających mają pewne znaczące luki.

Po pierwsze, nagłówki stron odsyłających nie są obowiązkowe, a niektóre witryny wysyłają żądania bez nich. Jeśli CSRF nie ma zasad obsługi żądań bez nagłówków, osoby atakujące mogą używać żądań bez nagłówków do wykonywania ataków zmieniających stan.

Ponadto ta metoda stała się mniej skuteczna wraz z niedawnym wprowadzeniem polityki odsyłaczy. Ta specyfikacja zapobiega wyciekom adresów URL do innych domen, dając użytkownikom większą kontrolę nad informacjami w nagłówku strony odsyłającej. Mogą ujawnić część informacji nagłówka strony odsyłającej lub wyłączyć ją, dodając tag metadanych na stronie HTML, jak pokazano poniżej:

 <meta name="referrer" content="no-referrer">

Powyższy kod usuwa nagłówek strony odsyłającej dla wszystkich żądań z tej strony. Utrudnia to aplikacjom, które opierają się na nagłówkach odsyłających, zapobieganie atakom CSRF z takiej strony.

Jak Kinsta chroni przed atakami CSRF

Oprócz korzystania z nagłówka strony odsyłającej i tokenów CSRF, istnieje trzecia i znacznie łatwiejsza opcja: wybranie bezpiecznej usługi hostingowej, takiej jak Kinsta, dla twoich stron internetowych i aplikacji internetowych zapewnia znacznie silniejszą i bezpieczniejszą barierę między atakującymi a użytkownikami.

Oprócz krytycznych funkcji bezpieczeństwa, takich jak automatyczne tworzenie kopii zapasowych, uwierzytelnianie dwuskładnikowe i SFTP przez protokoły SSH, integracja Cloudflare firmy Kinsta zapewnia ochronę na poziomie przedsiębiorstwa dzięki ochronie opartej na protokole IP i zaporze ogniowej.

W szczególności Kinsta ma obecnie około 60 niestandardowych reguł zapory ogniowej, które pomagają zapobiegać złośliwym atakom i radzić sobie z poważnymi nieuwierzytelnionymi lukami w zabezpieczeniach wtyczek i motywów, w tym określonymi, które szukają luk CSRF.

Streszczenie

Fałszowanie żądań między witrynami (CSRF) to atak, który nakłania uwierzytelnionych użytkowników do niezamierzonego inicjowania żądań zmieniających stan. Ich celem są aplikacje, które nie rozróżniają prawidłowych i sfałszowanych żądań zmiany stanu.

CSRF może odnieść sukces tylko w aplikacjach, które opierają się na plikach cookie sesji w celu identyfikacji zalogowanych użytkowników i mają słabą politykę plików cookie SameSite. Potrzebują również serwera, który przyjmuje żądania niezawierające nieznanych parametrów, takich jak hasła. Hakerzy mogą wysyłać złośliwe ataki za pomocą GET lub POST.

Chociaż używanie tokenów CSRF lub wymuszanie weryfikacji nagłówka strony odsyłającej może zapobiec niektórym atakom CSRF, oba środki mają potencjalne luki w zabezpieczeniach, które mogą sprawić, że środki zapobiegawcze będą bezużyteczne, jeśli nie będziesz ostrożny.

Migracja do bezpiecznej platformy hostingowej, takiej jak Kinsta, zabezpiecza Twoje strony internetowe lub aplikacje internetowe przed atakami CSRF. Ponadto integracja Kinsta z Cloudflare zapobiega określonym atakom CSRF.