Cross-site request forgery
Cross-site request forgery (w skrócie CSRF lub XSRF) – metoda ataku na serwis internetowy, która często (m.in. na skutek jednoczesnego wykorzystania) mylona jest z cross-site scripting (XSS) bądź jest uznawana za jej podzbiór. Ofiarami CSRF stają się użytkownicy nieświadomie przesyłający do serwera żądania spreparowane przez osoby o wrogich zamiarach. W przeciwieństwie do XSS, ataki te nie są wymierzone w strony internetowe i nie muszą powodować zmiany ich treści. Celem crackera jest wykorzystanie uprawnień ofiary do wykonania operacji w przeciwnym razie wymagających jej zgody. Błąd typu CSRF dotyczy również serwerów FTP.
Charakterystyka[edytuj | edytuj kod]
Atak ma na celu skłonić użytkownika zalogowanego do serwisu internetowego do tego, aby uruchomił on odnośnik, którego otwarcie wykona w owym serwisie akcję, do której atakujący nie miałby w przeciwnym razie dostępu. Na przykład, użytkowniczka Małgosia, na stałe zalogowana do forum internetowego, może w pewnym momencie otworzyć spreparowany przez Jasia link, który zmieni jej dane kontaktowe albo usunie wątek dyskusji. Jako link może również posłużyć obrazek, którego adres został odpowiednio przygotowany, a konsekwencje wykonanej akcji mogą być znacznie poważniejsze.
Poniższe cechy charakteryzują atak CSRF:
- Dotyczy serwisu wymagającego zalogowania lub innego ograniczenia np. dostępu tylko z sieci wewnętrznej lub określonej puli adresów IP.
- Wykorzystuje zaufanie serwisu 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ę.
Szczególnie podatne na ten atak są aplikacje webowe, które wykonują żądania przesłane przez zalogowanych użytkowników bez autoryzacji konkretnej akcji. Osoba uwierzytelniona na podstawie ciasteczka 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.
Na ataki CSRF narażeni byli użytkownicy serwisów takich jak Digg[1], Amazon.com[2] czy Google AdSense.
Przeciwdziałanie[edytuj | edytuj kod]
Zarówno użytkownicy, jak i twórcy serwisów internetowych mogą aktywnie zapobiegać atakom typu CSRF.
Użytkownicy[edytuj | edytuj kod]
Powodzenie ataku wymaga spełnienia dwóch warunków:
- Użytkownik musi być zalogowany do serwisu internetowego.
- Przeglądarka użytkownika musi wysłać do serwisu żądanie wykonania niechcianej akcji.
W celu ograniczenia pierwszego źródła zagrożenia należy wylogowywać się z serwisów internetowych za każdym razem, gdy skończy się z nich korzystać oraz unikać opcji zapamiętywania sesji na komputerze. Szczególną uwagę należy na to zwracać przy korzystaniu ze stron, których obsługa wiąże się ze znacznymi konsekwencjami (m.in. serwisy aukcyjne i bankowości elektronicznej).
Jeremiah Grossman, ekspert ds. bezpieczeństwa firmy Whitehat Security, korzysta z osobnej przeglądarki do pracy z serwisem bankowości elektronicznej. Przed zalogowaniem się na stronę banku zamyka "codzienną" przeglądarkę i uruchamia osobną, której używa wyłącznie do tego celu[3].
Kliknięcie w link nie jest warunkiem koniecznym do tego, aby przeglądarka przesłała do serwera niechciane żądanie. Atakujący może je "ukryć" w adresie obrazka, zagnieżdżonej ramki bądź przy pomocy skryptu osadzonego w stronie www. Dlatego, będąc zalogowanym do serwisów internetowych, należy unikać otwierania wszelkich innych stron.
Twórcy stron[edytuj | edytuj kod]
Istnieje cały szereg metod, które utrudniają przeprowadzenie skutecznego ataku CSRF.
- Hasła jednorazowe uniemożliwiają osobie niepowołanej spreparowanie poprawnego żądania do serwera. Wymóg podania hasła udostępnionego wyłącznie dysponentowi konta na papierowej liście lub tokenie bądź też przesłanego SMSem na numer telefonu komórkowego praktycznie wyklucza powodzenie ataku CSRF.
- Im większe konsekwencje dla użytkownika niesie korzystanie ze strony, tym krótszy powinien być okres ważności zalogowania i dopuszczalny czas bezczynności.
- Żądania mające skutki uboczne mogą wymagać potwierdzenia, połączonego ew. z ponowną autoryzacją.
- Do każdego formularza można dodawać ukryte pole, zawierające liczbę pseudolosową, która musi zostać przekazana wraz z żądaniem wykonania akcji. Ignorowanie żądań, którym brakuje ukrytej wartości bądź gdy nie pokrywa się ona z liczbą zachowaną po stronie serwera, utrudnia spreparowanie ataku.
- Zamiast liczby pseudolosowej przesłać można zawartość ciasteczka służącego do uwierzytelnienia i porównać je z wartością przesłaną w nagłówku żądania HTTP oraz tą zapisaną po stronie serwera. Metoda ta opiera swoje bezpieczeństwo na zasadzie same origin policy, która gwarantuje, że wartość ciasteczka dostępna jest jedynie dla skryptów pochodzących z oryginalnej strony. Zwrócić należy jednak uwagę na to, że odpowiednio spreparowany skrypt może zostać umieszczony w serwisie przy pomocy ataku XSS.
Poniższe metody zapewniają jedynie prowizoryczne zabezpieczenie.
- 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, nie jest jednak niemożliwe, jeśli przeglądarka atakowanej osoby ma włączoną obsługę JavaScriptu. Nie zmienia to faktu, że stosowanie metody POST do żądań powodujących skutki uboczne jest jednym z zaleceń protokołu HTTP.
- Każdorazowe sprawdzanie czy pole Referer nagłówka żądania HTTP zawiera oryginalną domenę, w której działa aplikacja, również nie gwarantuje jej bezpieczeństwa, ponieważ JavaScript umożliwia atakującemu dowolnie kształtować nagłówek żądania.
Przypisy[edytuj | edytuj kod]
- ↑ How to defeat digg.com
- ↑ Chris Shiflett, My Amazon Anniversary
- ↑ Security Researcher Promotes Concept of 'Safe' and 'Promiscuous' Web Browsers. csoonline.com. [dostęp 2008-01-24]. [zarchiwizowane z tego adresu (2008-01-26)]. (ang.).