Читать книгу Na tropie błędów. Przewodnik hakerski - Peter Yaworski - Страница 26

Ataki CSRF wykorzystują słabości w procesie uwierzytelniania żądań aplikacji internetowych. Gdy odwiedzasz stronę, która wymaga logowania, najczęściej za pomocą loginu i hasła, dokonuje ona uwierzytelnienia, dzięki czemu nie będziesz musiał się logować za każdym razem, kiedy odwiedzisz nową stronę w obrębie tej samej domeny. Uwierzytelnienie można przechować na dwa sposoby: przy użyciu podstawowego protokołu uwierzytelniania  lub plików cookies.

By rozpoznać stronę, która używa mechanizmu podstawowego uwierzytelniania HTTP, wystarczy sprawdzić, czy żądanie HTTP zawiera nagłówek, który wygląda jak ten: Authorization: Basic QWxhZGRpbjpPcGVuU2VzYW1l.  To, co wygląda na przypadkową serię znaków, jest zakodowanym w base64 loginem i hasłem, oddzielonymi dwukropkiem. W tym przypadku QWxhZGR pbjpPcGVuU2VzYW1l koduje Alladin:OpenSesame. W tym rozdziale nie będziemy się skupiać na podstawowym uwierzytelnianiu, lecz mimo wszystko możesz użyć wielu z przedstawionych tu technik, by wykorzystać podatności CSRF, które korzystają z podstawowego uwierzytelniania.

Cookies są małymi plikami, które strony internetowe tworzą i przechowują w przeglądarce użytkownika. Witryny używają cookies w różnych celach, takich jak przechowywanie informacji o preferencjach użytkownika czy historii odwiedzin danej strony. Cookies mają swoje atrybuty, które są znormalizowanymi informacjami. Takie detale mówią przeglądarce więcej o samych plikach oraz o tym, jak je traktować. Niektórymi z tych atrybutów są domain, expires, max-age, secure i httponly, o których dowiesz się więcej w tym rozdziale. Oprócz atrybutów cookies zawierają pary nazwa/wartość, które składają się z identyfikatora i powiązanej z nim wartości przekazywanej do strony (atrybut domain określa witrynę, do której należy przekazać te informacje).

Przeglądarki ustalają liczbę plików cookies, które strona może ustawić. Zazwyczaj jednak pojedyncza strona może ustawić od 50 do 150 plików w większości popularnych przeglądarek, choć niektóre z nich deklarują obsługę aż do 600. Przeglądarki pozwalają witrynom używać maksymalnie 4 kB na jeden plik cookie. Nie ma żadnego standardu w nazewnictwie bądź wartościach cookies: strony mają pełną dowolność w wyborze własnych par nazwa/wartość i ich przeznaczenia. Na przykład witryna może używać pliku o nazwie sessionId w celu zapamiętania, kim jest użytkownik, aniżeli wymagać od niego wpisania loginu i hasła przy każdej interakcji. (Pamiętaj, że żądania HTTP są bezstanowe, co opisaliśmy w rozdziale 1. Bezstanowy oznacza, że za każdym żądaniem HTTP witryna nie ma pojęcia, kim jest użytkownik, więc musi go ponownie uwierzytelnić dla każdego żądania.)

Na przykład parą nazwa/wartość w pliku cookie może być session Id=9f86d081884c7d659a2feaa0c55ad015a3bf4f1b2b0b822cd15d 6c15b0f00a08, a plik może mieć atrybut domain o wartości .site.com. Co za tym idzie, plik sessionId będzie wysyłany do każdej witryny .<site>.com, którą użytkownik odwiedzi, na przykład: foo.<site>.com, bar.<site>.com, www .<site>.com i tak dalej.

Atrybuty secure i httponly mówią przeglądarce, kiedy i jak wysyłać oraz czytać pliki cookies. Te atrybuty nie mają wartości; zamiast tego działają jako flagi, które albo są obecne w pliku, albo nie. Kiedy cookie ma atrybut secure, przeglądarka wyśle ten plik tylko przy połączeniu HTTPS. Na przykład, jeśli odwiedziłeś http://www.<site>.com/ (stronę HTTP) z bezpiecznym plikiem cookie, przeglądarka nie wyśle tego pliku na tę stronę. Powodem jest konieczność ochrony twoich danych, gdyż połączenia HTTPS są zaszyfrowane, a HTTP już nie. Atrybut httponly, który będzie istotny przy poznawaniu podatności cross-site scripting w rozdziale 7, mówi przeglądarce, żeby czytała dany plik tylko przez żądania HTTP i HTTPS. W związku z tym przeglądarki nie pozwolą żadnym językom skryptowym (takim jak JavaScript) na odczytanie zawartości tego pliku. Kiedy plik nie ma atrybutów httponly i secure, może zostać odczytany przez potencjalnie groźne źródła. Plik cookie bez atrybutu secure może zostać wysłany do strony internetowej innej niż HTTPS; podobnie plik bez atrybutu httponly może być odczytany przez JavaScript.

Atrybuty expires i max-age określają, kiedy plik cookie powinien wygasnąć i przeglądarka ma go zniszczyć. Atrybut expires określa konkretną datę, kiedy plik cookie ma zostać zniszczony. Na przykład cookie może ustawić atrybut expires=Wed, 18 Dec 2019 12:00:00 UTC. Dla odróżnienia, max-age określa liczbę sekund, po których cookie wygasa (max-age=300).

Podsumowując, jeśli strona bankowa Boba używa plików cookies, przechowa ona jego autoryzację w następujący sposób. Kiedy tylko Bob odwiedzi stronę i zaloguje się, bank wyśle odpowiedź http, która będzie zawierać plik cookie identyfikujący Boba. Z kolei przeglądarka Boba zacznie automatycznie wysyłać ten plik wraz ze wszystkimi innymi żądaniami HTTP do strony internetowej banku.

Po zakończeniu bankowości Bob opuszcza stronę banku, nie wylogowując się. Jest to istotny szczegół, ponieważ kiedy wylogowujesz się ze strony, ta wysyła odpowiedź http, która wygasza Twój plik cookie. W rezultacie po ponownym wejściu na stronę będziesz znowu musiał się zalogować.

Po sprawdzeniu wiadomości Bob klika w link do złośliwej strony.  Ta następnie przeprowadza atak CSRF przez wysłanie żądania do strony bankowej z odpowiednimi plikami cookies.