CSRF - ten skrót pojawia się raz po raz w aktualizacjach bezpieczeństwa i konserwacji rdzenia WordPressa. Metoda, która za tym stoi, jest już stara i wykorzystuje liczne pliki cookie użytkowników Internetu. Na szczęście jednak możesz w prosty sposób 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 wpisywać danych do logowania, lecz zostaniesz bezpośrednio zalogowany. Jest to oczywiście świetne rozwiązanie dla użytkownika, ponieważ - podobnie jak zarządzanie hasłami czy tak zwane Single Sign On - oszczędza mu konieczności wypełniania formularzy.
W tle zachodzą następujące procesy: kiedy po raz pierwszy logujesz się na stronie, strona umieszcza w Twojej przeglądarce plik cookie. Jest to mały plik tekstowy, w którym można przechowywać pewne informacje. W przypadku pozostawania zalogowanym jest to losowo wygenerowany ciąg znaków.
Przy następnej wizycie na stronie internetowej serwer sprawdza ten ciąg znaków i jeśli znajdzie odpowiedni odpowiednik, loguje Cię automatycznie. Jest to również powód, dla którego jesteś wszędzie wylogowany, kiedy opróżnisz pamięć podręczną swojej przeglądarki. Proces ten usuwa również wszystkie pliki cookie.
Atak CSRF to w istocie nadużycie zaufania
Jak widać, w odpowiednim ataku atakujący oszukuje usługę, która odczytuje pliki cookie. Poniżej wyjaśnię, jak to się dzieje na dwóch przykładach.
Niebezpieczeństwo takiej manipulacji polega na tym, że osoba trzecia, czyli atakujący, dokonuje zmian w Twoim profilu na Facebooku na przykład w Twoim imieniu. Jednak cross-site request forgery często zależy również od phishingu. Również w tym przypadku istotne jest zaufanie - a mianowicie zaufanie do nadawców e-maili.
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ł na 8 miejsce.
Jednym z powodów jest to, że ataki CSRF są prawie tak stare jak sam internet. Profesjonalni programiści mają już praktykę w zabezpieczaniu przed nimi swojego kodu. Zagrożenia bezpieczeństwa są więc dość łatwe i szybkie do naprawienia.
WordPress również ma się na baczności. W maju na przykład wydano aktualizację zabezpieczeń 4.7.5, która usuwa sześć luk, które hakerzy mogli wykorzystać do przeprowadzenia ataku poprzez cross-site scripting lub cross-site request forgery. Jednak Skryptografia cross-site jest często uważana za znacznie bardziej niebezpieczną.
Co więcej, kwestia cross-site request forgery jest zazwyczaj 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ę istotny na przykład w przypadku zakupów dokonywanych przez wtyczki.
Ale jak to wszystko działa teraz?
Anatomia zjawiska Cross-Site Request Forgery
Podstawowa idea ataku CSRF jest stosunkowo prosta i zwykle przebiega w dwóch krokach:
- Haker oszukuje ofiarę, aby załadowała zmanipulowaną stronę lub kliknęła link, na przykład podając się za zaufaną osobę lub wykorzystując ludzką ciekawość. Innymi słowy, phishing odgrywa ważną rolę w tym typie ataku.
- Podczas wczytywania lub klikania zmanipulowanych linków lub stron, 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€ Bobowi przez stronę www.bank.de, a Chudy czeka, by przeprowadzić atak CSRF. Chudy może teraz używać na przykład 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
Fałszowanie żądań typu cross-site przy użyciu metody GET
Metoda GET służy do żądania zasobu z serwera, na przykład pliku HTML. Parametry niezbędne do wywołania są po prostu dodawane do adresu URL. A jak już wiemy z zastrzyków do bazy danych: Adresem URL można stosunkowo łatwo manipulować.
Justus loguje się na stronie www.bank.de i wprowadza wszystkie wymagane dane. Następujące (całkowicie fikcyjne) dane zostaną przesłane do serwera:
GET http://bank.de/transfer.do?acct=BOB&betrag=100 HTTP/1.1
Chudy konstruuje teraz adres URL, który przekazuje 100 000 euro 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. 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 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 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ę ciasteczko logowania do banku atak działa, nawet jeśli w danej chwili nie ma otwartej strony.
To właśnie sprawia, że cross-site request forgery jest tak podstępne: ofiara może nawet nie wiedzieć, że plik cookie istnieje.
Cross-Site Request Forgery w metodzie POST
Metoda GET może być stosowana w odsyłaczach i dlatego jest szczególnie łatwa do rozpowszechniania. To naturalnie sprzyja atakującym w kwestii dystrybucji. Teraz jednak dostawcy mogą zapewnić, że żądania GET z zasady nie otrzymają pozwolenia na zapis.
Pozostaje metoda POST: W tym przypadku dane są przesyłane do serwera, aby mógł je dalej przetwarzać. Dane nie są jednak częścią adresu URL, ale są dołączane do nagłówka.
Może to brzmi trochę nieporęcznie, ale na pewno znasz przypadek użycia. Ponieważ formy 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.
Taki 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 widać, kod najpierw sprawdza, czy Justus jest zalogowany za pomocą cookie. Tylko w takim przypadku przelew jest realizowany.
Skinny umieszcza teraz niewidzialny 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>
Wysyła Justusowi link do tej zmanipulowanej strony. Czuje się wyzwany, klika przycisk, aby zobaczyć zagadkę, i nieświadomie wykonuje funkcję geld_ueberweisen.php. Ponieważ w przeglądarce użytkownika znajduje się odpowiedni plik cookie, 100 000 € zostaje ponownie przekazane Chudemu.
Atak przez obejścia
Dlatego nazywa się to CrossSite Request Forgery: Haker zazwyczaj wysyła polecenie z innej strony. Aby zaatakować stronę 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 zabezpieczyć się przed atakami CSRF
Dobra wiadomość: Cross-site request forgery jest znane od dawna. Deweloperzy znają to ryzyko i pracują 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órych naprawdę potrzebujesz.
- 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.
- Bycie krytycznym 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 już przeżytek
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ż ocenę OWASP: zakłada się, że atak jest raczej mało rozpowszechniony, ł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ć.
Niezależnie od tego, czy jesteś użytkownikiem, czy operatorem, najlepszym sposobem ochrony przed cross-site request forgery jest przeprowadzenie badań i zachowanie odrobiny zdrowego rozsądku.
