Ciasteczka jako zagrożenie: Cross-Site Request Forgery

Tobias Schüring Aktualizacja w dniu 21.01.2020 r.
7 Min.
Ataki Cross-Site Request Forgery (CSRF) WordPress są jednymi z najstarszych ataków w historii.

CSRF, skrót ten pojawia się wielokrotnie w aktualizacjach dotyczących bezpieczeństwa i konserwacji WordPress -Core. Metoda, która się za tym kryje, to teraz stary kapelusz, wykorzystujący obfitość plików cookie użytkownika Internetu. Na szczęście dość łatwo jest chronić się przed Cross-Site Request Forgery. Wszystko czego potrzebujesz to trochę czasu i uwagi.

Prawdopodobnie korzystasz również z wielu usług, w których istnieje możliwość pozostania zalogowanym nawet po opuszczeniu strony. Jeśli następnie ponownie odwiedzisz stronę, nie będziesz musiał ponownie podawać swoich danych do logowania, ale będziesz bezpośrednio zalogowany. Jest to oczywiście wspaniałe dla użytkownika, ponieważ jest to - podobnie jak zarządzanie hasłami lub tzw. Pojedynczy sygnał włączenia - męczące wypełnianie formularzy.

W tle pojawiają się następujące informacje: Podczas pierwszego logowania się na stronie internetowej, strona zapisuje plik cookie w przeglądarce. Jest to mały plik tekstowy, w którym można przechowywać pewne informacje. Jeśli jesteś zalogowany, jest to losowo wygenerowany łańcuch znaków.

Przy następnej wizycie na stronie internetowej, serwer sprawdza ten ciąg znaków i jeśli znajdzie odpowiedni odpowiednik, loguje się automatycznie. To jest również powód, dla którego będziesz wylogowany wszędzie, kiedy będziesz używał swojego Skrytka przeglądarki Pusty. Wynika to z faktu, że w trakcie tego procesu wszystkie pliki cookie są usuwane.

Atak CSRF jest zasadniczo nadużyciem zaufania.

Już zauważyłeś: W odpowiednim ataku napastnik podaje coś do serwisu, który odczytuje pliki cookie. Jak dokładnie to się dzieje, wyjaśniono poniżej na dwóch przykładach.

Niebezpieczeństwo tej manipulacji polega na tym, że osoba trzecia, tj. napastnik, dokonuje zmian na Twoim profilu na Facebooku, na przykład w Twoim imieniu. Fałszerstwa typu Cross-Site Request Forgery są jednak często również uzależnione od phishingu. Także tutaj zaufanie staje się istotne - a mianowicie zaufanie do nadawcy np. e-maili.

Atakom na WordPress Cross Site Request Forgery (CSRF) można zapobiec dzięki zdrowemu rozsądkowi.

Jak bardzo jest zagrożonyWordPress ?

Prawdopodobnie nie słyszałeś terminu Cross-Site Request Forgery tak często jak Brute Force Ataki czy cross-site scripting. Jest ku temu powód: organizacja non-profit OWASP (Open Web Application Security Project) regularnie publikuje listę dziesięciu najbardziej krytycznych luk w aplikacjach internetowych. Na wstępny wykaz na 2017 r. CSRF zajmuje 8. miejsce na 10. W 2007 i 2010 r. atak nadal lądował na 5. miejscu, W 2013 roku awansował na 8. miejsce Odjazd.

Jednym z powodów jest prawdopodobnie fakt, że ataki CSRF są prawie tak stare jak sam Internet. Profesjonalni programiści są teraz w stanie zabezpieczyć swój kod przed nimi. Ryzyko związane z bezpieczeństwem jest więc łatwo i szybko usuwane.

Z WordPress jednym jest też na straży. Na przykład, aktualizacja bezpieczeństwa 4.7.5 została wydana w maju, która naprawiła sześć luk, które mogły zostać wykorzystane przez hakerów do przeprowadzenia ataku poprzez cross-site scripting lub cross-site request forgery. Często aczkolwiek cross-site scripting jest uważany za znacznie bardziej niebezpieczny.

Ponadto kwestia fałszerstw typu "Cross-Site Request Forgery" dotyczy raczej Plugin- i twórców aplikacji niż dla projektantów stron internetowych, agencji i MŚP. Ponieważ ochrona przed CSRF jest również kwestią programowania. CSRF mogą być istotne na przykład w przypadku in-Plugin-zostanie kupiony.

Ale jak to wszystko działa teraz?

Anatomia Cross-Site Request Forgery

