POZNAJ CROSS-SITE REQUEST FORGERY, CZYLI JEDEN Z NAJGROŹNIEJSZYCH ATAKÓW NA APLIKACJE WEBOWE

Cross-Site Request Forgery (CSRF), to bardzo groźna podatność zwana także XSRF, session riding lub one-click attack, która została dokładnie opisana w raporcie OWASP Top Ten. Jest często mylona z podatnością XSS (Cross-Site-Scripting).

Podatność CSRF polega na zmuszeniu przeglądarki ofiary do wykonania zapytania HTTP lub FTP, które stanowi nieautoryzowaną akcję. Atak CSRF jest przeprowadzany na przeglądarkę internetową, wobec czego dla serwera zapytania wysyłane przez zaatakowaną przeglądarkę stanowią w pełni legalną komunikację.

Wprowadzenie w XSRF

Warto nadmienić, że w przypadku przeprowadzania ataku CSRF nie jest atakowana część serwerowa aplikacji webowej ani nie zachodzi konieczność wcześniejszej instalacji dodatkowego oprogramowania malware w systemie ofiary, jak w przypadku ataku Man-in-The-Browser.

Ponadto w przeciwieństwie do ataku XSS, atak XSRF nie jest wymierzony w stronę internetową i nie musi powodować zmiany jej treści. Celem atakującego jest wykorzystanie uprawnień ofiary do wykonania danej operacji.

Ofiarami tego ataku stają się użytkownicy nieświadomie przesyłający do serwera żądania spreparowane przez osoby o wrogich zamiarach.

Charakterystyka podatności Cross-Site Request Forgrey

Co do zasady ten typ ataku ma na celu skłonienie użytkownika zalogowanego do serwisu internetowego, aby uruchomił odnośnik, którego otwarcie wykona w tym serwisie daną akcję, której normalnie atakujący nie mógłby wykonać z powodu braku dostępu.

Warto zaznaczyć, że atak CSRF posiada następujące cechy charakterystyczne:

• dotyczy serwisu wymagającego zalogowania lub innego ograniczenia dostępu, np. tylko z sieci wewnętrznej lub określonej puli adresów IP,
• wykorzystuje „zaufanie” serwisu co do tożsamości zalogowanego użytkownika,
• podstępem nakłania przeglądarkę internetową do wysłania żądania HTTP do serwisu,
• dotyczy żądania zmieniającego stan konta użytkownika lub wykonującego w jego imieniu operację.

Istotnym jest fakt, że szczególnie podatne na atak CSRF są aplikacje webowe, które wykonują żądania przesłane przez zalogowanych użytkowników bez autoryzacji konkretnej akcji. Osoba uwierzytelniona na podstawie ciasteczka (pliku cookie) zapisanego w przeglądarce może nieświadomie wysłać żądanie HTTP do serwera, który jej ufa i wykona niepożądaną akcję w jej imieniu.

Co ciekawe, na te ataki narażone były nawet takie aplikacje jak Digg, Amazon.com, czy Google AdSense.

Przebieg ataku Cross-Site Request Forgery

Aby skutecznie przeprowadzić atak CSRF niezbędne jest wykorzystanie odpowiedniego tagu z przypisanym kodem, który może przyjąć następujące formy w celu zobrazowania różnych form tego ataku użyję ścieżki z poniższego Przykładu 1:

• img, np.:
  <img src=”http://meet-me.com/admin/addUser?login=hackAdm1&passwd=12345&type=admin”>,

• script, np.:
  <script src=”http://meet-me.com/admin/addUser?login=hackAdm1&passwd=12345&
  type=admin”>,

• iframe, np.:
  <iframe scrc=”http://meet-me.com/admin/addUser?login=hackAdm1&passwd=12345&
  type=admin”>,

• ‘Image’ Object, np.:
  <script>
  var xyz = new Image();
  xyz.src = ”http://meet-me.com/admin/addUser?login=hackAdm1&passwd=12345&type=admin”;
  </script>

