Czy CORS to bezpieczny sposób wykonywania żądań AJAX między domenami?

82

Po przeczytaniu o CORS (współużytkowaniu zasobów między źródłami) nie rozumiem, jak poprawia to bezpieczeństwo. Komunikacja między domenami AJAX jest dozwolona, ​​jeśli jest wysyłany poprawny nagłówek ORIGIN. Jako przykład, jeśli wyślę

POCHODZENIE: http://example.com

Serwer sprawdza, czy ta domena znajduje się na białej liście, a jeśli tak, nagłówek:

Access-Control-Allow-Origin: [otrzymany adres URL tutaj]

jest odsyłana wraz z odpowiedzią (jest to prosty przypadek, istnieją również wstępnie ustawione żądania, ale pytanie jest takie samo).

Czy to naprawdę bezpieczne? Jeśli ktoś chce otrzymać informacje, sfałszowanie nagłówków ORIGIN wydaje się naprawdę banalnym zadaniem. Również standard mówi, że polityka jest wymuszana w przeglądarce, blokując odpowiedź, jeśli Access-Control-Allow-Origin nie jest poprawna. Oczywiście, jeśli ktoś próbuje uzyskać te informacje, nie użyje standardowej przeglądarki, aby je zablokować.

Gibarian2001
źródło
Przeczytaj tę odpowiedź, jeśli ktoś nie jest pewien, czym są zasady dotyczące tego samego pochodzenia i CORS i dlaczego one istnieją: stackoverflow.com/a/27294846/3340994
nishantbhardwaj2002

Odpowiedzi:

53

Nie możesz sfałszować nagłówka Origin za pomocą JavaScript w przeglądarce internetowej. CORS ma temu zapobiegać.

Poza przeglądarką internetową to nie ma znaczenia. Nie ma na celu uniemożliwienia ludziom pobierania danych, które są publicznie dostępne. Nie możesz ujawnić go publicznie, jeśli nie mają go członkowie publiczności.

Został zaprojektowany tak, aby pod warunkiem:

  • Alice, osoba udostępniająca API zaprojektowane do dostępu przez Ajax
  • Bob, osoba z przeglądarką internetową
  • Charlie, osoba trzecia prowadząca własną witrynę internetową

Jeśli Bob odwiedzi witrynę Charliego, Charlie nie może wysłać kodu JS do przeglądarki Boba, aby pobierał dane ze strony internetowej Alice i wysyłał je do Charliego.

Powyższa sytuacja staje się ważniejsza, jeśli Bob ma konto użytkownika w witrynie Alice, które pozwala mu robić takie rzeczy, jak publikowanie komentarzy, usuwanie danych lub przeglądanie danych, które nie są dostępne dla ogółu społeczeństwa - ponieważ bez ochrony JS Charliego może poinformować przeglądarkę Boba zrobić to za plecami Boba (a następnie wysłać wyniki do Charliego).

Jeśli chcesz uniemożliwić nieupoważnionym osobom dostęp do danych, musisz zabezpieczyć je hasłami, certyfikatami klienta SSL lub innymi środkami uwierzytelniania / autoryzacji opartej na tożsamości.

Quentin
źródło
1
Zasadniczo CORS lub współdzielenie zasobów między źródłami i autoryzacja to dwie oddzielne rzeczy. Jak sugeruje akronim, faktycznie ZEZWALA NA udostępnianie między różnymi źródłami. To, czy klient faktycznie może to zrobić, zależy od logiki autoryzacji.
reaper_unique
149

Celem jest zapobieżenie temu -

  • Wchodzisz na stronę X
  • Autor strony X napisał zły skrypt, który zostaje wysłany do Twojej przeglądarki
  • ten skrypt działający w Twojej przeglądarce loguje się do witryny banku i robi złe rzeczy, a ponieważ działa tak, jak Ty w przeglądarce, ma na to pozwolenie.

Pomysł jest taki, że witryna twojego banku potrzebuje jakiegoś sposobu na poinformowanie przeglądarki, czy można ufać skryptom na stronie X, aby uzyskać dostęp do stron w twoim banku.