Podstawowa idea ataku CSRF jest stosunkowo prosta i zazwyczaj odbywa się w dwóch etapach:

  1. Haker sprawia, że ofiara ładuje manipulowaną stronę lub klika na link, na przykład udając zaufaną osobę lub wykorzystując ludzką ciekawość. Innymi słowy, phishing odgrywa ważną rolę w tego typu atakach.
  2. Podczas ładowania lub klikania manipulowanych linków lub stron, przeglądarka ofiary wykonuje żądanie HTTP bez zauważania ofiary.

Dwa stosunkowo proste przykłady ilustrują jak taki atak działa.

Powiedzmy, że Justus chce przekonać Boba. www.bank.de Przelej 100 euro, a Skinny będzie czekał na atak CSRF. Skinny może teraz użyć metody GET lub POST do swojego ataku.

Przy okazji, poniższe przykłady pochodzą z następujących źródeł:

Cross-Site Request Forgery w metodzie GET

Metoda GET jest używana do żądania zasobów z serwera, np. pliku HTML. Parametry wymagane dla danego połączenia są po prostu dodawane do adresu URL. I jak już usłyszeliśmy od SQL Injections Wiem: Adres URL jest stosunkowo łatwy do manipulowania.

Więc Justus loguje się na www.bank.de i wprowadza wszystkie wymagane dane. Następne (całkowicie fikcyjne) wejście zostanie przesłane do serwera:

GET http://bank.de/transfer.do?acct=BOBetrag=100 HTTP/1.1

Skinny buduje teraz adres URL, który zamiast tego przelewa 100.000€ na swoje własne konto. Na to wygląda:

http://bank.de/transfer.do?acct=SKINNYetrag=100000

Oczywiście Justus musi wykonać akcję, która jest ukryta za fałszywym łączem. Dlatego Skinny wysyła Justusowi pocztę z fałszywym linkiem. Kod HTML może na przykład tak wyglądać:

"Ktokolwiek nie potrafi rozwiązać tej tajemnicy, nie jest prawdziwym detektywem!

Albo wysyła mu maila zawierającego "niewidzialny" (bo 0 na 0 pikseli) obraz. Przy próbie załadowania obrazu, przeglądarka uzyskuje dostęp do adresu URL, nie zauważając nawet Justusa:

Kiedy Justus wywołuje link - świadomie lub nieświadomie - parametry są przekazywane do serwera, przelew jest inicjowany i 100.000 € znika z jego konta.

Oczywiście Justus musi kliknąć na link, gdy jest zalogowany. Ale jeśli niestety w jego przeglądarce znajduje się cookie logowania do jego banku atak działa nawet jeśli w tym czasie nie otworzył strony.

Właśnie to sprawia, że Cross-Site Request Forgery jest tak podstępne: poszkodowany może nawet nie wiedzieć, że plik cookie istnieje.

Cross-Site Request Forgery w metodzie POST

Metoda GET może być stosowana w linkach i dlatego jest szczególnie łatwa do rozpowszechniania. To oczywiście gra w ręce napastnika pod względem dystrybucji. Teraz jednak dostawcy mogą zapewnić, że żądania GET nie będą otrzymywać zgody na piśmie.

Pozostaje metoda POST: Tutaj dane są przenoszone na serwer, aby mogły być dalej przetwarzane. Dane te nie są jednak częścią adresu URL, lecz są dołączane do nagłówka.

Może to zabrzmieć trochę nieporęcznie, ale na pewno znasz przypadek użycia. Ponieważ formularze działają w ten sposób.

Dla naszego napastnika, Skinny'ego, oznacza to, że choć musi się bardziej starać, to jednak może osiągnąć swój cel.

Ten sam scenariusz: Justus chce przelać pieniądze na Boba. Więc wypełnia się www.bank.com w następującym formularzu:

<Formularz Metoda="POST" Działanie="wire_transfer.php">

    <Dane wejściowe Typ="tekst" Imię="przez">

    <Dane wejściowe Typ="tekst" Imię="na">

    <Dane wejściowe Typ="tekst" Imię="kwota_w_euro">

    <Dane wejściowe Typ="poddać się">

Formularz>

To wysyła polecenie geld_ueberweisen.php, które wygląda jak to

jeśli(iSSet($_FORM["przez"]) && iSSet($_FORM["na"]) &&iSSet($_FORM["crowd_in_euro"]) && iSSet($_CMOKIE["user_logged in"]))

{

    transMoney("przez", "na", "kwota");

    echo "Transfer udany!";

}

Jak widać, kod najpierw sprawdza, czy Justus jest zalogowany za pomocą cookie. Tylko wtedy, gdy on jest, przelew jest wykonywany.

Skinny umieszcza teraz niewidoczną formę na manipulowanej stronie internetowej, np.