• ‘XMLHTTP’ Object, np.:
  <script>
  var post_data = ‘name=value’;
  var xmlhttp = new ActiveXObject(”Microsoft.XMLHTTP”);
  xmlhttp.open(”POST”, ‘http://url/path/evilFile.ext’, true);
  xmlhttp.onreadystatechange = function () {
  if (xmlhttp.readyState == 4) {
  alert(xmlhttp.responseText);
  }
  };
  xmlhtp.send(post_data);
  </script>

• Mozilla, np.:
  <script>
  var post_data = ‘name=value’;
  var xmlhttp = new XMLHttpRequest();
  xmlhttp.open(”POST”, ‘http://url/path/evilFile.ext’, true);
  xmlhttp.onreadystatechange = function () {
  if (xmlhttp.readyState == 4) {
  alert(xmlhttp.responseText);
  }
  };
  xmlhttp.send(post_data);
  </script>

PRZYKŁAD 1

Stan faktyczny

W ramach pierwszego przykładu przyjrzymy się przebiegowi ataku CSRF na przykładowy portal społecznościowy. Dla potrzeb tego przykładu przyjmiemy, że portal ten działa pod jedną domeną, panel administracyjny posiada ograniczony dostęp – możliwe jest logowanie tylko z ograniczonej puli adresów IP, natomiast atakujący będzie chciał zmusić poprzez atak CSRF przeglądarkę administratora do zarejestrowania nowego konta.

Przebieg ataku

• atakujący rejestruje nowe konto przez formularz dostępny na stronie logowania, jednakże w loginie umieszcza następujący tag:
  <img src=http://meet-me.com/admin/addUser?login=hackAdm1&passwd=12345&type=admin”>,
• następnie administrator loguje się na swoje konto oraz wchodzi na stronę, poprzez którą akceptuje nowe konta,
• podczas akceptacji nowego konta przeglądarka podejmuje próbę pobrania obrazu z tagu <img>, przez co automatyczne realizuje zapytanie (request) do panelu administracyjnego i utworzy w systemie nowe konto o uprawnieniach administratora,
• do zalogowania się atakującego na nowoutworzone konto administracyjne wystarczy, aby jeszcze raz została wykorzystana podatność CSRF do wykonania zapytania usuwającego blokadę na IP nowego użytkownika.

Wnioski

Warto zauważyć, że przedmiotowy atak został zakończony sukcesem, pomimo, że atakujący na początku nie mógł dostać się do panelu administracyjnego z uwagi na ograniczenie dostępu do ściśle określonych adresów IP. Ponadto w tym ataku nie został wykorzystany kod JavaScript oraz nie została wykorzystana podatność XSS (Cross-Site Scripting). Jednakże, gdyby w tej aplikacji (portalu społecznościowym) była dostępna podatność XSS można by było skutecznie przeprowadzić atak CSRF poprzez użycie zapytania wykorzystującego kod JavaScript.

Dodatkowo w logach serwera www, na którym zapisana jest strona z portalem społecznościowym, jako źródłowy adres IP zapytania, poprzez które został dodany nieautoryzowany użytkownik, widoczny będzie prawdziwy adres IP atakowanego administratora, natomiast adres IP atakującego nie będzie widoczny.

Warto dodać, że w tak przeprowadzonym ataku haker nie widzi odpowiedzi na zapytanie (request), do którego wykonania została zmuszona przeglądarka podczas akceptacji przez administratora nowego konta użytkownika tego portalu społecznościowego, jednakże nie ma to wpływu na skuteczność ataku.

Powyższą technikę można zastosować do ataku na dowolny panel administracyjny aplikacji webowej, która przetwarza dane pobrane od użytkownika.

Niestety należy wyraźnie stwierdzić, że co do zasady aplikacje webowe są podatne na ataki CSRF z uwagi na taką a nie inną architekturę sieci web. Oczywiście w celu ochrony przed atakiem CSRF oraz w celu mitygacji tej podatności można w aplikacji webowej używać osobnych bibliotek czy mechanizmów ochronnych. Jednakże nawet w przypadku odpowiedniego filtrowania przez aplikację danych przekazywanych przez użytkownika, np. do pola login, także możliwe jest przeprowadzenie skutecznego ataku CSRF.

PRZYKŁAD 2

Stan faktyczny

W ramach drugiego przykładu przedstawię atak na router dostępowy do Internetu, którego panel administracyjny nie jest dostępny z poziomu Internetu. Tym razem atakujący używa dwóch domen, czyli jednej na której jest atakowany system operacyjny routera i drugiej pomocniczej z wprowadzonymi przez hakera odpowiednimi zmianami. Celem atakującego jest osiągnięcie nieograniczonego dostępu do systemu operacyjnego routera jako super użytkownik (root).

Przebieg ataku

• atakujący umieszcza na dowolnej stronie internetowej tag: <img src=”http://admin:admin@192.168.1.1/xyz”>. Umieszczenie zapytania w tagu <img> zapobiega wyświetleniu okienka z komunikatem ostrzeżenia przez przeglądarki internetowe. Na marginesie warto zaznaczyć, że ta metoda ataku mogłaby służyć także do złamania hasła dostępowego do routera atakiem brute force poprzez generowanie dużej liczby tagów <img>,
• atakujący nakłania ofiarę do wejścia na stronę internetową przygotowaną przez hakera, przez co na komputer ofiary ściąga się strona HTML wraz z obrazkiem (tag <img>),
• przeglądarka podejmując próbę pobrania obrazka wykonuje zapytanie (request) do routera, czyli zostaje zmuszona do wykonania nieautoryzowanej akcji w obrębie sieci lokalnej LAN,
• następnie router wykonuje polecenie zaszyte w tagu <img>, czyli np. restartuje się, dokonuje ściągnięcia zewnętrznego pliku (np. backdoora), czy odblokowuje dostęp do panelu administracyjnego.

Wnioski

W celu skutecznego przeprowadzenia ataku ofiara nie musiała być zalogowana do routera. W przeprowadzonym ataku nie został wykorzystany kod JavaScript oraz nie została wykorzystana podatność XSS. Warto zaznaczyć, że atak się udał, pomimo że atakujący nie znał loginu ani hasła administratora atakowanego routera, a także sam panel administracyjny nie był dostępny z poziomu Internetu. Jednakże dla swej skuteczności atak ten wymagał nakłonienia ofiary do odwiedzenia innej strony internetowej.

PRZYKŁAD 3

Stan faktyczny

W ramach trzeciego przykładu przedstawiony zostanie atak na aplikację webową bankowości elektronicznej. W naszym przykładzie hacker będzie chciał oszukać ofiarę, tak aby przelew środków został wykonany jemu, a nie właściwemu odbiorcy.

Przebieg ataku – żądanie GET

• jeżeli aplikacja bakowości elektronicznej została zaprojektowana tak, aby wykorzystywać żądania GET do przesyłania parametrów i wykonywania akcji, to prawidłowe żądanie może wyglądać następująco: GET http://bank-transfer.com/transfer.do?acc=RECEPIENT&amount=500 HTTP/1.1,
• haker modyfikuje żądanie na podstawie oryginalnego adresu URL polecenia, przy czym zastępuje nazwę beneficjenta sobą i podnosi kwotę przelewu: http://bank-transfer.com/transfer.do?acc=HACKER&amount=80000 lub tworzy exploita,
• wykorzystując socjotechnikę haker nakłania ofiarę do załadowania spreparowanego adresu URL (z tiretu powyżej), gdy ofiara jest zalogowana do aplikacji bankowości elektronicznej;
  zazwyczaj wykorzystywane są do tego następujące techniki:
  – wysłanie niechcianej wiadomości email z treścią HTML,
  – umieszczenie spreparowanego adresu URL lub exploita na stronach, które ofiara prawdopodobnie odwiedzi podczas korzystania z bankowości internetowej;

warto zaznaczyć, że w takim przypadku adres URL exploita może być zamaskowany jako zwykły link, zachęcający ofiarę do kliknięcia w niego, np.: <a href=”http://bank-transfer.com/transfer.do?ac=HACKER&amount=80000”>Zobacz moje najnowsze zdjęcia!</a>

lub jako fałszywy obraz 0x0:
<img src=”http://bank-transfer.com/transfer.do?ac=HACKER&amount=80000” width=”0” height=”0” border=”0”>.

Jeśli haker zamieści niniejszy tag <img> w wiadomości email, wówczas ofiara po kliknięciu w niego nic nie zobaczy, jednakże przeglądarka ofiary prześle żądanie na wskazany adres bez wizualnego wskazania, że przelew miał miejsce.

Jako ciekawostkę dodam, że prawdziwym przykładem ataku CSRF na aplikację wykorzystującą żądanie GET był exploit uTorrent z 2008 roku, który był wykorzystywany na masową skalę do pobierania szkodliwego oprogramowania.

Przebieg ataku – żądanie POST

Różnicą pomiędzy atakiem używającym metody GET a atakiem używającym metody POST jest sposób wykonania ataku.

• w tym przypadku aplikacja internetowa banku wykorzystuje żądania POST do przesyłania parametrów i wykonywania akcji, w związku z tym prawidłowe żądanie będzie wyglądało następująco:
  POST http://bank-transfer.com/transfer.do HTTP/1.1
  acc=RECPIENT&amount=500

• żądania wskazanego w tirecie 1 nie można dostarczyć przy użyciu standardowych tagów <a> lub <img>, ale można je dostarczyć za pomocą tagu <from>; wówczas żądanie będzie wyglądało następująco:
  <from action =”http://bank-transfer.com/transfer.do” method=”POST”>
  <input type=”hidden” name=”acc” value=”HACKER”/>
  <input type=”hidden” name=”amount” value=”80000”/>
  <input type=”submit” value=”Zobacz moje nowe zdjęcia!”/>
  </form>

• formularz z tiretu 2 będzie wymagał od użytkownika kliknięcia przycisku przesyłania, jednak można to wykonać automatycznie przy użyciu kodu JavaScript:
  <body onload=”document.forms[0].submit()”>
  <form…

Przebieg ataku – inne metody HTTP

Wskazać należy, że nowoczesne interfejsy API aplikacji internetowych często używają innych metod HTTP, takich jak PUT lub DELETE.

• w tym przypadku aplikacja internetowa banku używa metody PUT, która jako argument przyjmuje blok JSON:
  PUT http://bank-transfer.com/transfer.do HTTP/1.1

       {„acc”:”RECEPIENT”, „amount”=”500}

• haker wykonuje takie żądanie za pomocą kodu JavaScript osadzonego na stronie exploita:
  <scritpt>
  function put() {
  var x = newXMLHttpRequest();
  x.open(”PUT”,”http://bank-transfer.com/transfer.do”,true);
  x.setRequestHeader(”Content-Type”,”application/json”);
  x.send(JSON.stringify({”acc”:”HACKER”,”amount”=80000}));
  }
  </script>

• należy zaznaczyć, że żądanie opisane w tirecie 2 nie zostanie wykonane przez nowoczesne przeglądarki internetowe dzięki ograniczeniom polityki tego samego pochodzenia; to ograniczenie jest domyślnie włączone, chyba że docelowa witryna internetowa jawnie otwiera żądania cross-origin pochodzące od atakującego (lub kogokolwiek) innego za pomocą mechanizmu CORS (Cross-Origin Resource Sharing) z następującym nagłówkiem: Access-Control-Allow-Origin: *

Wnioski

Warto zaznaczyć, że obecne systemy bankowości elektronicznej są chronione przed podatnością CSRF, a także wymagają dodatkowej autoryzacji przy przelewie.

Niemniej jednak opisane powyżej przykłady ataków CSRF na użytkownika posiadającego otwartą sesję w aplikacji internetowej banku jasno pokazują jak niebezpieczne są tego typu ataki i podatności.

Sposoby ochrony przed atakami Cross-Site Request Forgery

Można rozróżnić kilka sposobów ochrony przed atakami CSRF. Niemniej jednak najważniejsza jest ochrona zapytań (requestów), które realizują zdarzenia zmieniające określone wartości w systemie aplikacji, np. realizujące przelew, czy zmieniające hasło. Co ciekawe, w odróżnieniu od ofiary, atakujący nie widzi bezpośredniego wyniku wykonania akcji. Stąd też wątpliwie zasadny jest np. atak CSRF polegający na listowaniu informacji o wykonanych przelewach.

Jednak zasadnym jest wdrożenie ochrony przed atakami CSRF w całym systemie aplikacji, co pozwala uniknąć braku ochrony, np. dla nowych funkcjonalności wówczas gdy osoba lub zespół odpowiedzialny za implementację zapomniał o jej implementacji.

Ponadto możemy rozróżnić trzy główne sposoby ochrony przed atakami CSRF.

Losowe tokeny

Jest to sposób zalecany przez OWASP, który opiera się na wzorcu Synchronizer Token Pattern. Polega on na użyciu losowych tokenów, czyli ciągów znaków, związanych z zalogowaną sesją (session tokens). W trakcie tworzenia zalogowanej sesji użytkownika, automatycznie generowany jest ciąg znaków, który jest przekazywany do kolejnych zapytań (requestów), np. w następujący sposób:
<form action=”/transfer.do” method=”post”>
<input type=”hidden” name=”CSRFToken” value=”OWY7NmQxODE5ODRiN2Q4NTlhMmZlYWEwYzU1
YWQwMTVhM2JmNGYxYjJiMGI4MjJjZDE1ZDZMGYwMGEwOA==”>
…
</form>

Strona, która obsługuje formularz musi sprawdzić, czy przekazany token jest tą samą wartością, która została wygenerowana przez aplikację.

Z uwagi na to, że atakujący nie zna prawidłowego tokenu, nie ma możliwości przygotowania akceptowalnych przez aplikację zapytań GET zawartych, np. w tagu <img> albo <src> lub zapytań POST umieszczonych na innej stronie lub domenie, będących automatycznie wysyłającym się formularzem.

Należy wyraźnie zaznaczyć, że wyciek prawidłowego tokenu umożliwia ominięcie ochrony przed atakiem CSRF, do czego może dojść, jeśli strona jest podatna na atak XSS. W takim przypadku atakujący pobiera token wykorzystując podatność XSS poprzez użycie XMLHttpRequest i odczytuje go z otrzymanej odpowiedzi, a następnie generuje zapytanie z osadzonym w nim wykradzionym tokenem.

Stąd zasadne jest stwierdzenie, że jeśli nasza aplikacja jest podatna na taki XSS, to bardzo prawdopodobna jest możliwość ominięcia ochrony przed atakiem Cross-Site Request Forgery.

Organizacja OWASP, w celu zwiększenia ochrony przed omawianym atakiem, proponuje tworzenie tokenów dla każdego zapytania (page tokens), a nie dla każdej sesji. Dzięki temu po wysłaniu formularza stary token straci ważność, a na stronie wynikowej generowane są nowe tokeny. Wadą takiego rozwiązania jest zmniejszenie funkcjonalności aplikacji, np. poprzez niedziałanie przycisku „wstecz”, ponieważ użyte na poprzedniej stronie tokeny zostały już unieważnione.

Natomiast akceptacja wrażliwych akcji pochodzących od użytkownika tylko metodą POST powoduje brak konieczności zawierania tokenów w zapytaniach typu GET. Warto wskazać, że parametry zapytań GET często są domyślnie zapisywane w logach serwerów WWW oraz wysyłane w nagłówku HTTP Referer, przez co potencjalnie są narażone na niekontrolowany wyciek.

W przypadku gdy komunikacja opiera się na wzorcu Synchronizer Token Pattern, wówczas możliwe jest wysyłanie tokenów w ciasteczkach (cookies).

Oczywiście możliwe jest generowanie tokenów antiCSRF, jednakże zawsze należy sprawdzać ich poprawność. Niestety w praktyce nader często można usłyszeć od twórców systemów zarządzania treścią (CMS-ów) coś w stylu: „Tak, tokeny antiCSRF mamy, ale jakoś tak wyszło, że niestety nie sprawdziliśmy ich poprawności po stronie serwerowej…”.

Jako ciekawostkę warto nadmienić, że w 2012 roku w ramach programu bug bounty Facebook wypłacił 5000 USD za znalezienie podatności CSRF w funkcji „Appcenter”.

Double Submit Cookies, czyli podwójne przesyłanie plików cookie

Metoda ta polega na wysyłaniu przez przeglądarkę użytkownika tej samej wartości, która jest losowo wygenerowana przez aplikację. Do komunikacji używa się protokołu HTTP oraz ciasteczka. W tym przypadku serwer sprawdza czy wartość zapisana w ciasteczku i wysłana w danym zapytaniu jest taka sama. Jeśli serwer wykryje niezgodność pomiędzy tymi wartościami, wówczas zgłasza próbę ataku CSRF.

Cechą charakterystyczną tej metody, a zarazem jej zaletą jest to, że nie ma potrzeby zapisywania po stronie serwera wcześniej wygenerowanej wartości.

Gotowe biblioteki

Wskazane jest używanie bibliotek i frameworków, które mają możliwość ochrony przed atakami CSRF. Jako przykład można wymienić biblioteki takie jak: spring, django, czy OWASP ESAPI.

Przeciwdziałanie atakom CSRF

• Po stronie użytkownika aplikacji webowej

  Aby atak mógł zostać skutecznie przeprowadzony, muszą być spełnione dwa warunki: użytkownik musi być zalogowany do serwisu internetowego a przeglądarka użytkownika musi wysłać do tego serwisu żądanie wykonania niechcianej akcji.

  W celu ograniczenia pierwszego źródła zagrożenia należy zawsze wylogować się z serwisów internetowych za każdym razem, gdy skończy się z nich korzystać oraz należy unikać opcji zapamiętywania sesji na komputerze, co jest szczególnie istotne, jeśli korzysta się ze stron, których obsługa jest związana ze znacznymi konsekwencjami, np. bankowości elektronicznej, czy serwisów aukcyjnych. W celu zwiększenia bezpieczeństwa zalecane jest, aby stronę z bankowością elektroniczną otwierać w osobnej przeglądarce, po zamknięciu przeglądarki służącej do wykonywania codziennych obowiązków.

  Ponadto będąc zalogowanym do serwisów internetowych należy unikać otwierania innych stron, ponieważ jak wyraźnie wynika z przytoczonych powyżej przykładów, atakujący może ukryć link, który po kliknięciu w niego wymusi wysłanie niechcianego żądania do serwera. Link taki może być ukryty w adresie obrazka, zagnieżdżonej ramki bądź przy pomocy skryptu osadzonego na stronie www.

• Po stronie twórcy aplikacji
  Twórcy stron i aplikacji mogą wykorzystywać następujące metody utrudniające przeprowadzenie skutecznego ataku CSRF:
  1. używanie jednorazowych haseł – uniemożliwia atakującemu spreparowanie poprawnego żądania do serwera, w szczególności, gdy hasła takie są udostępnione użytkownikowi na papierowej liście, tokenie lub przesłane SMSem na numer telefonu komórkowego użytkownika,
  2. skracanie czasu ważności zalogowania i dopuszczalnego czasu bezczynności na stronach, z których korzystanie niesie duże konsekwencje dla użytkownika, np. strony bakowości elektronicznej,
  3. potwierdzanie połączone z ewentualną ponowną autoryzacją dla żądań mogących rodzić skutki uboczne, dodawanie do każdego formularza ukrytych pól zawierających liczbę pseudolosową, która musi zostać przekazana wraz z żądaniem wykonania akcji oraz ignorowanie żądań, które nie zawierają ukrytej wartości, bądź gdy nie pokrywa się ona z liczbą zachowaną po stronie serwera,
  4. zamiast liczby pseudolosowej można przesłać zawartość ciasteczka służącego do uwierzytelnienia i porównać ją z wartością przesłaną w nagłówku żądania HTTP oraz tą zapisaną po stronie serwera, co jest zgodne z zasadą same origin policy, która gwarantuje, że wartość ciasteczka dostępna jest jedynie dla skryptów pochodzących z oryginalnej strony. Należy jednak podkreślić, że odpowiednio spreparowany skrypt może zostać umieszczony na stronie lub w aplikacji przy pomocy ataku XSS.
  
  Nadal stosowane są metody dające jedynie prowizoryczne zabezpieczenie. Zaliczyć można do nich:
  1. stosowanie metody POST do żądań powodujących skutki uboczne, co jest jednym z zaleceń protokołu HTTP; należy jednak zauważyć, że przesłanie do serwera spreparowanej zawartości formularza opartego na metodzie POST jest znacznie trudniejsze niż wykonanie tego samego zadania dla formularza opartego na metodzie GET, lecz nie jest niemożliwe, jeśli przeglądarka atakowanej osoby ma włączoną obsługę kodu JavaScript, co zostało wyraźnie pokazane w Przykładzie 3,
  2. każdorazowe sprawdzanie czy pole Referer nagłówka żądania HTTP zawiera oryginalną domenę, w której działa aplikacja – to również nie gwarantuje bezpieczeństwa, ponieważ kod JavaScript umożliwia atakującemu dowolnie kształtować nagłówek żądania.

Podsumowanie

Zawarcie na liście OWASP Top Ten podatności aplikacji webowych na ataki CSRF, wyraźnie wskazuje, że problem ten jest niezwykle istotny i nie należy go ignorować. Pomimo że do przeprowadzenia skutecznego ataku CSRF zazwyczaj niezbędna jest dodatkowa akcja po stronie ofiary, np. kliknięcie w spreparowany link czy odwiedzenie odpowiednio spreparowanej strony, to skutecznie przeprowadzony atak może być niezwykle groźny i prowadzić do nieodwracalnych strat.

Niestety większość aplikacji webowych jest podatna na ataki CSRF, stąd też konieczne jest ich dodatkowe zabezpieczanie.

Autor: Michał Mamica