Ciasteczka jako zagrożenie: Cross-Site Request Forgery

Tobias Schüring Ostatnia aktualizacja 21.01.2020
.
. 7 Min.
Ataki typu Cross-Site Request Forgery (CSRF) na stronie WordPress  należą do najstarszych ataków ze wszystkich.

CSRF, skrót ten pojawia się raz po raz w aktualizacjach bezpieczeństwa i konserwacji rdzenia WordPress . Metoda, która za tym stoi, jest już stara jak świat i wykorzystuje obfitość plików cookie użytkownika Internetu. Na szczęście jednak, można dość łatwo zabezpieczyć się przed cross-site request forgery. Wszystko, czego potrzebujesz, to trochę czasu i uwagi.

Prawdopodobnie korzystasz również z wielu serwisów, które oferują możliwość pozostania zalogowanym nawet po opuszczeniu strony. Jeśli następnie ponownie odwiedzisz tę stronę, nie będziesz musiał ponownie podawać swoich danych logowania, lecz zostaniesz bezpośrednio zalogowany. Dla użytkownika jest to oczywiście świetne rozwiązanie, ponieważ - podobnie jak zarządzanie hasłami lub tak zwany Single Sign On - oszczędza irytującego wypełniania formularzy.

W tle zachodzą następujące procesy: Podczas pierwszego logowania na stronie internetowej, strona zapisuje w przeglądarce plik cookie. Jest to mały plik tekstowy, w którym mogą być przechowywane pewne informacje. W przypadku pozostania zalogowanym jest to losowo wygenerowany ciąg znaków.

Przy następnej wizycie na stronie, serwer sprawdza ten ciąg znaków i jeśli znajdzie odpowiadający mu odpowiednik, loguje Cię automatycznie. Jest to również powód, dla którego jesteś wylogowany wszędzie, gdy wyczyścisz pamięć podręczną przeglądarki. Ponieważ wszystkie pliki cookie są również usuwane podczas tego procesu.

Atak CSRF jest w swej istocie nadużyciem zaufania.

Jak widać, w odpowiednim ataku atakujący oszukuje usługę, która odczytuje ciasteczka, aby w coś uwierzyła. Jak dokładnie to się dzieje, wyjaśniam poniżej na dwóch przykładach.

Niebezpieczeństwo tej manipulacji polega na tym, że osoba trzecia, czyli atakujący, dokonuje zmian w Twoim profilu na Facebooku np. w Twoim imieniu. Jednak cross-site request forgery jest często uzależnione od phishingu. Również tutaj istotne staje się zaufanie - a mianowicie zaufanie do np. nadawców e-maili.

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

Jak wrażliwa jest strona WordPress ?

