Nieporozumienie na temat działania Cross Origin Resource Sharing (CORS)

Question

Z tego co wiem o CORS, tak to działa: mam stronę foo.com, która obsługuje stronę X. X chce opublikować dane na innym pasku domeny. com. Jeśli bar.com ma włączoną funkcję CORS (jej nagłówki generują Access-Control-Allow-Origin foo.com), to strona X może teraz wysyłać dane do bar.com.

Jak rozumiem, aby CORS działał, wszystko zależy od ustawienia na bar.com i nie ma nic wspólnego z foo.com. Chodzi o to, aby bar.com nie akceptował żądań ze starej domeny.

Jednak to naprawdę nie ma dla mnie sensu. Sądziłem, że CORS został zaprojektowany, aby umożliwić foo.com na dyktowanie, z kim X może się komunikować. Jeśli wrócimy do poprzedniego przykładu, ale tym razem X jest zagrożony przez podejrzany skrypt, aby w tajemnicy wysłać do evil.com, jak CORS zamierza to zatrzymać? evil.com ma włączoną funkcję CORS i jest ustawiona na *, więc akceptuje żądania z dowolnego miejsca. W ten sposób użytkownik, który myśli, że używa witryny foo.com, nieświadomie wysyła dane do evil.com.

Jeśli chodzi o ochronę samej bar.com, to dlaczego przeglądarka wymusza politykę? Jedyną możliwą sytuacją, w której ma to sens, jeśli masz stronę evil.com wyświetlającą stronę Y, która podszywa się pod stronę foo.com, która próbuje wysłać dane do bar.com. Ale CORS jest egzekwowane przez przeglądarkę, wszystko co musisz zrobić, to uczynić evil.com proxy, które wysyła fałszywe żądania pochodzenia do bar.com (dane przechodzą od Y do evil.com, evil.com określa ich fałszywe pochodzenie do foo .com następnie wysyła go do bar.com).

To ma dla mnie sens tylko wtedy, gdy działa na odwrót. foo.com ma włączoną funkcję CORS, a jej nagłówki są ustawione na Bar.com Access-Control-Allow-Origin. W ten sposób skryptom rouge odmawiano dostępu do zła.com przez przeglądarkę. Sensowne jest więc, aby przeglądarka wymuszała stosowanie tej zasady, ponieważ uruchamiała skrypty, które mogą być różnokolorowe. To nie powstrzyma witryn rouge przed próbą wysłania danych rouge do bar.com, ale bar.com może zabezpieczyć się za pomocą nazwy użytkownika/hasła. Jeśli foo.com ma punkty końcowe, które oczekują danych z X, możesz osadzić tokeny na X, aby upewnić się, że evil.com nie wysyła do nich danych.

Czuję, że nie rozumiem tutaj czegoś ważnego. Naprawdę doceniam pomoc.

Answer 1

Jednak to naprawdę nie ma dla mnie sensu. Sądziłem, że CORS został zaprojektowany, aby umożliwić foo.com na dyktowanie, z kim X może się komunikować.

Nie, chodzi o bar.com kontrolowanie wykorzystania jego zawartości.

Ale CORS jest egzekwowane przez przeglądarki, wszystko trzeba było zrobić, to evil.com proxy, który wysyła fałszywe wnioski pochodzenia do bar.com ...

Tak. A jeśli to zrobisz, a ludzie w bar.com zauważyli i dbają, nie akceptują żądań z twojego serwera. Poruszasz się, nie pozwalają na nowe. Whack-a-mole time. Ale bolesne, jak ta gra w whack-a-mole, jest o wiele mniej bolesne, niż gdyby żądania pochodziły bezpośrednio od każdego użytkownika z ich pulpitu.

Posiadanie foo.com wymusza to, co foo.com może zrobić, nie ma żadnego sensu. foo.com już Wymusza to, co może zrobić foo.com, ponieważ jest to strona foo.com, która obsługuje zawartość i skrypty foo.com.

