To pytanie dotyczy tylko ochrony przed atakami typu Cross Site Request Forgery.
Chodzi w szczególności o: Czy ochrona za pośrednictwem nagłówka Origin (CORS) jest tak dobra, jak ochrona za pośrednictwem tokenu CSRF?
Przykład:
- Alicja jest zalogowana (używając pliku cookie) w swojej przeglądarce na „ https://example.com ”. Zakładam, że korzysta z nowoczesnej przeglądarki.
- Alicja odwiedza „ https://evil.com ”, a kod klienta evil.com wykonuje jakieś żądanie do „ https://example.com ” (klasyczny scenariusz CSRF).
Więc:
- Jeśli nie sprawdzimy nagłówka Origin (po stronie serwera) i żadnego tokena CSRF, mamy lukę w zabezpieczeniach CSRF.
- Jeśli sprawdzimy token CSRF, jesteśmy bezpieczni (ale to trochę uciążliwe).
- Jeśli sprawdzimy nagłówek Origin, żądanie z kodu po stronie klienta evil.com powinno zostać zablokowane tak samo, jak w przypadku użycia tokena CSRF - z wyjątkiem sytuacji, gdy kod evil.com może ustawić nagłówek Origin.
Wiem, że nie powinno to być możliwe z XHR (patrz np. Bezpieczeństwo udostępniania zasobów między źródłami ), a przynajmniej nie, jeśli ufamy, że specyfikacja W3C zostanie poprawnie zaimplementowana we wszystkich nowoczesnych przeglądarkach (czy możemy?)
A co z innymi rodzajami próśb - np. Przesłaniem formularza? Ładowanie tagu script / img / ...? Czy w inny sposób strona może (legalnie) utworzyć żądanie? A może jakiś znany hack JS?
Uwaga: nie mówię o
- aplikacje natywne,
- manipulowane przeglądarki,
- błędy cross-site scripting na stronie example.com,
- ...
javascript
security
cors
csrf
Chris Lercher
źródło
źródło
Origin? To zniweczyłoby ochronę CORS.Odpowiedzi:
Ostatecznie musisz „zaufać” przeglądarce klienta, aby bezpiecznie przechowywać dane użytkownika i chronić sesję po stronie klienta. Jeśli nie ufasz przeglądarce klienta, powinieneś w ogóle przestać używać sieci do niczego innego niż zawartość statyczna. Nawet korzystając z tokenów CSRF, ufasz, że przeglądarka klienta prawidłowo przestrzega zasad tego samego pochodzenia .
Chociaż wcześniej występowały luki w przeglądarkach, takie jak te w IE 5.5 / 6.0, w których osoby atakujące mogły ominąć te same zasady pochodzenia i przeprowadzać ataki, zazwyczaj można oczekiwać, że zostaną one załatane, gdy tylko zostaną wykryte, a większość przeglądarek automatycznie się zaktualizuje. , ryzyko to zostanie w większości złagodzone.
OriginNagłówek jest normalnie tylko wysłał do XHR żądań cross-domeny. Żądania obrazów nie zawierają nagłówka.Nie jestem pewien, czy dotyczy to zmanipulowanych przeglądarek, czy nie, ale stare wersje Flasha pozwalały na ustawienie dowolnych nagłówków, które umożliwiałyby atakującemu wysłanie żądania ze sfałszowanym
referernagłówkiem z maszyny ofiary w celu wykonania ataku.źródło
crossdomain.xmlmożliwość umożliwienia komunikacji między domenami.Treść internetowa nie może zmieniać nagłówka Origin. Ponadto w ramach tej samej zasady pochodzenia jedno źródło nie może nawet wysyłać niestandardowych nagłówków do innych źródeł. [1]
W związku z tym sprawdzenie nagłówka Origin jest równie dobre w blokowaniu ataków, jak użycie tokena CSRF.
Głównym problemem związanym z poleganiem na tym jest to, czy pozwala ono działać wszystkim uzasadnionym żądaniom. Pytający wie o tym problemie i ustawił pytanie, aby wykluczyć główne przypadki (brak starych przeglądarek, tylko HTTPS).
Producenci przeglądarek przestrzegają tych zasad, ale co z wtyczkami? Może nie, ale pytanie pomija „zmanipulowane przeglądarki”. A co z błędami w przeglądarce, które pozwalają napastnikowi sfałszować nagłówek Origin? Mogą istnieć błędy, które pozwalają tokenowi CSRF na przeciekanie między źródłami, więc twierdzenie, że jeden jest lepszy od drugiego, wymagałoby więcej pracy.
źródło