CSRF - ten skrót pojawia się raz po raz w notatkach o aktualizacjach WordPress Core. Metoda, która za tym stoi, jest już stara i wykorzystuje zwykle obfite pliki cookie przeglądarki. Na szczęście jednak możesz 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 ponownie odwiedzisz stronę, nie będziesz musiał ponownie wpisywać danych do logowania, ale zostaniesz bezpośrednio zalogowany. Jest to oczywiście świetne rozwiązanie, ponieważ - podobnie jak zarządzanie hasłami czy tzw. pojedyncze logowanie - oszczędza Ci konieczności wypełniania formularzy.
W tle zachodzą następujące procesy: kiedy po raz pierwszy logujesz się na stronie internetowej, strona umieszcza w Twojej przeglądarce plik cookie. Jest to mały plik tekstowy, w którym mogą być zapisane pewne informacje. W przypadku pozostawania zalogowanym jest to losowo wygenerowany ciąg znaków.
Przy następnej wizycie na stronie serwer sprawdza ten ciąg i jeśli znajdzie jego odpowiednik, loguje Cię automatycznie. Jest to również powód, dla którego jesteś wylogowywany wszędzie, gdy opróżnisz pamięć podręczną swojej przeglądarki. Proces ten usuwa również wszystkie pliki cookie.
Ataki CSRF są w gruncie rzeczy nadużyciem zaufania
Jak widać, w przypadku takiego ataku usługa, która odczytuje ciasteczka, zostaje oszukana. Na dwóch przykładach wyjaśnię, jak dokładnie to się dzieje.
Niebezpieczeństwo takiej manipulacji polega na tym, że ktoś w Twoim imieniu wprowadza zmiany w Twoim profilu na Facebooku. Jednak cross site request forgery często zależy również od phishingu. Tutaj również istotne jest zaufanie - na przykład zaufanie do nadawców wiadomości e-mail.
Jak bardzo podatny na ataki jest WordPress?
Prawdopodobnie nie słyszałeś terminu Cross Site Request Forgery tak często jak Brute Force Attacks lub 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. CSRF przez lata spadał coraz niżej na liście zagrożeń bezpieczeństwa, a teraz zniknął z pierwszej dziesiątki.
Jest to prawdopodobnie częściowo spowodowane tym, że ataki CSRF są prawie tak stare jak sam internet. Profesjonalni programiści mają już praktykę w zabezpieczaniu przed nimi swojego kodu. Dlatego zagrożenia bezpieczeństwa są dość łatwe i szybkie do naprawienia.
WordPress również jest czujny. W maju na przykład wydano aktualizację bezpieczeństwa 4.7.5, która usunęła sześć luk w zabezpieczeniach, które hakerzy mogli wykorzystać do przeprowadzenia ataku poprzez cross-site scripting lub cross-site request forgery. Jednak 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 wtyczek i aplikacji niż dla firm projektujących strony internetowe, agencji i małych i średnich przedsiębiorstw. Dzieje się tak, ponieważ ochrona przed CSRF jest również kwestią programowania. CSRF może stać się istotne na przykład w przypadku zakupów dokonywanych w wtyczkach.
Ale jak to wszystko działa teraz?
Anatomia ataku Cross Site Request Forgery
Podstawowa idea ataku CSRF jest stosunkowo prosta i zwykle przebiega w dwóch krokach:
- Ofiara zostaje podstępnie zmuszona do załadowania zmanipulowanej strony internetowej lub kliknięcia linku, na przykład poprzez stworzenie pozorów, że wiadomość pochodzi od zaufanej osoby. Wykorzystywana jest też ludzka ciekawość. Innymi słowy, phishing odgrywa ważną rolę w tego typu atakach.
- Podczas wczytywania lub klikania zmanipulowanych linków lub stron internetowych, przeglądarka ofiary wykonuje żądanie HTTP, czego ofiara nie zauważa.
Dwa stosunkowo proste przykłady ilustrują jak działa taki atak.
Załóżmy, że Justus chce przelać 100 euro Bobowi za pośrednictwem strony www.bank.de, a Chudy czeka, by przeprowadzić atak CSRF. Chudy może użyć metody GET lub POST do swojego ataku.
Nawiasem mówiąc, poniższe przykłady pochodzą z następujących źródeł:
- "Cross Site Request Forgery (CSRF)" - artykuł przeglądowy OWASP
- "Zapobieganie atakom CSRF w WordPressie przy użyciu znaków Nonces" - von qnimate.com
Wykrywanie błędów w żądaniach stron internetowych przy użyciu metody GET
Metoda GET służy do żądania zasobu z serwera, na przykład pliku HTML. Parametry potrzebne do wywołania są po prostu dodawane do adresu URL. A jak już wiemy z wstrzyknięć do bazy danych: URL jest stosunkowo łatwy do manipulowania.
Justus loguje się na stronie www.bank.de i wprowadza wszystkie niezbędne dane. Następujące (całkowicie fikcyjne) dane zostałyby przesłane do serwera:
GET http://bank.de/transfer.do?acct=BOB&betrag=100 HTTP/1.1Chudy konstruuje teraz adres URL, który przekazuje 100 000 euro na jego własne konto. Wygląda to następująco:
http://bank.de/transfer.do?acct=SKINNY&betrag=100000Oczywiście, Justus musi wykonać akcję ukrytą za fałszywym linkiem. Dlatego Chudy 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 e-maila z "niewidocznym" (bo 0 na 0 pikseli) obrazkiem. Podczas próby załadowania obrazka 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 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 jego przeglądarce znajduje się plik cookie logowania z jego banku, atak zadziała nawet wtedy, gdy w danej chwili nie ma otwartej strony internetowej.
Właśnie to sprawia, że Cross Site Request Forgery jest tak podstępne: Justus prawdopodobnie nawet nie wie, że taki plik cookie istnieje.
Wykrywanie błędów w żądaniach Cross Site przy użyciu metody POST
Metoda GET może być używana w odnośnikach i dlatego jest szczególnie łatwa do rozpowszechniania. Jednak dostawcy mogą teraz zapewnić, że żądania GET nie będą zasadniczo otrzymywać pozwolenia na zapis.
Pozostaje metoda POST: Tutaj dane są przesyłane do serwera, aby mógł je dalej przetwarzać. Dane nie są częścią adresu URL, ale są dołączane do nagłówka.
Może się to wydawać nieco kłopotliwe, ale na pewno znasz ten przypadek użycia, ponieważ formularze działają w ten właśnie sposób.
Dla naszego napastnika Chudego oznacza to, że musi włożyć więcej wysiłku, ale nadal może dotrzeć do celu.
Ten sam scenariusz: Justus chce przekazać pieniądze Bobowi. Wypełnia więc następujący formularz na stronie www.bank.de:
<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 widzisz, kod najpierw używa ciasteczka, aby sprawdzić, czy Justus jest zalogowany. Dopiero potem zostanie wykonany przelew.
Chudy składa teraz niewidzialny formularz na przykład na zmanipulowanej stronie internetowej:
<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>Wysyła Justusowi link do zmanipulowanej strony. Justus czuje się zachęcony, klika na przycisk, aby zobaczyć zagadkę - i nieświadomie wykonuje funkcję geld_ueberweisen.php. Ponieważ funkcja ta znajduje w jego przeglądarce odpowiednie ciasteczko, 100 000 euro zostaje ponownie przekazane Chudemu.
Atak przez obejścia
Stąd nazwa Cross Site Request Forgery: Polecenie jest zwykle wysyłane z innej strony internetowej. Aby zaatakować stronę A, umieszcza złośliwy kod na stronie B. Ofiara jest następnie zwabiana na tę stronę. Następnie zwabia tu niczego nie podejrzewającą ofiarę, aby jej przeglądarka wykonała kod.
"*" wyświetla wymagane pola
Jak chronić się przed atakami CSRF
Dobra wiadomość: Cross Site Request Forgery jest znane od dawna. Ryzyko jest powszechnie znane, a twórcy oprogramowania pracują nad jego wyeliminowaniem.
Zła wiadomość jest taka, że nie możesz się przed tym zabezpieczyć od strony technicznej. Rdzeń WordPressa 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ść luk pochodzi z wtyczek. 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órych naprawdę potrzebujesz.
- Uważaj na wtyczki, które od dłuższego czasu nie były aktualizowane. Mogą się w nich kryć nieusunięte luki bezpieczeństwa.
- Dowiedz się wcześniej o wtyczkach, które instalujesz, na przykład o ich kompatybilności z innymi wtyczkami lub o wersji WordPress, której używasz (aby można było również zaktualizować wtyczkę).
- Regularnie aktualizuj swoje wtyczki i rdzeń WordPress. Stałe aktualizacje służą właśnie do usuwania takich luk w zabezpieczeniach.
- Bądź 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 załatała jakiejś poważnej dziury w zabezpieczeniach?
Wniosek: CSRF to już przeżytek
Cross site request forgery istnieje od początku ery cyfrowej. Ponadto liczba przypadków jest bardzo mała w porównaniu z atakami typu 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 szczególnych przypadkach.
Niemniej jednak dobrze jest wiedzieć, jak działają ataki. Ponieważ ataki często udają się tylko dzięki ludzkim błędom. Często użytkownicy otwierają wiadomości z ciekawości lub klikają na linki, których lepiej byłoby nie otwierać.
Najlepszym sposobem ochrony przed Cross-Site Request Forvery jest zapoznanie się z tematem i zachowanie odrobiny zdrowego rozsądku.