Answer 2

Nie chodzi o Foo.com, ani o Bar.com. Chodzi o użytkownika.

Są dwie rzeczy, przed którymi chroni CORS. Pierwszy to dostęp do zasobów za zaporą. Drugi to zasoby, które są zwykle chronione, chyba że z przeglądarki wysyłane jest żądanie uwierzytelnienia lub innych poufnych plików cookie.

CORS to technologia Browser, obsługiwana przez serwery, która umożliwia foo ograniczoną swobodę dzwonienia poza domenę. Jest to ograniczony dziurkowany w ograniczeniu skryptów cross-domain.

Każdy może sfałszować nagłówek ORIGIN i utworzyć preflight CORS lub proste żądanie - Oczywiście, każdy może bezpośrednio połączyć się z serwerem Bar bezpośrednio i wysyłać żądania bez użycia CORS w ogóle. Każda przeglądarka może bezpośrednio połączyć się z bar.com i uzyskać dane. Ale nowoczesna przeglądarka nie uruchomi skryptu ze strony foo.com, który uzyskuje dostęp do zasobu bar.com. Osoby odwiedzające witryny internetowe są chronione przed odwiedzaniem witryny przeznaczonej do korzystania z plików cookie lub z faktu, że przeglądarka znajduje się za firmową zaporą sieciową.

Tak przyjęta odpowiedź jest NIEPRAWIDŁOWA. Nie chodzi o to, że bar.com chroni swoje zasoby - robi to poprzez uwierzytelnianie i autoryzację. Nie musisz tworzyć proxy do wysyłania żądań CORS - tworzysz serwer proxy, aby usunąć żądania CORS (automatycznie odpowiadając na żądanie preflight i zwracając odpowiednie nagłówki do przeglądarki, ale wysyłając normalne żądanie do paska. com). Ale nadal potrzebujesz uwierzytelnienia, aby zdobyć zasoby serwisu bar.com, a foo.com nadal będzie musiało w jakiś sposób zmusić cię do zainstalowania proxy, aby wykorzystać lukę w zabezpieczeniach cross-domain, której chroni CORS.

Ale zdanie końcowe jest poprawne - foo.com nie ma kontroli nad zasobami - jest to przeglądarka, z szybką kontrolą z bar.com, aby zapytać, czy jest to coś, co było zamierzone.

Z OP:

Jeśli jest naprawdę wszystko o bar.com ochrony sama, to dlaczego to uczynić przeglądarka egzekwować politykę ?. Jedyną możliwą sytuacją jest , w której ma to sens, jeśli witryna evil.com wyświetla stronę Y, która pod numerem podszywa się pod stronę foo.com, która próbuje wysłać dane do bar.com. Ale CORS jest wymuszony przez przeglądarkę, wszystko co musisz zrobić, to uczynić evil.com proxy , który wysyła fałszywe żądania pochodzenia do bar.com (dane idą od Y do evil.com, evil.com ustawia swój fałszywy origin do foo.com, a następnie wysyła go do bar.com).

evil.com może już kontaktować się z bar.com - tak jak każdy człowiek używający przeglądarki może (lub zwijać się lub wget, itp.). Problem polega na tym, że evil.com może zmusić twoją przeglądarkę do połączenia się z bar.com, która może mieć filtry IP, pliki cookie, zapory ogniowe itp. Chroniąc ją, ale javascript może połączyć się z twoją przeglądarką. Tak więc przeglądarka jest tym, co chroni użytkownika. Przez uniemożliwienie skryptów cross-domain. Czasami jednak jest to przydatne (np. Google apis lub bank łączący się z usługą płacenia rachunków itp.) W celu przechodzenia między skryptami domeny. CORS informuje przeglądarkę, że w tym przypadku wszystko jest OK.

Nie oznacza to, że nie ma dziur, albo standard jest najlepszy, albo że nie ma luk w implementacji w przeglądarce lub że strony są zbyt pobłażliwe. Ale to są różne pytania ...