W jaki sposób serwery WWW egzekwują zasady tego samego pochodzenia?

Zagłębiam się w tworzenie interfejsów API RESTful i do tej pory pracowałem z kilkoma różnymi platformami. Oczywiście natrafiłem na zasady tego samego pochodzenia i teraz zastanawiam się, jak wymuszają to serwery sieciowe (a nie przeglądarki). Z tego, co rozumiem, pewne wymuszanie wydaje się mieć miejsce na końcu przeglądarki (np. Honorowanie nagłówka Access-Control-Allow-Origin otrzymanego z serwera). Ale co z serwerem?

Załóżmy na przykład, że serwer sieciowy obsługuje aplikację internetową Javascript, która uzyskuje dostęp do interfejsu API, również hostowanego na tym serwerze. Zakładam, że serwer wymusiłby zasady tego samego pochodzenia --- tak, aby tylko javascript hostowany na tym serwerze miał dostęp do interfejsu API. Uniemożliwi to komuś innemu napisanie klienta javascript dla tego interfejsu API i hostowanie go w innej witrynie, prawda? Jak więc serwer sieciowy mógłby zatrzymać złośliwego klienta, który próbowałby wysyłać żądania AJAX do swoich punktów końcowych interfejsu API, twierdząc, że uruchamia javascript pochodzący z tego samego serwera WWW? W jaki sposób najpopularniejsze serwery (Apache, nginx) chronią przed tego rodzaju atakami? A może moje rozumienie tego jest jakoś nie na miejscu?

Czy też zasada krzyżowania pochodzenia jest egzekwowana tylko po stronie klienta?

Ta sama zasada pochodzenia jest ograniczeniem całkowicie opartym na kliencie i przede wszystkim ma na celu ochronę użytkowników , a nie usług . Wszystkie lub większość przeglądarek zawiera przełącznik wiersza polecenia lub opcję konfiguracji, aby go wyłączyć. SOP jest jak pasy bezpieczeństwa w samochodzie: chronią jeźdźca w samochodzie, ale każdy może swobodnie z niego nie korzystać. Na pewno nie oczekuj, że pas bezpieczeństwa kogoś powstrzyma przed wydostaniem się z samochodu i zaatakowaniem ciebie (lub dostępem do twojej usługi internetowej).

Załóżmy, że piszę program, który uzyskuje dostęp do Twojej usługi sieci Web. To tylko program, który wysyła wiadomości TCP zawierające żądania HTTP. Pytasz o mechanizm po stronie serwera, aby odróżnić żądania wysłane przez mój program (które mogą wysyłać cokolwiek) od żądań wysłanych przez przeglądarkę, która ma stronę załadowaną z dozwolonego źródła. Po prostu nie da się tego zrobić; mój program zawsze może wysłać żądanie identyczne z żądaniem utworzonym przez stronę internetową.

Zasada tego samego pochodzenia została wymyślona, ​​ponieważ uniemożliwia kodowi z jednej witryny dostęp do treści zastrzeżonych w innej witrynie. Żądania Ajax są domyślnie wysyłane z plikami cookie uwierzytelniania udzielonymi przez witrynę docelową. Załóżmy na przykład, że przypadkowo ładuję http://evil.com/, co powoduje wysłanie żądania http://mail.google.com/. Gdyby SOP nie był na miejscu, a ja zalogowałem się do Gmaila, skrypt o evil.commógł zobaczyć moją skrzynkę odbiorczą. Jeśli witryna w evil.comchce się załadować mail.google.combez moich plików cookie, może po prostu użyć serwera proxy; publiczne treści mail.google.comnie są tajne (ale treść mail.google.com, do której moje pliki cookie mają dostęp, są tajne).

Zasady tego samego pochodzenia są egzekwowane po stronie klienta. Jeśli przeglądarka obsługuje CORS , serwer może odsyłać nagłówki, które nakazują przeglądarce wyjątki od zasad tego samego pochodzenia. Na przykład wysyłanie nagłówka

 Access-Control-Allow-Origin: www.example.com

poinformuje przeglądarkę, aby zezwoliła na prośby o pochodzenie z www.example.com.

 Access-Control-Allow-Origin: *

informuje przeglądarkę, aby zezwoliła na wszystkie żądania dotyczące różnych źródeł dla tego zasobu.

