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

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

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.

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.

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.

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 .

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.

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