Co powstrzyma złośliwy kod przed sfałszowaniem nagłówka „Origin” w celu wykorzystania mechanizmu CORS?

149

Tak jak rozumiem, jeśli skrypt po stronie klienta działający na stronie z foo.com chce zażądać danych z bar.com, w żądaniu musi określić nagłówek Origin: http://foo.com, a bar musi odpowiedzieć Access-Control-Allow-Origin: http://foo.com.

Co ma powstrzymać złośliwy kod z witryny roh.com przed zwykłym sfałszowaniem nagłówka w Origin: http://foo.comcelu zażądania stron z paska?

javascript  ajax  http  cors 
— Jay Lamont
źródło
2
Uważam, że chodzi o to, że oryginalna domena, z której strona jest obsługiwana (tutaj foo.com), musi dostarczać Access-Control-Allow-Originnagłówek, w przeciwnym razie przeglądarka nie zezwala na żądanie bar.com.
— Chris Hayes,
2
Przeczytanie tego posta naprawdę pomogło mi w zrozumieniu procesu cors między przeglądarką, serwerem pochodzenia i serwerem docelowym. html5rocks.com/en/tutorials/cors
— brendonparker
5
@ChrisHayes W ogóle tak nie działa CORS. Możesz poczytać na ten temat trochę więcej, patrząc na specyfikację lub tę wspaniałą stronę wiki MDN na ten temat .
— Ray Nicholus,
1
@brendonparker Tak, to świetny artykuł. Ten autor odpowiada na wiele pytań CORS dotyczących SO, a także utrzymuje enable-cors.org .
— Ray Nicholus,
4
@RayNicholus Interesujące, wyraźnie byłem daleko. Dzięki za linki. Sądząc po głosach nad moim komentarzem, nie tylko ja cierpię z powodu tego złudzenia. Mam nadzieję, że ci dwaj wrócą i nauczą się (i wycofają swoje głosy!).
— Chris Hayes,

Odpowiedzi:

159

Przeglądarki kontrolują ustawienie Originnagłówka, a użytkownicy nie mogą zastąpić tej wartości. Więc nie zobaczysz Originnagłówka sfałszowanego z przeglądarki. Złośliwy użytkownik może stworzyć żądanie curl, które ręcznie ustawia Originnagłówek, ale żądanie to pochodziło spoza przeglądarki i może nie zawierać informacji specyficznych dla przeglądarki (takich jak pliki cookie).

Pamiętaj: CORS nie jest zabezpieczeniem. Nie polegaj na CORS, aby zabezpieczyć swoją witrynę. Jeśli udostępniasz chronione dane, użyj plików cookie lub tokenów OAuth lub czegoś innego niż Originnagłówek, aby zabezpieczyć te dane. Access-Control-Allow-OriginNagłówek w CORS tylko dyktuje której początki powinny mieć możliwość dokonania żądań między pochodzenia. Nie polegaj na tym w niczym więcej.

— monsur
źródło
3
To ma sens. Jeśli przeglądarka nie pozwala JavaScriptowi na zastąpienie nagłówka Origin, nie ma problemu. Jeśli wykonujesz żądania spoza przeglądarki, nie będziesz mieć plików cookie. Wydaje mi się, że byłem zdezorientowany, ponieważ we wszystkich dokumentach, które czytałem, nigdzie nie było wyraźnie napisane, że nagłówek Origin nie może zostać zastąpiony. Dzięki!
— Jay Lamont,
43
Jeśli ktoś chce coś sfałszować, może to zrobić. Używając praktycznie dowolnego języka skryptowego, mogą konstruować żądania http. Perl i Python mają biblioteki http, które to bardzo ułatwiają. Biblioteki przechowują i wysyłają pliki cookie, umożliwiają dodawanie dowolnych nagłówków i dostarczają wiele informacji dotyczących debugowania. Więc nagłówki CORS mają tylko utrudnić złośliwemu javascriptowi na forum, które czytasz, zrobienie czegoś paskudnego z kontem bankowym w innej domenie, gdy jesteś zalogowany w obu przeglądarkach.
— Mnebuerquo
9
Aby wyjaśnić, złośliwy użytkownik może po prostu uruchomić instancję przeglądarki, która została załatana, aby umożliwić mu ręczną kontrolę nad nagłówkiem Origin, a następnie doskonale podszywać się pod zwykłego użytkownika, pliki cookie, AJAX i inne.
— Jordan Rieger
10
„Przeglądarki kontrolują ustawianie nagłówka Origin, a użytkownik nie może zastąpić tej wartości”. Jestem pewien, że bardzo łatwo jest użyć narzędzia takiego jak Fiddler2 lub Charles do modyfikowania nagłówków, gdy żądanie opuszcza przeglądarkę.
— Asa
3
złośliwy użytkownik może po prostu odrodzić instancję przeglądarki, która została załatana aby umożliwić mu ręczną kontrolę nad nagłówkiem Origin Jeśli masz dostęp do maszyny do punktu, w którym możesz 'po prostu odrodzić zainstalowaną instancję przeglądarki' (nie brzmi to tak prosto do mnie), dlaczego nie po prostu odczytać ciasteczek bezpośrednio z dysku? Są przechowywane w postaci zwykłego tekstu, który znasz. W rzeczywistości skrypty między witrynami są prawdziwym zagrożeniem, podczas gdy scenariusz ataku jest po prostu wymyślony i niepraktyczny.
— Stijn de Witt,
41

