Co to jest fałszowanie żądań między witrynami (CSRF)?

Luki w zabezpieczeniach związane z fałszowaniem żądań między witrynami (CSRF lub XSRF) rzadko są wysokie lub krytyczne w swoich ocenach ważności. Wciąż jednak mogą wyrządzić wiele szkody. W ostatnich latach były drugą najczęstszą luką w zabezpieczeniach WordPressa, po lukach w zabezpieczeniach związanych z skryptami krzyżowymi (XSS). Zrozumiesz, jak lepiej chronić swoją witrynę, jeśli wiesz, czym jest luka w zabezpieczeniach CSRF i jak atakujący często ją wykorzystują.

Obejście polityki tego samego pochodzenia

Luka CSRF umożliwia atakującemu obejście standardowej funkcji przeglądarki zwanej polityką tego samego pochodzenia. Wszystkie przeglądarki internetowe przestrzegają tej zasady, aby zapobiec rodzajowi zakłóceń, które umożliwiają CSRF. Zwykle podczas ładowania strony internetowej przeglądarka wchodzi w interakcje tylko z jedną domeną lub subdomeną, poza wszelkimi dozwolonymi wyjątkami. I będzie akceptować zawartość tylko przez jeden protokół, HTTP lub HTTPS (nie oba), bez ostrzeżenia o wystąpieniu problemu. Jeśli złośliwe osoby obejdą zasady tego samego pochodzenia, mogą również nakłonić Cię do kliknięcia linków, które wykonują niechciane działania poprzez nieoczekiwaną interakcję z inną witryną.

Wizualnie nie miałbyś żadnych lub niewiele wskazówek, że wchodzisz w interakcję z inną witryną w niepożądany sposób. Clickjacking działa w ten sposób. Jeśli Twoja witryna WordPress została wykorzystana przez lukę w zabezpieczeniach CSRF, Ty i Twoi goście możecie zostać narażeni na phishing, przechwytywanie kliknięć i gorsze rzeczy.

W tym przewodniku przyjrzymy się szczegółom fałszerstw żądań między witrynami. Przyjrzymy się konkretnemu przykładowi luki CSRF, abyś zrozumiał, jak one działają. Następnie pokażemy Ci, co możesz zrobić, aby zapobiec pojawieniu się luk w zabezpieczeniach CSRF w Twojej witrynie. Zaproponujemy również kilka sposobów na uniknięcie lub ograniczenie szkód, jakie może wyrządzić udany exploit CSRF, poprzez zabezpieczenie witryny przed tymi i innymi rodzajami ataków.

Spójrzmy.

W jaki sposób atak typu cross-site request forgery (CSRF) wpływa na Twoją witrynę WordPress?

Kiedy atak CSRF się powiedzie, jego ofiary nieumyślnie autoryzują szkodliwe działanie, takie jak aktualizacja danych logowania. Mogą zostać oszukani, aby umożliwić atakującemu przejęcie ich konta użytkownika. Co gorsza, ofiara exploita CSRF może pozwolić atakującym na inicjowanie przelewów finansowych w jej imieniu.

Jeśli wtyczka w Twojej witrynie WordPress zawiera lukę w zabezpieczeniach CSRF, atakujący może przejąć kontrolę nad niektórymi kontami użytkowników. To byłby jeden z najgorszych scenariuszy. Jeśli skradzione konto pełni rolę administracyjną w WordPress lub użytkownik ponownie użyje swojego hasła w innych witrynach, szkody mogą być rozległe.

Jak działa atak CSRF?

Haker musi spełnić trzy różne warunki, aby atak CSRF zadziałał. Jeśli rozumiesz je na poziomie ogólnym, będziesz mieć dobrą praktyczną znajomość niektórych podstaw bezpieczeństwa w sieci.

1. Obsługa sesji oparta na plikach cookie

Podobnie jak inne aplikacje bezstanowe, WordPress wykorzystuje sesyjne pliki cookie do identyfikacji użytkowników. W warunkach niskiego lub zagrożonego bezpieczeństwa osoba atakująca może być w stanie upiec fałszywe sesyjne pliki cookie lub zmanipulować zalogowanego użytkownika, aby wykonał niepożądane działanie. WordPress zaakceptuje sfałszowane i zmanipulowane żądania, które pochodzą lub wyglądają na pochodzące od zalogowanego użytkownika.

Chociaż exploity CSRF często celują w obsługę sesji opartą na plikach cookie, nie jest to ich jedyny cel. Ataki CSRF mogą być skuteczne przeciwko dowolnej aplikacji, która automatycznie dodaje poświadczenia użytkownika do żądań. Z tego powodu uwierzytelnianie oparte na certyfikatach i uwierzytelnianie HTTP Basic są również podatne na luki w zabezpieczeniach CSRF.