jcoder
źródło
9
Twoja odpowiedź również była bardzo jasna, dzięki. Nie mogę głosować za, ponieważ wymaga to 15 punktów reputacji.
Gibarian 2001,
Tak więc CORS nie chroni integralności aplikacji w witrynie X, ale chroni integralność BANKU, który mówi, że można ufać web X w zakresie wykonywania wywołań API do BANKU?
luigi7up
7
@ luigi7up: Nie, CORS niczego nie chroni, w rzeczywistości „osłabia” bezpieczeństwo definiując wyjątki od SOP. W Access-Control-Allow-OriginOkreśla informacje nagłówka, które początki (określone w Originnagłówku) mają dostęp do zasobu. Zwykle dozwolone byłyby tylko żądania o tym samym pochodzeniu. Najważniejszą częścią jest tutaj: zezwolenie / odmowa jest wymuszane przez PRZEGLĄDARKA, a nie serwer. Oznacza to, że Access-Control-Allow-Originchroni Twoją przeglądarkę, a nie zasoby na serwerze lub sam serwer.
Daniel F.
Co uniemożliwia autorowi witryny X zalogowanie się do banku za pośrednictwem zaplecza jego witryn, który byłby następnie używany jako serwer proxy? To tylko dodatkowa warstwa, którą musiałby utworzyć, ale to całkowicie obejdzie problem z CORSem, który miałby w przeglądarce, tak myślę ... Więc to wydaje się być tylko ochroną przeglądarki, która wydaje mi się całkiem bez znaczenia, jeśli możesz to obejść w bardzo prosty sposób ..
tkit
1
@pootzko: w Twoim scenariuszu złośliwa witryna X nie miałaby prawidłowej sesji dla witryny banku. Nawet jeśli ofiara jest zalogowana w swojej bankowości (na przykład w innej zakładce), złośliwa strona X nie miałaby dostępu do tej sesji z powodu polityki plików cookie wymuszonej przez przeglądarkę: przeglądarka nigdy nie wysłałaby pliku cookie sesji do strony internetowej X.
daniel F.
67

Aby dodać odpowiedź @jcoder, cały Originnagłówek nie ma na celu ochrony zasobów żądanych na serwerze. To zadanie należy do samego serwera w inny sposób, dokładnie dlatego, że osoba atakująca jest w stanie sfałszować ten nagłówek za pomocą odpowiednich narzędzi.

Celem Originnagłówka jest ochrona użytkownika. Scenariusz jest następujący:

  • osoba atakująca tworzy złośliwą witrynę internetową M

  • użytkownik Alice jest oszukiwany, aby połączyć się z M, który zawiera skrypt, który próbuje wykonać pewne akcje za pośrednictwem CORS na serwerze B, który faktycznie obsługuje CORS

  • B prawdopodobnie nie będzie miał M w Access-Control-Allow-Originnagłówku, bo po co?

  • Kluczowe jest to, że M nie ma możliwości sfałszowania lub nadpisania Originnagłówka, ponieważ żądania są inicjowane przez przeglądarkę Alicji. Więc jej przeglądarka ustawi (prawidłowe) Originna M, które nie znajduje się w Access-Control-Allow-OriginB, więc żądanie zakończy się niepowodzeniem.

Alice mogłaby Originsama zmienić nagłówek, ale dlaczego miałaby to robić, skoro oznaczałoby to, że sama sobie szkodzi?

TL; DR: The Origin Nagłówek chroni niewinnego użytkownika. Nie zabezpiecza zasobów na serwerze. Atakujący może go sfałszować na własnej maszynie, ale nie może zostać sfałszowany na komputerze, nad którym nie ma kontroli.

Serwery powinny nadal chronić swoje zasoby, ponieważ pasujący Originnagłówek nie oznacza autoryzowanego dostępu. Jednak Originnagłówek, który NIE pasuje, oznacza nieautoryzowany dostęp.

daniel f.
źródło
11
Bardzo ładna odpowiedź. Najlepszy ogólnie IMHO.
petersaints
Dlaczego nie była to wybrana odpowiedź? To jest zdecydowanie najlepsze. Czwarty punkt wspomniany w tej odpowiedzi dotyczy tego, o co tak naprawdę prosi plakat.
alaboudi
najlepsza odpowiedź Daniel. To jest cały punkt CORS: „Punktem kluczowym jest to, że M nie ma możliwości sfałszowania lub nadpisania nagłówka Origin, ponieważ żądania są inicjowane przez przeglądarkę ALICE. Dlatego jej przeglądarka ustawi (poprawne) Origin na M, co nie znajduje się w Access-Control-Allow-Origin B, dlatego żądanie zakończy się niepowodzeniem. "
Lukas Lukac
14

