Ataki typu cross-site request forgery (CSRF) na WordPress są jednymi z najstarszych ataków ze wszystkich.

Ciasteczka jako zagrożenie: Cross-Site Request Forgery

CSRF, ten skrót pojawia się raz po raz w aktualizacjach bezpieczeństwa i konserwacji rdzenia WordPressa. Metoda za nim jest teraz stary kapelusz i wykorzystuje obfite pliki 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.

Z pewnością korzystasz 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. Jest to oczywiście świetne rozwiązanie dla użytkownika, ponieważ - podobnie jak zarządzanie hasłami czy tzw. pojedyncze logowanie - oszczędza konieczności wypełniania formularzy.

W tle zachodzą następujące procesy: podczas pierwszego logowania na stronie internetowej, strona umieszcza 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. To jest również powód, dla którego jesteś wylogowany wszędzie, gdy opróżnisz pamięć podręczną przeglądarki. Proces ten usuwa również wszystkie pliki cookie.

Atak CSRF jest w swej istocie nadużyciem zaufania

Jak widać, w odpowiednim ataku atakujący oszukuje usługę, która odczytuje ciasteczka. Poniżej wyjaśnię, jak dokładnie to się dzieje 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 Cross Site Request Forgery (CSRF) na WordPressa można zapobiec dzięki zdrowemu rozsądkowi.

Jak bardzo podatny na ataki jest WordPress?

Prawdopodobnie nie słyszałeś jeszcze terminu Cross-Site Request Forgery tak często jak ataki typu brute force 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 internetowych. W tymczasowym wykazie na 2017r. CSRF zajmuje 8 miejsce na 10. W 2007 i 2010 roku atak ten był jeszcze na 5 miejscu, W 2013 roku spadła na 8 miejsce. zszedł.

Jednym z powodów jest to, że ataki CSRF są prawie tak stare jak sam internet. Profesjonalni programiści są obecnie wyćwiczeni w zabezpieczaniu przed nimi swojego kodu. Tak więc zagrożenia bezpieczeństwa są dość łatwe i szybkie do naprawienia.

WordPress również ma się na baczności. W maju, na przykład, 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. Jednakże, skrypty cross-site scripting są Jednakże, cross-site scripting jest często uważany za znacznie bardziej niebezpieczny.

Co więcej, kwestia cross-site request forgery wydaje się być bardziej istotna dla twórców wtyczek i 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ę istotne na przykład w przypadku zakupów w pluginach.

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 podstępnie nakłania ofiarę do załadowania zmanipulowanej strony lub kliknięcia na link, np. podając się za zaufaną osobę lub wykorzystując ludzką ciekawość. Innymi słowy, phishing odgrywa istotną rolę w tego typu atakach.
  2. Podczas ładowania lub klikania na zmanipulowane linki lub strony, przeglądarka ofiary wykonuje żądanie HTTP, a ofiara niczego nie zauważa.

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

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

Nawiasem mówiąc, poniższe przykłady pochodzą z następujących źródeł:

Cross-Site Request Forgery z metodą GET

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

Więc Justus loguje się na 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:

<a href="http://bank.de/transfer.do?acct=SKINNY&betrag=100000">Wer dieses Rätsel nicht lösen kann, ist kein echter Detektiv!</a>

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

<img src="http://bank.de/transfer.do?acct=SKINNY&betrag=100000" width="0" height="0" border="0">

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

Oczywiście, Justus musi kliknąć na link będąc zalogowanym. Ale jeśli, niestety, w przeglądarce znajduje się plik cookie logowania 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 w metodzie 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ą jednak częścią adresu URL, lecz są dołączane do nagłówka.

Może się to wydawać nieco 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 chce.

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

<form method="POST" action="geld_ueberweisen.php">

    <input type="text" name="von">

    <input type="text" name="an">

    <input type="text" name="betrag_in_euro">

    <input type="submit">

</form>

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 w takim przypadku przelew jest realizowany.

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

<form method="POST" action="http://www.bank.de/geld_ueberweisen.php">

    <input type="text" name="von" value="Justus" style="display: hidden">

    <input type="text" name="an" value="Skinny" style="display: hidden">

    <input type="text" name="betrag_in_euro" value="100000" style="display: hidden">

    <input type="submit" value="Wer dieses Rätsel nicht lösen kann, ist kein echter Detektiv!">

</form>

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

Stąd nazwa Cross-Site 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 tam niczego nie podejrzewającego użytkownika, aby jego przeglądarka wykonała kod. 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 WordPressa?

Jak zabezpieczyć się przed atakami CSRF

Dobra wiadomość: cross-site request forgery jest znane od dawna. Deweloperzy znają to ryzyko i pracują specjalnie nad jego wyeliminowaniem.

Zła wiadomość jest taka, że od strony technicznej nie możesz się przed tym uchronić. Rdzeń WordPressa jest obecnie stosunkowo dobrze chroniony, a jak widać po bieżących aktualizacjach, ciągle trwają nad nim prace. Podobnie jak w przypadku innych rodzajów ataków, większość luk jest związana z wtyczkami. Musisz więc zaufać, że twórcy rozszerzeń, których używasz, wykonują dobrą robotę.

To znaczy konkretnie:

  • Nie instaluj zbyt wielu wtyczek i instaluj tylko te, które są Ci naprawdę potrzebne.
  • Należy uważać na wtyczki, które od dłuższego czasu nie były aktualizowane przez twórców. Mogą tu być ukryte nieusunięte luki w zabezpieczeniach.
  • Dowiedz się wcześniej o wtyczkach, które instalujesz, np. o ich kompatybilności z innymi wtyczkami lub o wersji WordPressa, której używasz (aby wtyczka mogła być również aktualizowana).
  • Regularnie aktualizuj swoje wtyczki i rdzeń WP. Dzieje się tak dlatego, że ciągłe aktualizacje mają na celu właśnie usunięcie takich luk w zabezpieczeniach.
  • Ty krytyczny w stosunku do phishingu
  • Jeśli nie jesteś pewien, przyjrzyj się dokładnie wtyczce w repozytorium WP. Jakie są oceny, jakie były największe problemy w przeszłości i czy wtyczka nie zamknęła 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 atakami brute force.

Potwierdza to również ocena OWASP: tutaj zakłada się, że atak jest raczej powszechny, łatwy do wykrycia i poważny tylko w bardzo 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 operatorem, najlepszym sposobem na ochronę przed cross-site request forgery jest przeprowadzenie badań i użycie odrobiny zdrowego rozsądku.

Spodobał Ci się ten artykuł?

Zostawiając opinię pomożesz nam udoskonalać publikowane przez nas treści.

Napisz komentarz

Twój adres e-mail nie zostanie opublikowany.