2. Odpowiednie działanie może być ukierunkowane

W docelowej aplikacji musi być jakieś działanie, do którego podjęcia ofiary mogą zostać oszukane. Może to być działanie uprzywilejowane, takie jak zmiana uprawnień użytkownika. Może to być związane z danymi specyficznymi dla użytkownika, takimi jak aktualizacja hasła użytkownika. Są to wspólne działania we wszystkich aplikacjach internetowych, w tym WordPress. Mają wartość jako cele dla hakerów, ponieważ mogą otworzyć im drogę do kradzieży kont użytkowników i głębszego poszukiwania sposobów na kradzież, oszustwo lub inną złośliwą działalność.

3. Brak nieprzewidywalnych parametrów żądania

Żądania, które wykonują ukierunkowaną akcję, muszą być znane lub przewidywalne. Jeśli kierowane żądania nie muszą zawierać parametrów, których wartości atakujący nie może określić ani odgadnąć, są bardziej podatne na manipulację.

Na przykład, jeśli prawidłowe żądanie zmiany hasła musi zawierać istniejące hasło, jest bezpieczne — o ile osoba atakująca nie zna hasła. Tokeny CSRF i pliki cookie SameSite stanowią dodatkowe przeszkody dla atakujących, gdy programiści używają ich do zabezpieczenia swojego kodu. Ale czasami programiści nie wdrażają tych metod bezpieczeństwa poprawnie lub wcale. (Dlatego tak cenne jest silne uwierzytelnianie użytkownika bez hasła).

Wykorzystanie luki CSRF w celu zmiany adresów e-mail konta użytkownika — przykład

Oto bardziej szczegółowy przykład. W rzeczywistości to nie zadziała, ale ilustruje główne koncepcje skutecznego exploita CSRF.

Rozważ prośbę o zmianę adresu e-mail. Gdy użytkownik wykonuje tę czynność, wysyła do odbierającego je serwera WWW żądanie HTTP, które wygląda mniej więcej tak:

 POST /test HTTP/1.1 Host: yourwebsite.com Content-Type: application/x-www-form-urlencoded Content-Length: 60 Cookie: session=yvthgjrudhgeQkAPzeQ5gHgTvlyxHfsAfE;[email protected]

Dlaczego to działa

Spełnia to warunki wymagane dla CSRF, jeśli/ponieważ:

• Docelowa witryna/aplikacja wykorzystuje sesyjny plik cookie do identyfikacji użytkownika, który wysłał żądanie, i nie ma żadnych innych tokenów ani mechanizmów do śledzenia sesji użytkownika. Dlatego programiści powinni używać tokenów CSRF i/lub plików cookie SameSite.
• Zmiana adresu e-mail użytkownika jest adekwatnym działaniem w interesie atakującego. To na pewno! Jeśli możesz zmienić adres e-mail użytkownika na kontrolowany przez siebie, możesz przejąć pełną kontrolę nad jego kontem.
• Atakujący zna parametry żądania potrzebne do zmiany adresu e-mail użytkownika i może wygenerować dla niego prawidłowe wartości. Te parametry nie są tajne i nietrudno jest ustalić, jakich adresów e-mail używa wiele osób do swoich kont internetowych. Sesyjny plik cookie jest trudniejszy.

Jak osoba atakująca może ukraść pliki cookie sesji

Główną przeszkodą atakującego jest określenie rzeczywistych wartości parametrów, które będą miały dostęp do konta konkretnego użytkownika. Mogą to zrobić, budując stronę internetową skierowaną do użytkowników docelowej witryny. Ta oszukańcza witryna może zawierać linki lub przyciski, które wydają się mieć uzasadniony cel, na przykład prośba o bezpłatne upominki. W rzeczywistości, jeśli klikniesz te linki lub przyciski, jedyną osobą, która dostanie trochę słodyczy za darmo, jest atakujący.

Gdy klikniesz te fałszywe linki, wyślą żądanie zmiany adresu do docelowej i podatnej na CSRF witryny. Jeśli jesteś zalogowany na tej stronie, prośba będzie ważna. Twoje konto zostało skradzione — przekazałeś klucze.

Użytkownicy witryny WordPress, którzy pozostają w niej zalogowani, mają w przeglądarce aktywny sesyjny plik cookie, który utrzymuje się nawet wtedy, gdy znajdują się w innej witrynie. Ich przeglądarka automatycznie uwzględni ten sesyjny plik cookie w sfałszowanym żądaniu. WordPress może to postrzegać jako całkowicie poprawne żądanie zmiany adresu — nawet jeśli pochodzi z innej witryny, a użytkownik nie ma pojęcia, że ​​to robi.

