Ochrona CSRF z nagłówkiem CORS Origin vs. token CSRF

103

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,
...

— Chris Lercher
źródło

Uważam, że wiele serwerów proxy usuwa nagłówek pochodzenia.

— thefourtheye

A w przypadku tagów przesyłania formularzy i img / script powinniśmy polegać na dostawcach CSP, nie mając jednak pewności co do starych przeglądarek.

— thefourtheye

@thefourtheye: Ponieważ połączenie jest inicjowane przez TLS, użytkownik ma znacznie bardziej palący problem niż CSRF, jeśli proxy może go pośredniczyć.

— Perseids,

@thefourtheye, dlaczego mieliby się rozbierać Origin? To zniweczyłoby ochronę CORS.

— Paul Draper,

Podoba mi się to pytanie i odpowiedzi, ponieważ dotyczą czegoś konkretnego, ale przypominają mi też o różnicy między CSRF a CORSem. (Przyznaję, że nie są to łatwe do pomylenia pojęcia ... Ale nadal udaje mi się je pomylić.)

— The Red Pea,

Odpowiedzi:

wiedz, ż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?)

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.

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?

OriginNagłówek jest normalnie tylko wysłał do XHR żądań cross-domeny. Żądania obrazów nie zawierają nagłówka.

Uwaga: nie mówię o

aplikacje natywne,

manipulowane przeglądarki,

błędy cross-site scripting na stronie example.com,

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.

— SilverlightFox
źródło

Przykład Flasha jest dobry - i być może inne wtyczki mogą mieć podobną lukę. Mogę (niestety) chronić Alicję przed CSRF, jeśli używa ona nowoczesnej przeglądarki itp., To jasne. Ale nie jest nierozsądne, że nawet jako użytkownik świadomy bezpieczeństwa mogła zainstalować wtyczki innych firm - zwłaszcza jeśli pochodzą one z dużych (godnych zaufania) firm. Chociaż mogą pisać bezpieczne wtyczki, nie jestem w 100% przekonany, jeśli myślą również o CSRF! Więc jeśli piaskownice przeglądarki nie ograniczają wtyczek przed naruszeniem SOP (może tak?), Wolałbym raczej trzymać się tokena CSRF.

— Chris Lercher,

@ChrisLercher: Tak, współczesne wtyczki wydają się być nieco bardziej niezawodne. Jednak w każdej chwili może zostać wydana nowa wersja, która pozwoli atakującemu wykorzystać ją w taki sposób, aby ominąć zabezpieczenia przeglądarki. Najlepszy sposób na jego obsługę (np. Token / nagłówek) będzie zależał od wrażliwości Twoich danych i tego, czy takie ryzyko jest do zaakceptowania. Flash spełnia wymagania SOP, ale źródłem wtyczki Flash jest strona, z której została załadowana (a nie strona wywołująca, taka jak JavaScript). Istnieje crossdomain.xmlmożliwość umożliwienia komunikacji między domenami.

— SilverlightFox,

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.

— Gość
źródło

Właśnie przetestowałem Firefoksa 47 i nie wysyła on nagłówka pochodzenia dla postu z formularza między źródłami (powszechny sposób atakowania usług REST, które nie włączają CORS dla XHR), więc nie sądzę, aby sprawdzić nagłówek pochodzenia byłoby skuteczne, jeśli użytkownik używa przeglądarki Firefox.

— Andy,

Dla porównania, problem z nieprzesyłaniem przez przeglądarkę Firefox nagłówka „Origin” jest śledzony na Bugzilli: bugzilla.mozilla.org/show_bug.cgi?id=446344 W tym przypadku można wrócić do sprawdzania nagłówka „Referer”, ale z mojego doświadczenia wynika, że Użytkownicy Firefoksa blokują nagłówek „Referer” ze względu na obawy dotyczące prywatności (chociaż IMHO wystarczyłoby usunąć ścieżkę i zapytanie).

— Steffen