Polityka jednego pochodzenia i CORS - o co ci chodzi?

Question

Mam problem ze zrozumieniem polityki tego samego pochodzenia i różnych sposobów "obejścia" tej zasady.
Jest oczywiste, że polityka tego samego pochodzenia istnieje jako środek bezpieczeństwa, więc jeden skrypt pochodzący z serwera/domeny nie ma dostępu do danych pochodzących z innego serwera/domeny.
Jasne jest również, że czasami jest przydatna możliwość złamania tej reguły, więc na przykład aplikacja mashup uzyskuje dostęp do informacji z różnych serwerów w celu uzyskania pożądanych rezultatów. Jednym ze sposobów na to jest CORS.

1) Jeśli się nie mylę, CORS pozwala serwer docelowy powiedzieć przeglądarki „Jest OK, aby podjąć dane/kod z siebie” dodając kilka nagłówków w odpowiedzi. Ale jeśli jest to poprawne, oznacza to, że złośliwy serwer mógłby po prostu dodać ten nagłówek, a przeglądarka umożliwiłaby pobranie wszelkich danych lub kodu, potencjalnie szkodliwych, pochodzących z tego serwera.
2) Z drugiej strony mamy JSONP, który pozwala nam pobrać dowolny kod lub dane z serwera bez włączonego CORS, co pozwala uniknąć głównego celu SPO. Z drugiej strony złośliwy serwer, który może zarządzać JSONP, może wstrzykiwać dane lub kod nawet przy pomocy SOP w przeglądarce.
Moje pytania są następujące:

Czy druga argumentacja jest poprawna? Czy to decyzja serwera, czy przeglądarka musi zaakceptować zawartość? Czy druga argumentacja jest poprawna? To znowu nie jest w przeglądarce decyzji, czy akceptować dane, czy nie?
Czy JSONP nie czyni SOP bezużytecznym?

Dzięki za oświecenie mnie!

Answer 1

Ważne jest, aby pamiętać, jest to, że jeśli użytkownik jest zalogowany w witrynie http://example.com/ i wniosek http://example.com/delete?id=1 usuwa post przez użytkownika, a następnie następujący kod usunie posta użytkownika:

<script src="http://example.com/delete?id=1" /> 

Nazywa się to atakiem CSRF/XSRF (fałszowanie żądań między witrynami). To dlatego większość aplikacji internetowych po stronie serwera żądania bilet transakcji: zamiast http://example.com/delete?id=1 trzeba zrobić http://example.com/delete?id=1&txid=SomethingTheUserCannotGuess

Teraz po ataku nie będzie działać:

<script src="http://example.com/delete?id=1" /> 

... ponieważ nie zawierają parametr txid. Teraz zastanówmy się, co się stanie, jeśli dostęp do strony będzie możliwy za pomocą XmlHttpRequest. Skrypt działa na przeglądarce użytkownika mógłby za plecami użytkownika pobierać i analizować http://example.com/pageThatContainsDeleteLink, wyodrębnić txid a następnie zażądać http://example.com/delete?id=1&txid=SomethingTheUserCannotGuess

Teraz, jeśli XmlHttpRequest nie może uzyskać dostępu do witryn o różnym pochodzeniu, jedynym sposobem, aby spróbować odzyskać txid byłoby spróbuj zrobić coś takiego:

<script src="http://example.com/pageThatContainsDeleteLink" /> 

... ale to nie pomaga, ponieważ jest to strona HTML, a nie fragment kodu JavaScript. Istnieje więc powód, dla którego można dołączyć <skrypt>: s z innych witryn, ale nie można uzyskać dostępu do innych witryn za pośrednictwem XmlHttpRequest.

Możesz być zainteresowany przeczytaniem tego: http://haacked.com/archive/2008/11/20/anatomy-of-a-subtle-json-vulnerability.aspx/

Atak ten pracował na Gmaila z powrotem w ciągu dnia i pozwolił, aby pobrać maile użytkownika z kodu JavaScript uruchomione w innym miejscu. Wszystko to pokazuje, że model bezpieczeństwa WWW jest bardzo subtelny i nie do końca przemyślany. To ewoluowało zamiast być dobrze zaprojektowane.

Co do pytania: wydaje się, że serwer http://example.com/ jest złośliwy. Nie o to chodzi. Używając notatek z mojej odpowiedzi, serwer jest celem ataku, a strona atakującego to http://attacker.com/. Jeśli http://example.com/ otwiera możliwość wysyłania żądań za pomocą JSONP lub CORS, prawdą jest, że może stać się podatny na atak CSRF/XSRF, który właśnie opisałem. Nie oznacza to jednak, że inne witryny mogą zostać narażone na atak. Podobnie, jeśli http://attacker.com/ otwiera możliwość wysyłania żądań za pomocą JSONP lub CORS, strona atakującego właśnie stała się podatna na ataki CSRF/XSRF. W związku z tym administrator serwera, który nie jest dobrze poinformowany, może otworzyć dziurę we własnej witrynie, ale nie wpływa to na bezpieczeństwo innych witryn.