Zakładając, że nie zastosowano żadnych innych środków bezpieczeństwa, takich jak atrybut pliku cookie SameSite, zagrożona witryna docelowa przetworzy sfałszowane żądanie tak samo, jak prawidłowe. Jeśli zaatakowana witryna nie wymusi kroku potwierdzenia zmiany adresu lub jeśli osoba atakująca ma sposób na obejście tego problemu, osoba atakująca pomyślnie zmieni adres użytkownika na dowolny wybrany przez osobę atakującą.

W jaki sposób atak CSRF jest dostarczany do podatnej na ataki witryny internetowej

Mechanizmy dostarczania ataków CSRF i ataków Reflected Cross-Site Scripting (Reflected XSS) są podobne.

W większości przypadków osoby atakujące umieszczają swój złośliwy kod na zwodniczej witrynie, którą kontrolują. Może to być legalna witryna, którą już przejęli, dlatego Google prowadzi oszukańczą listę witryn. Wszystkie przeglądarki będą ostrzegać swoich użytkowników, jeśli znajdziesz się na tej liście! Właśnie dlatego iThemes Security codziennie sprawdza, czy Twoja witryna nie stała się narzędziem hakera.

Nakłonienie potencjalnych ofiar do odwiedzenia oszukańczej witryny to po prostu kwestia podstawowych mediów społecznościowych i marketingu e-mailowego. Czasami szkodliwy kod jest po prostu umieszczany na popularnej stronie w aktywnym obszarze.

Atakujący może nawet nie potrzebować strony internetowej, aby zwabić swoje ofiary. Niektóre proste exploity CSRF wykorzystują metodę GET. To właśnie robi Twoja przeglądarka, gdy klikniesz łącze lub wpiszesz adres URL w pasku adresu. Wykonuje żądanie GET, korzystając z adresu URL w linku lub podanego przez Ciebie. Czasami atak CSRF można w pełni wykonać za pomocą pojedynczego żądania GET skierowanego do podatnej witryny. W takich sytuacjach osoba atakująca może nie potrzebować korzystać ze zwodniczej witryny internetowej. Mogą po prostu bezpośrednio podać swoim ofiarom szkodliwy adres URL.

Ochrona Twojej witryny przed atakami typu Cross-Site Request Forgery (CSRF).

Luki CSRF często pojawiają się we wtyczkach, a czasem w motywach. Kiedy hakerzy atakują ich, nie jest trudno się zabezpieczyć. Używaj wysokiej jakości wtyczek i motywów, którym ufasz, usuwaj te, których nie używasz, i dbaj o aktualność całego oprogramowania . Powinieneś także wdrożyć dobrze przemyślaną politykę bezpieczeństwa użytkowników i rozważyć rezygnację z hasła. Jeśli luka CSRF (lub jakakolwiek inna) zostanie wykorzystana w Twojej witrynie w celu uzyskania dostępu do kont użytkowników, nie przyniesie to wiele korzyści atakującemu, jeśli używasz kluczy dostępu. Nikt nie może ukraść czegoś, co nie istnieje.

Oprócz zarządzania aktualizacjami i ostrzegania o podatnych na ataki wtyczkach i motywach, iThemes Security Pro ułatwia konfigurowanie i zarządzanie regułami bezpieczeństwa opartymi na użytkownikach i rolach. Uprawnienia delegatów oparte na zasadzie najmniejszych uprawnień. Zabezpiecz swój login, odzyskiwanie hasła i formularze kontaktowe za pomocą CAPTCHA. Nie dawaj użytkownikom większych możliwości niż potrzebują. Wymagaj od użytkowników o wyższych uprawnieniach używania silniejszych metod uwierzytelniania. I zdecydowanie zastosuj najwygodniejszy, absolutnie prosty sposób logowania się do WordPress bez hasła: klucze dostępu!

Najlepsza wtyczka zabezpieczająca WordPress do zabezpieczania i ochrony WordPress

WordPress obsługuje obecnie ponad 40% wszystkich witryn internetowych, więc stał się łatwym celem dla hakerów o złośliwych zamiarach. Wtyczka iThemes Security Pro usuwa zgadywanie z zabezpieczeń WordPress, aby ułatwić zabezpieczanie i ochronę witryny WordPress. To tak, jakby zatrudnić pełnoetatowego eksperta ds. bezpieczeństwa, który stale monitoruje i chroni Twoją witrynę WordPress.

Pobierz iThemes Security Pro

Dana Knaussa

Dan Knauss jest generalistą ds. treści technicznych w StellarWP. Jest pisarzem, nauczycielem i freelancerem pracującym w open source od późnych lat 90., a z WordPressem od 2004 roku.