TLDR: nic nie stoi na przeszkodzie , aby złośliwy kod sfałszował pochodzenie. Kiedy tak się stanie, Twój serwer nigdy się o tym nie dowie i będzie reagował na żądania. Czasami te prośby są drogie. Więc nie używaj CORS zamiast żadnego rodzaju zabezpieczeń.

Ostatnio bawiłem się CORS-em i zadałem sobie to samo pytanie. Odkryłem, że przeglądarka może być wystarczająco inteligentna, aby rozpoznać sfałszowane żądanie CORS, gdy je zobaczy, ale twój serwer nie jest tak inteligentny.

Pierwszą rzeczą, jaką znalazłem, było to, że Originnagłówek jest nazwą nagłówka zabronionego przez HTTP , której nie można modyfikować programowo. Oznacza to, że możesz go zmodyfikować w około 8 sekund za pomocą Modyfikuj nagłówki dla Google Chrome .

Aby to przetestować, skonfigurowałem dwie domeny klienckie i jedną domenę serwera. Dodałem białą listę CORS na serwerze, która zezwalała na żądania CORS od klienta 1, ale nie od klienta 2. Przetestowałem obu klientów i rzeczywiście żądania CORS klienta 1 zakończyły się powodzeniem, podczas gdy klient 2 zawiódł.

Następnie sfałszowałem Originnagłówek Klienta 2, aby pasował do nagłówka Klienta 1. Serwer otrzymał sfałszowany Originnagłówek i pomyślnie przeszedł kontrolę białej listy (lub nie powiódł się, jeśli jesteś typem do połowy pustej szklanki). Następnie serwer sumiennie działał, zużywając wszystkie zasoby, które był przeznaczony do wykorzystania (wywołania bazy danych, wysyłanie drogich e-maili, wysyłanie jeszcze droższych wiadomości SMS itp.). Kiedy to się stało, serwer szczęśliwie wysłał sfałszowany Access-Control-Allow-Originnagłówek z powrotem do przeglądarki.

Dokumentacja, którą przeczytałem, stwierdza, że Access-Control-Allow-Originotrzymana wartość musi Origindokładnie odpowiadać wartości przesłanej w żądaniu. Pasują do siebie, więc byłem zaskoczony, gdy zobaczyłem następujący komunikat w Chrome:

Nie można załadować XMLHttpRequest http://server.dev/test. Nagłówek „Access-Control-Allow-Origin” ma wartość, http://client1.dev która nie jest równa podanemu pochodzeniu. http://client2.dev Dlatego Origin nie ma dostępu.

Dokumentacja, którą przeczytałem, nie wydaje się być dokładna. Karta sieciowa Chrome wyraźnie pokazuje zarówno nagłówki żądań, jak i odpowiedzi jako http://client1.dev, ale możesz zobaczyć w błędzie, że Chrome w jakiś sposób wie, że prawdziwe źródło było http://client2.devi poprawnie odrzuca odpowiedź. W tym momencie nie ma to znaczenia, ponieważ serwer już przyjął sfałszowane żądanie i wydał moje pieniądze.