Celem tej samej zasady pochodzenia nie jest ogólne uniemożliwienie ludziom dostępu do treści witryny; jeśli ktoś chce to zrobić, nie potrzebuje nawet przeglądarki. Chodzi o to, aby skrypty klienta nie miały dostępu do treści w innej domenie bez niezbędnych praw dostępu. Zobacz wpis w Wikipedii dotyczący tych samych zasad pochodzenia .

Andy E.
źródło
2
„Chodzi o to, aby skrypty klienta nie uzyskiwały dostępu do treści w innej domenie”, zostało to rozwiązane w ramach tej samej zasady pochodzenia. Nie? Mam na myśli, że moja witryna wysyła ci trochę JS, a twoja przeglądarka nie zezwala na połączenia AJAX z inną domeną. to ta sama polityka pochodzenia. CORS robi to samo - pozwala mojemu Ajaxowi na dostęp do innej domeny. Brakuje mi tutaj czegoś wielkiego :)
luigi7up
do @ luigi7up: Tak, CORS robi coś przeciwnego. Pozwala właścicielowi witryny internetowej na udzielenie dostępu do swoich usług z więcej niż jednej zaufanej domeny.
SergeyT
6

Po przeczytaniu o CORS nie rozumiem, jak poprawia bezpieczeństwo.

CORS nie poprawia bezpieczeństwa. CORS zapewnia serwerom mechanizm informujący przeglądarki, w jaki sposób powinny uzyskać dostęp do obcych domen, i próbuje to zrobić w sposób zgodny z modelem bezpieczeństwa przeglądarki, który istniał przed CORS (a mianowicie z tą samą polityką pochodzenia ).

Ale te same zasady pochodzenia i CORS mają ograniczony zakres. W szczególności sama specyfikacja CORS nie ma mechanizmu odrzucania żądań. Może używać nagłówków, aby poinformować przeglądarkę, aby nie pozwalała stronie z obcej domeny na odczytanie odpowiedzi. W przypadku żądań inspekcji wstępnej może poprosić przeglądarkę, aby nie wysyłała pewnych żądań z domeny zagranicznej. Ale CORS nie określa żadnych środków dla serwera, aby odrzucić (to znaczy nie wykonać) rzeczywiste żądanie.

Weźmy przykład. Użytkownik jest zalogowany na stronie Aza pomocą pliku cookie. Użytkownik ładuje złośliwą witrynę M, która próbuje przesłać formularz, który ma POSTdo A. Co się stanie? Cóż, z CORSem lub bez niego M, z dozwoloną domeną lub bez , przeglądarka wyśle ​​żądanie do Apliku cookie autoryzacji użytkownika, a serwer wykona złośliwyPOST tak, jakby to użytkownik zainicjował.

Ten atak nazywa się fałszerstwem żądań między lokacjami , a sam CORS nie robi nic, aby go złagodzić. Dlatego zabezpieczenia CSRF są tak ważne, jeśli zezwalasz na żądania zmiany danych w imieniu użytkowników.

Teraz użycie Originnagłówka może być ważną częścią ochrony przed CSRF. Rzeczywiście, sprawdzenie tego jest częścią aktualnych zaleceń dotyczących wielotorowej obrony CSRF . Ale to użycieOrigin nagłówka wykracza poza specyfikację CORS.

Podsumowując, CORS jest przydatną specyfikacją do rozszerzania istniejącego modelu bezpieczeństwa Same Origin Policy na inne akceptowane domeny. Nie dodaje zabezpieczeń, a witryny potrzebują takich samych mechanizmów obronnych, jak przed CORS.

Kevin Christopher Henry
źródło
1

Spóźniłem się na odpowiedź, ale nie sądzę, aby jakikolwiek post tutaj naprawdę zawierał poszukiwaną odpowiedź. Największym wnioskiem powinno być to, że przeglądarka jest agentem, który zapisuje originwartość nagłówka. Zły skrypt nie może zapisać originwartości nagłówka. Gdy serwer odpowiada z Access-Control-Allow-Originnagłówkiem, przeglądarka próbuje upewnić się, że ten nagłówek zawiera originwartość wysłaną wcześniej. Jeśli nie, wyzwala błąd i nie zwraca wartości z powrotem do skryptu żądającego. Inne odpowiedzi na to pytanie przedstawiają dobry scenariusz, kiedy chciałbyś zaprzeczyć odpowiedzi złemu skryptowi.

@daniel f również stanowi dobrą odpowiedź na to pytanie

alaboudi
źródło