Prawdopodobnie nie słyszałeś jeszcze terminu Cross-Site Request Forgery tak często jak Brute Force ataki lub skrypty krzyżowe (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 webowych. Na wstępnej liście na 2017r. CSRF zajmuje 8 miejsce na 10. W 2007 i 2010 roku atak ten lądował jeszcze na 5 miejscu, W 2013 roku spadł na ósme miejsce. zszedł.

Wynika to prawdopodobnie po części z faktu, że ataki CSRF są niemal tak stare jak sam Internet. Profesjonalni programiści są obecnie dobrze wyćwiczeni w zabezpieczaniu przed nimi swojego kodu. Tak więc zagrożenia bezpieczeństwa są dość łatwe i szybkie do naprawienia.

WordPress jest również na celowniku. Na przykład, w maju wydano aktualizację bezpieczeństwa 4.7.5, która naprawiła sześć luk, które hakerzy mogli wykorzystać do przeprowadzenia ataku poprzez cross-site scripting lub cross-site request forgery. Często Cross-site scripting jest często uważany za znacznie bardziej niebezpieczny.

Co więcej, problem cross-site request forgery jest zwykle bardziej istotny dla Plugin- i twórców aplikacji niż dla projektantów stron internetowych, agencji i MŚP. Dzieje się tak dlatego, że ochrona przed CSRF jest również kwestią programowania. CSRF może stać się istotny na przykład w przypadku zakupów na stroniePlugin.

Ale jak to wszystko działa teraz?

Anatomia zjawiska Cross-Site Request Forgery

Podstawowa idea ataku CSRF jest stosunkowo prosta i zazwyczaj przebiega w dwóch krokach:

  1. Haker oszukuje ofiarę, aby załadowała zmanipulowaną stronę lub kliknęła na link, na przykład podając się za zaufaną osobę lub wykorzystując ludzką ciekawość. Innymi słowy, phishing odgrywa istotną rolę w tego typu atakach.
  2. Kiedy zmanipulowane linki lub strony są ładowane lub klikane, przeglądarka ofiary wykonuje żądanie HTTP bez jej wiedzy.

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

W tym celu załóżmy, że Justus chce wysłać do Boba wiadomość za pośrednictwem strony www.bank.de 100€, a Skinny czeka, aby przeprowadzić atak CSRF. Skinny może teraz użyć do swojego ataku na przykład metody GET lub POST.

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

Cross-Site Request Forgery z wykorzystaniem metody GET

Metoda GET jest stosowana do żądania zasobu z serwera, np. pliku HTML. Parametry wymagane do wywołania są po prostu dołączane do adresu URL. A jak już wiemy z SQL injections: Adres URL jest stosunkowo łatwy do manipulowania.

Justus loguje się więc pod adresem www.bank.de i wprowadza wszystkie niezbędne dane. Następujące (całkowicie fikcyjne) dane wejściowe zostałyby przesłane do serwera:

GET http://bank.de/transfer.do?acct=BOB&betrag=100 HTTP/1.1

Skinny konstruuje teraz adres URL, który zamiast tego przelewa 100 000 € na jego własne konto. Wygląda to tak:

http://bank.de/transfer.do?acct=SKINNY&betrag=100000

Oczywiście, Justus musi wykonać akcję ukrytą za fałszywym linkiem. W związku z tym Skinny wysyła Justusowi maila z fałszywym linkiem. Kod HTML może wyglądać na przykład tak:

">Kto nie potrafi rozwiązać tej zagadki, nie jest prawdziwym detektywem!

Albo wysyła mu maila, który zawiera "niewidzialny" (bo 0 na 0 pikseli) obrazek. Podczas próby załadowania obrazu, przeglądarka uzyskuje dostęp do adresu URL, a Justus nawet tego nie zauważa:

Kiedy Justus - świadomie lub nieświadomie - wywołuje link, parametry są przekazywane do serwera, przelew zostaje uruchomiony i 100 000€ znika z jego konta.

Oczywiście, Justus musi kliknąć na link będąc zalogowanym. Ale jeśli, niestety, w jego przeglądarce znajduje się plik cookie logowania z jego banku atak działa nawet jeśli nie otworzył on strony.

To właśnie to sprawia, że cross-site request forgery jest tak podstępne: ofiara może nawet nie być świadoma istnienia ciasteczka.

Cross-Site Request Forgery z metodą POST

Metoda GET może być stosowana w linkach i dzięki temu jest szczególnie łatwa do rozpowszechniania. To naturalnie sprzyja atakującemu w kwestii dystrybucji. Teraz jednak dostawcy mogą zapewnić, że żądania GET z zasady nie otrzymują uprawnień do zapisu.

Pozostaje metoda POST: Tutaj dane są przekazywane do serwera, aby ten mógł je dalej przetwarzać. Dane te nie są częścią adresu URL, ale są dołączane do nagłówka.

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

Dla naszego napastnika, Chudego, oznacza to, że musi włożyć więcej wysiłku, ale nadal może dotrzeć tam, gdzie zmierza.

Ten sam scenariusz: Justus chce przekazać pieniądze Bobowi. Więc on napełnia www.bank.de i wypełnia poniższy formularz:

<formularz metoda="POST" działanie="money_transfer.php">

    <wejście typ="tekst" nazwa="od">

    <wejście typ="tekst" nazwa="an">

    <wejście typ="tekst" nazwa="amount_in_euro">

    <wejście typ="złożyć">

formularz>

To powoduje wysłanie polecenia money_transfer.php, które wygląda tak:

if(isset($_FORM["von"]) && isset($_FORM["an"]) &&isset($_FORM["menge_in_euro"]) && isset($_CMOKIE["user_eingeloggt"]))

{

    transMoney("von", "an", "betrag");

    echo "Überweisung erfolgreich!";

}

Jak widać, kod najpierw sprawdza, czy Justus jest zalogowany za pomocą cookie. Tylko wtedy, gdy tak się stanie, transfer zostanie wykonany.

Skinny umieszcza teraz niewidoczny formularz na zmanipulowanej stronie internetowej, np.

<formularz metoda="POST" działanie="http://www.bank.de/geld_ueberweisen.php">

    <wejście typ="tekst" nazwa="od" wartość="Justus" styl="display: hidden">

    <wejście typ="tekst" nazwa="an" wartość="chudy" styl="display: hidden">

    <wejście typ="tekst" nazwa="amount_in_euro" wartość="100000" styl="display: hidden">

    <wejście typ="złożyć" wartość="Każdy, kto nie potrafi rozwiązać tej zagadki, nie jest prawdziwym detektywem!">

formularz>

Przesyła Justusowi link do tej zmanipulowanej strony. Czuje się wyzwany, klika na przycisk, aby zobaczyć zagadkę, i nieświadomie uruchamia funkcję geld_ueberweisen.php. Ponieważ w jego przeglądarce znajduje się odpowiedni plik cookie, 100 000€ zostaje ponownie przekazane do Skinny'ego.

Atak poprzez objazdy

Dlatego też nazwa CrossSite Request Forgery: Haker zazwyczaj wysyła komendę z innej strony. W celu zaatakowania strony A, umieszcza złośliwy kod na stronie B. Następnie zwabia niczego nie podejrzewającego użytkownika tutaj, aby jego przeglądarka wykonała kod.

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

Jak zabezpieczyć się przed atakami CSRF

Dobra wiadomość jest taka, że cross-site request forgery jest znane od wieków. Deweloperzy znają to ryzyko i pracują specjalnie nad jego wyeliminowaniem.

Zła wiadomość jest taka, że nie można się przed tym zabezpieczyć od strony technicznej. Rdzeń WordPress jest obecnie stosunkowo dobrze chroniony, a jak widać po bieżących aktualizacjach, prace nad nim są stale prowadzone. Podobnie jak w przypadku innych rodzajów ataków, większość podatności jest dostępna pod adresem Plugins . Musisz więc zaufać, że twórcy rozszerzeń, których używasz, wykonują dobrą robotę.

To znaczy konkretnie:

  • Nie instaluj zbyt wielu Plugins i instaluj tylko te Plugins, których naprawdę potrzebujesz.
  • Uważaj na Plugins, który nie był aktualizowany przez deweloperów od jakiegoś czasu. Mogą tu być ukryte niezałatane luki w zabezpieczeniach.
  • Sprawdź kompatybilność instalowanego Plugins z innymi Plugins lub z używaną wersją WordPress (aby można było zaktualizować Plugin ).
  • Regularnie aktualizuj swoją stronę Plugins i rdzeń WP. Ponieważ ciągłe aktualizacje są właśnie po to, aby usuwać takie luki w zabezpieczeniach.
  • Jesteś krytyczny w kwestii phishingu
  • Jeśli nie jesteś pewien, przyjrzyj się dokładnie Plugin w repozytorium WP. Jakie są oceny, jakie były największe problemy w przeszłości i czy Plugin nie załatał jakiejś wybitnej dziury w zabezpieczeniach?

Wniosek: CSRF to stary kapelusz

Cross-site request forgery jest znane od początku ery cyfrowej. Ponadto, liczba przypadków jest niezwykle mała w porównaniu np. z atakamiBrute Force .

Potwierdza to również ocena OWASP, że atak jest raczej niskoprofilowy, łatwy do wykrycia i poważny tylko w niektórych specyficznych przypadkach. sprawy.

Niemniej jednak dobrze jest wiedzieć, jak działają te ataki. Ponieważ ataki często udają się tylko dzięki ludzkim błędom. Wielokrotnie zdarza się, że użytkownicy otwierają maile z ciekawości lub klikają w linki, których lepiej byłoby nie otwierać.

Tak więc, niezależnie od tego, czy jesteś użytkownikiem, czy użytkownikiem końcowym, najlepszym sposobem na ochronę przed cross-site request forgery są badania i odrobina zdrowego rozsądku.

Jako administrator systemu Tobiasz czuwa nad naszą infrastrukturą i znajduje każdą śrubkę, aby zoptymalizować wydajność naszych serwerów. Dzięki jego niestrudzonym wysiłkom, często można go spotkać w nocy na stronie Slack .

Powiązane artykuły

Komentarze do tego artykułu

Napisz komentarz

Twój adres e-mail nie zostanie opublikowany. Pola obowiązkowe oznaczone są *.