Cross-site request forgery (w skrocie CSRF lub XSRF ) ? metoda ataku na serwis internetowy , ktora cz?sto (m.in. na skutek jednoczesnego wykorzystania) mylona jest z cross-site scripting (XSS) b?d? jest uznawana za jej podzbior. 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 rownie? serwerow FTP.

Charakterystyka [ edytuj | edytuj kod ]

Atak ma na celu skłoni? u?ytkownika zalogowanego do serwisu internetowego do tego, aby uruchomił on odno?nik, ktorego otwarcie wykona w owym serwisie akcj?, do ktorej 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, ktory zmieni jej dane kontaktowe albo usunie w?tek dyskusji. Jako link mo?e rownie? posłu?y? obrazek, ktorego 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 adresow 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?.

Szczegolnie podatne na ten atak s? aplikacje webowe , ktore wykonuj? ??dania przesłane przez zalogowanych u?ytkownikow bez autoryzacji konkretnej akcji. Osoba uwierzytelniona na podstawie ciasteczka zapisanego w przegl?darce mo?e nie?wiadomie wysła? ??danie HTTP do serwera, ktory jej ufa i wykona niepo??dan? akcj? w jej imieniu.

Na ataki CSRF nara?eni byli u?ytkownicy serwisow takich jak Digg ^[1] , Amazon.com ^[2] czy Google AdSense .

Przeciwdziałanie [ edytuj | edytuj kod ]

Zarowno u?ytkownicy, jak i tworcy serwisow internetowych mog? aktywnie zapobiega? atakom typu CSRF.

U?ytkownicy [ edytuj | edytuj kod ]

Powodzenie ataku wymaga spełnienia dwoch warunkow:

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 ?rodła zagro?enia nale?y wylogowywa? si? z serwisow internetowych za ka?dym razem, gdy sko?czy si? z nich korzysta? oraz unika? opcji zapami?tywania sesji na komputerze. Szczegoln? uwag? nale?y na to zwraca? przy korzystaniu ze stron, ktorych 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?, ktorej 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 serwisow internetowych, nale?y unika? otwierania wszelkich innych stron.

Tworcy stron [ edytuj | edytuj kod ]

Istnieje cały szereg metod, ktore utrudniaj? przeprowadzenie skutecznego ataku CSRF.

• Hasła jednorazowe uniemo?liwiaj? osobie niepowołanej spreparowanie poprawnego ??dania do serwera. Wymog podania hasła udost?pnionego wył?cznie dysponentowi konta na papierowej li?cie lub tokenie b?d? te? przesłanego SMSem na numer telefonu komorkowego praktycznie wyklucza powodzenie ataku CSRF.
• Im wi?ksze konsekwencje dla u?ytkownika niesie korzystanie ze strony, tym krotszy 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? , ktora musi zosta? przekazana wraz z ??daniem wykonania akcji. Ignorowanie ??da?, ktorym 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 porowna? je z warto?ci? przesłan? w nagłowku ??dania HTTP oraz t? zapisan? po stronie serwera. Metoda ta opiera swoje bezpiecze?stwo na zasadzie same origin policy , ktora gwarantuje, ?e warto?? ciasteczka dost?pna jest jedynie dla skryptow pochodz?cych z oryginalnej strony. Zwroci? 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łowka ??dania HTTP zawiera oryginaln? domen?, w ktorej działa aplikacja, rownie? nie gwarantuje jej bezpiecze?stwa, poniewa? JavaScript umo?liwia atakuj?cemu dowolnie kształtowa? nagłowek ??dania.

Przypisy [ edytuj | edytuj kod ]

Linki zewn?trzne [ edytuj | edytuj kod ]

• Czym jest podatno?? CSRF?