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

Istnieje wiele sposobów przeciwdziałania atakom CSRF. Jeden z najbardziej powszechnych to tokeny CSRF. Chronione strony wymagają tokenu CSRF podczas wysyłania żądań, które mogą mieć wpływ na dane (żądania POST). W takich sytuacjach aplikacja internetowa (taka jak bank Boba) generuje token złożony z dwóch części: pierwszej, którą otrzymuje Bob, i drugiej, którą aplikacja zachowa dla siebie. Kiedy Bob będzie próbował wykonać żądanie przelewu, będzie musiał wysłać swój token, który bank następnie porówna ze swoją częścią. Tokeny zostały zaprojektowane tak, aby były niemożliwe do odgadnięcia i dostępne tylko dla konkretnego użytkownika, do którego są przypisane (np. Boba). Dodatkowo nie zawsze są nazywane w sposób oczywisty, lecz niektóre z przykładów potencjalnych nazw to: X-CSRF-TOKEN, lia-token, rt lub form-id. Tokeny mogą być przechowywane w nagłówkach żądań HTTP, w treści żądania POST lub w ukrytym polu, tak jak w poniższym przykładzie:

<form method='POST' action='http://bank.com/transfer'>

<input type='text' name='from' value='Bob'>

<input type='text' name='to' value='Joe'>

<input type='text' name='amount' value='500'>

<input type='hidden' name='csrf' value='lHt7DDDyUNKoHCC66BsPB8aN4p24hxNu6ZuJA+8l+YA='>

<input type='submit' value='submit'>

</form>

W tym przykładzie witryna może zdobyć token CSRF z pliku cookie, z wbudowanego na stronie skryptu bądź z części zawartości otrzymanej ze strony. Niezależnie od metody jedynie docelowa przeglądarka wie, jak odczytać tę wartość. Ponieważ atakujący nie może wysłać tokenu, nie byłby on w stanie pomyślnie przesłać żądania POST i wyprowadzić ataku CSRF. Jednakże tylko dlatego, że aplikacja internetowa używa tokenów CSRF, nie oznacza to końca poszukiwania podatności. Spróbuj usunąć token, zmienić jego wartość i bawić się nim na różne sposoby w celu sprawdzenia, czy aby na pewno logika obsługi tokena została poprawnie zaimplementowana.

Inną metodą ochrony stron internetowych jest korzystanie z CORS; nie jest to jednak niezawodne rozwiązanie, gdyż opiera się ono na zabezpieczeniach przeglądarki i konfiguracji CORS w celu określenia, czy strony trzecie mogą mieć dostęp do odpowiedzi. Atakujący mogą czasami ominąć CORS, zmieniając content-type z application/json na application/x-www-form-urlencoded bądź korzystając z żądań GET zamiast POST, na skutek błędnej konfiguracji po stronie serwera. Działa to, ponieważ przeglądarki automatycznie wysyłają żądanie OPTIONS przy zawartości application/json, lecz nie wysyłają go dla żądań GET lub żądań z zawartością application/x-www-form-urlencoded.

Na koniec, istnieją dwie dodatkowe strategie zapobiegania atakom CSRF. Pierwsza polega na sprawdzeniu nagłówków żądań Origin oraz Referer w celu upewnienia się, czy mają oczekiwaną wartość. Na przykład w niektórych przypadkach Twitter sprawdza nagłówek Origin, a jeśli nie jest on zawarty, sprawdza Referer. Ta metoda działa, ponieważ nad tymi nagłówkami mają kontrolę przeglądarki, więc atakujący nie ma możliwości zdalnej zmiany ich wartości (co oczywiście można obejść, wykorzystując podatności w przeglądarkach bądź korzystając z dodatków). Drugie zabezpieczenie stanowi coraz bardziej powszechne w przeglądarkach wsparcie dla nowego atrybutu plików cookies, zwanego samesite. Atrybut ten można ustawić na strict lub lax. W ustawieniu strict przeglądarka nie wyśle pliku cookie dla żadnego żądania HTTP, które nie pochodzi z konkretnej witryny. Włączamy w to nawet podstawowe zapytania GET. Dla zobrazowania załóżmy, że byłeś zalogowany na stronę Amazon, która użyła atrybutu samesite strict w swoich plikach cookies. Z tego powodu, jeśli wejdziesz w link z innej strony, to przeglądarka nie wyśle twoich plików. W dodatku Amazon nie rozpozna Cię jako zalogowanego, dopóki nie odwiedzisz innej strony Amazona, gdzie Twoje pliki cookies dopiero zostaną wysłane. Z kolei ustawienie atrybutu samesite na lax zleca Twojej przeglądarce wysyłanie plików cookies z inicjującymi żądaniami GET. Działa to zgodnie z zasadą, która mówi, że żądania GET nigdy nie powinny zmieniać danych na serwerze. W tym przykładzie, jeśli byłeś zalogowany na stronie Amazona i korzystała ona z plików lax, przeglądarka przesłałaby Twoje pliki, a Amazon rozpoznałby, że byłeś zalogowany, nawet jeśli zostałeś do niego przekierowany z innej strony.