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ć.
źródło
Odpowiedzi:
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:
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.
źródło
Celem jest zapobieżenie temu -
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.
źródło
Access-Control-Allow-Origin
Określa informacje nagłówka, które początki (określone wOrigin
nagłó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, żeAccess-Control-Allow-Origin
chroni Twoją przeglądarkę, a nie zasoby na serwerze lub sam serwer.Aby dodać odpowiedź @jcoder, cały
Origin
nagłó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
Origin
nagłó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-Origin
nagłówku, bo po co?Kluczowe jest to, że M nie ma możliwości sfałszowania lub nadpisania
Origin
nagłówka, ponieważ żądania są inicjowane przez przeglądarkę Alicji. Więc jej przeglądarka ustawi (prawidłowe)Origin
na M, które nie znajduje się wAccess-Control-Allow-Origin
B, więc żądanie zakończy się niepowodzeniem.Alice mogłaby
Origin
sama 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
Origin
nagłówek nie oznacza autoryzowanego dostępu. JednakOrigin
nagłówek, który NIE pasuje, oznacza nieautoryzowany dostęp.źródło
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 .
źródło
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
A
za pomocą pliku cookie. Użytkownik ładuje złośliwą witrynęM
, która próbuje przesłać formularz, który maPOST
doA
. Co się stanie? Cóż, z CORSem lub bez niegoM
, z dozwoloną domeną lub bez , przeglądarka wyśle żądanie doA
pliku 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
Origin
nagłó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.
źródło
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
origin
wartość nagłówka. Zły skrypt nie może zapisaćorigin
wartości nagłówka. Gdy serwer odpowiada zAccess-Control-Allow-Origin
nagłówkiem, przeglądarka próbuje upewnić się, że ten nagłówek zawieraorigin
wartość 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
źródło