Serwery WWW zazwyczaj zapobiegają tego typu atakom, sprawdzając (niesławnie błędnie napisaną) Refererlinię w nagłówku HTTP, aby upewnić się, że żądanie pochodzi ze strony w ich własnej witrynie. Nie ma dobrego sposobu na ochronę przed złośliwym klientem, ale nie w ten sposób działają ataki XSRF.

Klient nie jest złośliwy; jest to zwykle zwykły użytkownik, który został nakłoniony przez złośliwą stronę trzecią do otwarcia dokumentu, który cicho wysyła żądanie HTTP za pomocą przechowywanych plików cookie klienta. Jeśli więc serwer może zweryfikować, Refererże żądanie HTTP pochodzi z gmail.com, a nie MyAwesomeWebsite.com, może zamknąć atak.

W jaki sposób serwery WWW egzekwują zasady tego samego pochodzenia?

Krótko mówiąc, nie robią tego, jak zauważyli apsillers i Dirk .
Jednym z ważnych powodów jest to, że nagłówek ACAO chroni same serwery przed szalonym DDOS, rozproszonymi atakami typu Denial of Service .

Kto:

ACAO jako nagłówek odpowiedzi HTTP jest przeznaczony do interpretacji przez klienta WWW, działając przy założeniu, że większość użytkowników Internetu przegląda sieć przez głównych dostawców przeglądarek, którzy przestrzegają i wdrażają zalecaną wersję roboczą W3C . Powinny przecież korzystać z szybkiego, dostępnego internetu.

W jaki sposób:

W przeciwnym razie każdy może po prostu skopiować i wkleić kilka wierszy kodu javascript w złośliwej witrynie, która działa w prostej pętli, co powoduje wysłanie żądania Ajax GET lub POST do obcej domeny. Bez interakcji użytkownika i możliwości wielowątkowości.

Dlatego musisz wyrazić zgodę na dostęp do witryny z różnych źródeł za pośrednictwem nagłówka HTTP ACAO . Użytkownik może uzyskać dostęp do tej witryny w dowolnym momencie poprzez interakcję świadomą użytkownika, tj. Łącze internetowe. Tak jak możesz świadomie kopiować lub wklejać zawartość do lub do schowka, ale nie w żaden inny sposób - oprócz wtyczek.

Przyszłość:

W tym momencie zapoznaj się z instrukcją producenta przeglądarki:

• domyślne usuwanie wtyczek , jako krok w kierunku środowiska w pełni piaskownicy i
• usunięcie opcji użytkownika, aby wyłączyć javascript

Ograniczenia bezpieczeństwa można przyzwoicie ustalić za pomocą kombinacji TSL 2/3, silnych identyfikatorów sesji, TAN, uwierzytelniania dwuskładnikowego itp.

„Google” ma to do pokazania i powiedzenia na temat DDOS

Wreszcie, każdy może swobodnie przesyłać proxy do dowolnej treści internetowej i dodawać żądany nagłówek ACAO, aby uzyskać dostęp do pośredniczonej zawartości krzyżowej. Podobnie ten serwer proxy jest wtedy tak samo otwarty na atak DDOS, jak pozwala na to ustawienie ACAO. Właściwie to nie znam żadnej darmowej oferty usług publicznych. Proszę, popraw mnie jeśli się mylę.

Jak powiedzieli inni, to zależy od klienta. Ale serwer może potrzebować poradzić sobie z XSS, który omija SOP.

Supopse serwer pozwala użytkownikom przesyłać treści, które są wyświetlane, gdy inni użytkownicy przeglądają Twoją witrynę. Ta strona jest dobrym przykładem - właśnie przesłałem treść i jest ona wyświetlana.
Jeśli moja treść zawiera <script>znacznik, a serwer po prostu skopiuje go do generowanego kodu HTML, wówczas uruchomiony skrypt zostanie uruchomiony.
Ponieważ skrypt został znaleziony w pliku HTML z pliku, ma on wszystkie uprawnienia do skryptu witryny. Może na przykład głosować za odpowiedzią. I dlatego ta odpowiedź ma tak wiele pozytywnych opinii.

Dobry serwer WWW (jak, niestety, ten, którego używa StackExchange), nie pozwoli na to. Może usunąć <script>znacznik lub uciec z niego, więc będzie widoczny, ale nie wykonany (ostrzeżenie - ta odpowiedź jest daleka od wiarygodnego przepisu, aby zapobiec XSS).

Więc to po stronie klienta wymusza SOP, ale w niektórych przypadkach serwer powinien działać, aby zapobiec jego obejściu.