target="_blank" rel="nofollow" href="#i000007210021.png"/>. Podobnie jak w przypadku żądania GET, kiedy tylko formularz zostanie wysłany, przeglądarka wykona żądanie POST w celu przesłania plików cookies do strony bankowej, które wywoła przelew. Ponieważ żądania POST zwracają odpowiedź HTTP z powrotem do przeglądarki, atakujący ukrywa odpowiedź w ramce iFrame z atrybutem display:none 
W innych przypadkach strona może oczekiwać żądania POST z nagłówkiem content-type application/json. Czasami żądanie typu application/json będzie mieć token CSRF. Ten token jest wartością, która jest wysyłana wraz z żądaniem HTTP, zatem docelowa strona może zweryfikować, czy żądanie pochodzi od niej samej, a nie innej, potencjalnie złośliwej strony. Token może znajdować się w treści HTTP żądania POST lub we własnym nagłówku z nazwą taką jak X-CSRF-TOKEN. Kiedy przeglądarka ma zamiar wysłać żądanie POST z zawartością typu application/json do strony, najpierw wysyła dodatkowe żądanie OPTIONS. Następnie strona zwraca odpowiedź do żądania OPTIONS, wskazując, które rodzaje żądań HTTP akceptuje i z których zaufanych źródeł mogą pochodzić. Taka operacja jest nazywana „preflight OPTIONS call”. Przeglądarka odczytuje odpowiedź i wysyła poprawne żądanie HTTP, które w naszym przykładzie z bankiem będzie żądaniem POST.
Jeśli zostały zaimplementowane poprawnie, preflight OPTIONS call stanowi ochronę przed niektórymi podatnościami CSRF: złośliwe strony nie będą obecne na liście zaufanych witryn dla danego serwera, podczas gdy przeglądarki będą pozwalały tylko wybranym stronom (znajdującym się na whiteliście witryn) na odczytanie odpowiedzi OPTIONS. Dzięki temu, ponieważ złośliwa strona nie może przeczytać odpowiedzi OPTIONS, przeglądarki nie będą wysyłać niebezpiecznych żądań POST.
Zestaw zasad określających, kiedy i jak strony internetowe mogą czytać odpowiedzi od siebie nawzajem, nazywa się Cross-Origin Resource Sharing (CORS). CORS ogranicza dostęp do zasobów, włączając w to odpowiedzi JSON spoza tych domen, które obsługiwały te pliki lub są dozwolone przez testowaną witrynę. Innymi słowy, kiedy deweloper używa CORS do ochrony witryny, nie możesz wysłać żądania application/json w celu uruchomienia testowanej aplikacji lub odczytania odpowiedzi, chyba że testowana witryna na to zezwala. W niektórych przypadkach możesz ominąć to zabezpieczenie, zmieniając nagłówek content-type na application/x-www-form-urlencoded, multipart/form-data lub text/plain. Przeglądarki nie wyślą żądania preflight OPTIONS dla żadnego z tych trzech rodzajów zawartości przy wykonywaniu żądania POST, zatem żądanie CSRF może zadziałać. Jeśli nie zadziała, sprawdź nagłówek Access-Control-Allow-Origin w odpowiedziach HTTP z serwera, by upewnić się, czy serwer nie ufa wszystkim źródłom. Jeżeli nagłówek ten się zmienia, gdy żądania wysyłane są z dowolnych źródeł, aplikacja może mieć spory problem, gdyż pozwala wszystkim źródłom na odczyt odpowiedzi z ich serwera. Otwiera to drogę na istnienie dziur CSRF, ale może również pozwolić atakującym na odczytanie poufnych danych zebranych w odpowiedziach HTTP z serwera.
Ochrona przed atakami CSRF
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.
Odłączenie Twittera z Shopify
Poziom trudności: Niski
