Cross-site request forgery

Użytkownicy

Powodzenie ataku wymaga spełnienia dwóch warunków:

1. Użytkownik musi być zalogowany do serwisu internetowego.
2. 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.

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

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.