<Formularz Metoda="POST" Działanie="http://www.bank.de/geld_ueberweisen.php">

    <Dane wejściowe Typ="tekst" Imię="przez" Wartość="Justus" Styl="wyświetlacz: ukryty">

    <Dane wejściowe Typ="tekst" Imię="na" Wartość="Chudy" Styl="wyświetlacz: ukryty">

    <Dane wejściowe Typ="tekst" Imię="kwota_w_euro" Wartość="100000" Styl="wyświetlacz: ukryty">

    <Dane wejściowe Typ="poddać się" Wartość="Ten, kto nie potrafi rozwiązać tej tajemnicy, nie jest prawdziwym detektywem!">

Formularz>

Wysyła link do tej zmanipulowanej strony do Justusa. Czując się zagrożony, klika przycisk, aby zobaczyć puzzle; i nieświadomie wykonuje funkcję geld_ueberweisen.php. Ponieważ w jego przeglądarce znajduje się odpowiedni plik cookie, 100.000 € zostaje ponownie przeniesione do Skinny'ego.

atak podstępnymi metodami

Stąd nazwa Krzyż-Site Request Forgery: Haker zazwyczaj wysyła polecenie z innej strony. Aby zaatakować stronę A, umieszcza więc złośliwy kod na stronie B. Następnie wabi tu niczego niepodejrzewającego użytkownika, aby jego przeglądarka mogła wykonać kod.

Jak bardzo niebezpieczne są ataki Cross Site Request Forgery (CSRF)WordPress ?

Jak chronić się przed atakami CSRF

Dobra wiadomość: Cross-Site Request Forgery istnieje od wieków. Deweloperzy znają ryzyko i ciężko pracują, aby je wyeliminować.

Zła wiadomość jest taka, że od strony technicznej nie można się przed nią naprawdę zabezpieczyć. System WordPress -Core jest obecnie stosunkowo dobrze chroniony i jak widać na podstawie bieżących aktualizacji, jest on stale rozwijany. Podobnie jak w przypadku innych rodzajów ataków, większość słabych punktów pochodzi z Pluginstego typu ataków. Musisz więc ufać, że twórcy rozszerzeń, których używasz, wykonują dobrą robotę.

To znaczy konkretnie:

  • Nie należy instalować zbyt wielu Plugins i tylko Pluginsże naprawdę potrzebujesz
  • Uważajcie na Pluginste, które nie były aktualizowane przez deweloperów od dłuższego czasu. Nierozwiązane luki w zabezpieczeniach mogą być tu ukryte.
  • Dowiedz się o Pluginsktóre instalujesz, na przykład, o ich kompatybilności z innymi Plugins lub WordPress wersji, której używasz (aby można było ją Pluginzaktualizować).
  • Regularnie aktualizuj swoje Pluginsi WP-Core. Ponieważ ciągłe aktualizacje są dokładnie tam, gdzie można zamknąć takie luki w zabezpieczeniach.
  • Jesteś krytyczny wobec phishingu
  • Jeśli nie jesteś pewna, spójrz. Plugin w repozytorium WP. Jakie są ratingi, jakie były największe problemy w przeszłości, i zrobił Plugin może nie udało się zamknąć poważnego naruszenia bezpieczeństwa?

Wniosek: CSRF to stary kapelusz

Cross-Site Request Forgery istnieje praktycznie od początku ery cyfrowej. Ponadto liczba spraw wzrosła w porównaniu z np. Brute Force Ataki niezwykle mały.

To również potwierdza ocena OWASPZakłada się, że atak ma raczej małą skalę, jest łatwy do wykrycia i poważny tylko w bardzo szczególnych przypadkach. jest.

Mimo to, dobrze jest wiedzieć, jak działają ataki. Bo często ataki działają tylko dzięki ludzkiemu błędowi. Raz za razem użytkownicy z ciekawości otwierają maile lub klikają na linki, których nie powinni byli otwierać.

Zatem niezależnie od tego, czy jesteś użytkownikiem, czy też użytkownikiem, najlepszym sposobem na ochronę przed Cross-Site Request Forgery jest przeprowadzenie pewnych badań i zastosowanie odrobiny zdrowego rozsądku.

Jako administrator systemu Tobias czuwa nad naszą infrastrukturą i znajduje wszelkie możliwe sposoby na optymalizację wydajności naszych serwerów. Dzięki jego niestrudzonym wysiłkom często można go Slack znaleźć w nocy.

Artykuły pokrewne

Komentarze do tego artykułu

Napisz komentarz

Twój adres e-mail nie zostanie opublikowany. Wymagane pola oznaczone są * Zaznaczone.