— Nocturno
źródło
2
@Nocturno, dziękuję za przykład. Dodam tylko moją obserwację. CORS odnosi się do funkcji bezpieczeństwa przeglądarki. Jeśli bezpieczna przeglądarka zostanie zmodyfikowana z pierwotnego stanu, może to zostać zinterpretowane jako prawdopodobnie pozbawiona funkcji bezpieczeństwa.
— Luka Žitnik
12
Wcale nie genialne. Całkowicie mija się z celem CORS. Jeśli jesteś w stanie przechwycić żądania pochodzące z komputera użytkownika, możesz po prostu odczytać jego pliki cookie, zainstalować keyloggery, wirusy i wszystkie inne realne zagrożenia. CORS ma na celu ochronę uczciwych użytkowników zalogowanych w witrynie A przed złośliwym skryptem, który w jakiś sposób został wstrzyknięty do witryny B. Skrypt w witrynie B (który może być fragmentem kodu JavaScript w poście na forum, który nie został poprawnie pominięty przez witrynę B) wykonuje działania w witrynie A w ramach konta użytkownika (np. usuwanie rzeczy itp.), przy użyciu sesyjnego pliku cookie ze strony A.
— Stijn de Witt
4
Nazywa się to cross-site scripting i bez CORS można by to zrobić bez konieczności przejmowania kontroli nad maszyną użytkownika. O to chodzi. Kontrola nad maszyną użytkownika nie była potrzebna, ponieważ podczas wysyłania żądań do witryny A przeglądarka automatycznie dodawała sesyjny plik cookie do żądania, więc wyglądało to na prawidłowe żądanie od samego użytkownika, podczas gdy w rzeczywistości pochodziło ze skryptu na innym teren. Zasada tego samego pochodzenia zapobiega temu, a mechanizm CORS służy do umieszczania na białej liście domen, którym należy udzielić dostępu, mimo że znajdują się w innym pochodzeniu.
— Stijn de Witt
3
@Nocturno Tak, byłem może trochę zbyt surowy, przepraszam za to. Twój pierwotny punkt jest ważny. Zasady tego samego pochodzenia to funkcja zabezpieczeń przeglądarki, a CORS to mechanizm osłabiający to bezpieczeństwo poprzez umieszczanie niektórych domen na białej liście. OP musi zrozumieć, że fałszowanie nagłówka Origin nie jest tak naprawdę wykonalne jako „atak”, ponieważ nie przynosi ci niczego, czego nie można uzyskać np. Z curl.
— Stijn de Witt
3
@Nocturno Myślę, że twoje wstępne oświadczenie jest nieco mylące. There's nothing stopping malicious code from spoofing the origin-> Tak, nie można ustawić javascript Origin. Tak, użytkownik może zmodyfikować swoją przeglądarkę / użyć skrzypka, aby zmienić pochodzenie, ale CORS nie przed tym broni się; Strony internetowe kontrolowane przez atakujących nie mogą zmienić Origin, i to jest jedyne, co się liczy.
— RJFalconer,
17

Tylko skromne podsumowanie:

P: Czy polityka tego samego pochodzenia (SOP) jest egzekwowana tylko przez przeglądarki?
ZA: tak. W przypadku wszystkich połączeń wykonywanych w przeglądarce SOP jest zdecydowanie stosowana przez przeglądarkę. Serwer może sprawdzić pochodzenie żądania lub nie.

P: Jeśli żądanie nie jest zgodne z SOP, czy przeglądarka je blokuje?
O: Nie, przeglądarki nie mają do tego uprawnień. Przeglądarki po prostu wysyłają żądania z różnych źródeł i czekają na odpowiedź, aby sprawdzić, czy połączenie jest sygnalizowane przez serwer za pośrednictwem Access-Controlnagłówków - *. Jeśli serwer nie odsyła Access-Control-Allow-Originnagłówka zwrotnego, nie odsyła echa z powrotem do źródła wywołującego lub nie odsyła *w nagłówku, to jedyną rzeczą, jaką zrobi przeglądarka, jest powstrzymanie się od dostarczenia odpowiedzi dzwoniącemu.

P: Czy to znaczy, że nie mogę fałszować Origin?
O: W przeglądarce i przy użyciu skryptów nie można przesłonić, Originponieważ jest to kontrolowane przez przeglądarkę. Jeśli jednak chcesz się włamać, możesz manipulować połączeniami wychodzącymi z TWOJEJ przeglądarki za pomocą rozszerzeń przeglądarki lub innych narzędzi zainstalowanych na komputerze. Można też wydać HTTPpołączeń za pomocą curl, Python, C#, etc i zmieniaćOrigin nagłówek do serwerów sztuczka.

P: Więc jeśli mogę oszukać serwer przez zmianę Origin, czy to znaczy, że CORSnie jest bezpieczny?
ZA: CORS per se milczy na temat bezpieczeństwa - tj. Uwierzytelniania i autoryzacji żądań. Do serwerów należy sprawdzanie żądań i uwierzytelnianie / autoryzowanie ich za pomocą dowolnego mechanizmu, z którym współpracują, takiego jak pliki cookie i nagłówki. To powiedziawszy, może nas nieco bardziej chronić w przypadku ataków typu XSS:

Przykład: załóżmy, że zalogowałeś się w swojej witrynie i złośliwy skrypt próbuje wysłać żądanie do witryny banku w celu uzyskania informacji o saldzie: atak Reflected XSS . Witryna banku ufa poświadczeniom pochodzącym z (tutaj w imieniu) Twojej witryny, więc żądanie zostaje uwierzytelnione, a w odpowiedzi nagłówek. Teraz po nadejściu żądania przeglądarka zdaje sobie sprawę, że żądanie było żądaniem z różnych źródeł, ale odpowiedź nie wskazuje, że serwer był szczęśliwy, mogąc udostępnić zasób (tutaj punkt końcowy zapytania o saldo) z Twoją witryną. Tak więc przerywa przepływ, dlatego zwracany wynik nigdy nie dotrze do złośliwego kodu.HTTP odpowiedź mająca na celu złośliwy kod. Jeśli witryna Twojego banku nie dba o udostępnianie swoich punktów końcowych innym źródłom, nie zawieraAccess-Control-Allow-Origin

— Alireza
źródło
Ładna, lepsza / wyraźniejsza niż zaakceptowana odpowiedź IMO
— 3dGrabber
Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.