Odpowiadając za pomocą Access-Control-Allow-Origin: *, żądany zasób umożliwia współdzielenie z każdym źródłem. Zasadniczo oznacza to, że każda witryna może wysłać żądanie XHR do Twojej witryny i uzyskać dostęp do odpowiedzi serwera, co nie miałoby miejsca, gdybyś nie zaimplementował tej odpowiedzi CORS.
Dzięki temu każda witryna może wysłać żądanie do Twojej witryny w imieniu odwiedzających i przetworzyć jej odpowiedź. Jeśli masz zaimplementowane coś, na przykład schemat uwierzytelniania lub autoryzacji, który opiera się na czymś, co jest automatycznie dostarczane przez przeglądarkę (pliki cookie, sesje oparte na plikach cookie itp.), Żądania uruchamiane przez witryny stron trzecich również będą ich używać.
W rzeczywistości stwarza to zagrożenie dla bezpieczeństwa, szczególnie jeśli zezwalasz na udostępnianie zasobów nie tylko dla wybranych zasobów, ale dla każdego zasobu. W tym kontekście należy zapoznać się z tematem Kiedy można bezpiecznie włączyć CORS? .
Access-Control-Allow-Origin: *? Nie będzie żadnych noginów itp., Są one publiczne dla wszystkich?Access-Control-Allow-Origin: *jest całkowicie bezpieczny do dodania do dowolnego zasobu, chyba że zasób ten zawiera prywatne dane chronione przez coś innego niż standardowe poświadczenia (pliki cookie, podstawowe uwierzytelnianie, certyfikaty klienta TLS).Np .: Dane chronione przez pliki cookies są bezpieczne
Wyobraź sobie
https://example.com/users-private-data, co może ujawnić prywatne dane w zależności od stanu zalogowania użytkownika. Ten stan wykorzystuje sesyjny plik cookie. Dodanie do tego zasobu jest bezpieczneAccess-Control-Allow-Origin: *, ponieważ ten nagłówek umożliwia dostęp do odpowiedzi tylko wtedy, gdy żądanie zostało wysłane bez plików cookie, a pliki cookie są wymagane do uzyskania prywatnych danych. W rezultacie żadne prywatne dane nie wyciekają.Np .: Dane chronione przez lokalizację / adres IP / sieć wewnętrzną nie są bezpieczne (niestety powszechne w przypadku intranetów i urządzeń domowych):
Wyobraź sobie
https://intranet.example.com/company-private-data, co ujawnia prywatne dane firmy, ale można uzyskać do nich dostęp tylko wtedy, gdy jesteś w firmowej sieci Wi-Fi. To nie jest bezpieczne , aby dodaćAccess-Control-Allow-Origin: *do tego zasobu, ponieważ jest chroniony za pomocą czegoś innego niż standardowe mandatów. W przeciwnym razie zły skrypt mógłby użyć Cię jako tunelu do intranetu.Praktyczna zasada
Wyobraź sobie, co zobaczyłby użytkownik, gdyby uzyskał dostęp do zasobu w oknie incognito. Jeśli jesteś zadowolony z tego, że wszyscy widzą tę zawartość (w tym kod źródłowy otrzymany przez przeglądarkę), możesz bezpiecznie dodać
Access-Control-Allow-Origin: *.źródło
Access-Control-Allow-Origin: *zezwala tylko na żądania bez plików cookie. Zredagowałem odpowiedź, aby trochę wyjaśnić.AFAIK, Access-Control-Allow-Origin to po prostu nagłówek http wysyłany z serwera do przeglądarki. Ograniczenie go do określonego adresu (lub wyłączenie go) nie czyni witryny bezpieczniejszą np. Dla robotów. Jeśli roboty chcą, mogą po prostu zignorować nagłówek. Zwykłe przeglądarki (Explorer, Chrome itp.) Domyślnie honorują nagłówek. Ale aplikacja taka jak Postman po prostu ją ignoruje.
Koniec serwera w rzeczywistości nie sprawdza, jakie jest „pochodzenie” żądania, kiedy zwraca odpowiedź. Po prostu dodaje nagłówek http. To przeglądarka (klient), która wysłała żądanie, decyduje o przeczytaniu nagłówka kontroli dostępu i wykonaniu na nim czynności. Zauważ, że w przypadku XHR może użyć specjalnego żądania „OPTIONS”, aby najpierw poprosić o nagłówki.
Tak więc każdy, kto ma kreatywne umiejętności tworzenia skryptów, może łatwo zignorować cały nagłówek, niezależnie od tego, co jest w nim ustawione.
Zobacz także Możliwe problemy z bezpieczeństwem podczas ustawiania Access-Control-Allow-Origin .
Teraz, aby właściwie odpowiedzieć na pytanie
Jeśli ktoś chce cię zaatakować, może łatwo ominąć Access-Control-Allow-Origin. Ale włączając „*”, dajesz atakującemu kilka dodatkowych „wektorów ataku” do zabawy, na przykład przy użyciu zwykłych przeglądarek internetowych, które obsługują ten nagłówek HTTP.
źródło
Access-Control-Allow-Origin *zdecydowanie odradzamy umieszczanie na złośliwej stronie internetowej, która obsługuje skrypty do kradzieży haseł :-)192.168.1.1) i rekonfigurować router, aby umożliwić ataki. Może nawet używać routera bezpośrednio jako węzła DDoS. (Większość routerów ma strony testowe, które umożliwiają pingowanie lub proste testy serwera HTTP. Mogą one być masowo nadużywane).Oto 2 przykłady opublikowane jako komentarze, w których wieloznacznik jest naprawdę problematyczny:
- Brad
- Brad
Uważam, że te komentarze powinny być odpowiedziami, ponieważ wyjaśniają problem na przykładzie z życia.
źródło
W scenariuszu, w którym serwer próbuje całkowicie wyłączyć CORS, ustawiając poniżej nagłówki.
Access-Control-Allow-Origin: * (informuje przeglądarkę, że serwer akceptuje żądania między witrynami z dowolnego ORIGIN)
Access-Control-Allow-Credentials: true (informuje przeglądarkę, że żądania między witrynami mogą wysyłać pliki cookie)
W przeglądarkach zaimplementowano funkcję fail safe, która spowoduje poniższy błąd
Dlatego w większości scenariuszy ustawienie „Access-Control-Allow-Origin” na
*nie będzie stanowić problemu. Jednak aby zabezpieczyć się przed atakami, serwer może utrzymywać listę dozwolonych źródeł i za każdym razem, gdy serwer otrzyma żądanie między źródłami, może zweryfikować nagłówek ORIGIN z listą dozwolonych źródeł, a następnie powtórzyć to samo w Access-Control-Allow-Origin nagłówek.Ponieważ nagłówka ORIGIN nie można zmienić za pomocą javascript uruchomionego w przeglądarce, złośliwa witryna nie będzie w stanie go sfałszować.
źródło