Co sprawia, że ​​domena z domeną ajax jest niepewna?

Question

Nie jestem pewien, czy rozumiem, jakie rodzaje usterek to powoduje.

Kiedy potrzebuję uzyskać dostęp do danych z interfejsu API, muszę użyć ajaxa, aby zażądać pliku PHP na moim własnym serwerze, a ten plik PHP uzyskuje dostęp do interfejsu API. Co sprawia, że ​​jest to bezpieczniejsze niż po prostu pozwala mi bezpośrednio trafić API za pomocą ajax?

W tym przypadku wygląda na to, że przy użyciu JSONP http://en.wikipedia.org/wiki/JSONP można zrobić wszystko, co można zrobić w domenie ajaxowej.

Czy ktoś mógłby mnie oświecić?

Answer 1

Myślę, że nie rozumiesz problemu, który stara się rozwiązać polityka tego samego pochodzenia.

Wyobraź sobie, że jestem zalogowany do Gmaila i że Gmail ma zasoby JSON, http : //mail.google.com/information-about-current-user.js, z informacjami o zalogowanym użytkowniku. Ten zasób prawdopodobnie ma być używany przez interfejs użytkownika Gmaila, ale jeśli nie jest to polityka tego samego pochodzenia, każda odwiedzana przeze mnie strona, która podejrzewa, że ​​mogę być użytkownikiem Gmaila, może uruchomić żądanie AJAX, aby to zrobić zasób jako ja i pobieraj informacje o mnie, bez Gmaila, który jest w stanie bardzo dużo z tym zrobić.

Polityka tego samego pochodzenia nie chroni twojej strony PHP przed witryną strony trzeciej; i nie ma to na celu ochrony kogoś odwiedzającego twoją stronę PHP od strony trzeciej; Chodzi raczej o to, aby chronić kogoś odwiedzającego twoją stronę PHP i wszelkie strony osób trzecich, do których mają specjalny dostęp, ze swojej strony PHP. ("Specjalny dostęp" może być spowodowany plikami cookie, lub AUTH HTTP lub białą listą adresów IP, lub po prostu być w odpowiedniej sieci — być może ktoś pracuje w NSA i odwiedza twoją stronę, co nie znaczy, że powinieneś być jest w stanie wywołać zrzut danych z wewnętrznej strony NSA.)

JSONP obchodzi to w bezpieczny sposób, wprowadzając inne ograniczenie: działa tylko wtedy, gdy zasobem jest JSONP. Jeśli więc Gmail chce, aby dany zasób JSON był użyteczny dla stron trzecich, może obsługiwać JSONP dla tego zasobu, ale jeśli chce, aby ten zasób był użyteczny przez jego własny interfejs użytkownika, może obsługiwać tylko zwykły JSON.

Answer 2

Przy użyciu skryptów krzyżowych, strona internetowa mogłaby pobierać dane z dowolnego miejsca, a następnie działać w tym samym kontekście, co pozostałe dane na stronie i teoretycznie mieć dostęp do pliku cookie i inne informacje o zabezpieczeniach, których nie chciałbyś mieć również podany. Skrypty typu "cross site" byłyby bardzo niepewne pod tym względem, ponieważ byłbyś w stanie przejść na dowolną stronę, a jeśli jest to dozwolone, skrypt na tej stronie mógł po prostu załadować dane z dowolnego miejsca, a następnie rozpocząć wykonywanie złego kodu, a więc powód, dla którego nie jest dozwolony.

JSONP z drugiej strony pozwala uzyskać dane w formacie JSON, ponieważ zapewnia niezbędne wywołanie zwrotne, że dane są przekazywane, dlatego daje miarę kontroli, że dane nie będą wykonywane przez przeglądarkę, chyba że wywołanie zwrotne funkcja wykonuje i wykonuje lub próbuje go wykonać. Dane będą w formacie JSON, który można następnie zrobić, co chcesz, jednak nie zostanie wykonany, dlatego jest bezpieczniejszy, a więc z tego powodu.

Answer 3

Wiele usług internetowych nie jest zaprojektowanych tak, aby były odporne na XSRF, więc jeśli witryna internetowa może programowo ładować dane użytkownika za pomocą żądania, które przenosi pliki cookie w wielu domenach na podstawie użytkownika, który odwiedził witrynę, każdy mający możliwość uruchom javascript może wykraść dane użytkownika.

CORS to planowana bezpieczna alternatywa dla XHR, która rozwiązuje problem przez not carrying credentials by default. Specyfikacja CORS wyjaśnia problem:

Aplikacje użytkownika zwykle stosują ograniczenia tego samego pochodzenia do żądań sieci. Ograniczenia te uniemożliwiają aplikacjom WWW po stronie klienta działającym od jednego źródła uzyskanie danych pobranych z innego źródła, a także ograniczają niebezpieczne żądania HTTP, które mogą być automatycznie uruchamiane w kierunku miejsc docelowych, które różnią się od źródła uruchomionej aplikacji.

W programach klienckich zgodnych z tym wzorcem, żądania sieciowe zazwyczaj używają uwierzytelniania otoczenia i informacji zarządzania sesją, w tym uwierzytelniania HTTP i informacji cookie.

EDIT:

Problem właśnie czyni pracę XHR między domenami jest to, że wiele usług internetowych wystawiać ambient authority. Zwykle ten organ jest dostępny tylko dla kodu z tego samego pochodzenia.

Oznacza to, że użytkownik, który ufa stronie internetowej, ufa wszystkim kodom z tej witryny prywatnymi danymi. Użytkownik ufa serwerowi, do którego wysyła dane, oraz wszelkiemu kodowi załadowanemu przez strony obsługiwane przez ten serwer. Kiedy ludzie za stroną internetową i bibliotekami, które ładuje, są godni zaufania, zaufanie użytkownika jest dobrze umiejscowione.

Jeśli XHR pracował z różnymi źródłami i nosił pliki cookie, ten organ otoczenia mógł udostępniać kod każdemu, kto może podać kod użytkownikowi. Decyzje o zaufaniu, które wcześniej podjął użytkownik, nie mogą już być dobrze umiejscowione.

CORS nie dziedziczy tych problemów, ponieważ istniejące usługi nie wystawiają uprawnień otoczenia do CORS.

Answer 4

Wzorzec z JS->Server(PHP)->API umożliwia i nie tylko najlepsze, ale również niezbędne do zachowania zdrowia, sprawdzanie, co dostajesz, gdy przechodzi przez serwer. Oprócz tego rzeczy takie jak poisened local resolvery (alias DNS Worms) itp. Są znacznie mniej prawdopodobne na serwerze niż na przypadkowym kliencie.

Co do JSONP: To nie jest laska, ale kula. IMHO może to być postrzegane jako exploit przeciwko błędom kombinacji HTML/JS, których nie można usunąć bez zerwania istniejącego kodu. Inni mogą myśleć inaczej.

Podczas JSONP pozwala Ci unreflectedly wykonać kod z somwhere w złym szerokim świecie, nikt siły, aby to zrobić. Śmiałe implementacje JSONP zawsze używają jakiegoś skrótu, aby sprawdzić, czy dostawca tego kodu jest wiarygodny. Znowu inni mogą myśleć inaczej.

Answer 5

Urządzenie original XHR nigdy nie zostało zaprojektowane w taki sposób, aby zezwalać na żądania różnych źródeł. Powodem była konkretna luka w zabezpieczeniach znana głównie pod numerem CSRF attacks.

W tym scenariuszu ataku witryna osoby trzeciej może zmusić agenta użytkownika ofiary do wysłania sfałszowanych, ale ważnych i zgodnych z prawem żądań do witryny źródłowej. Z punktu widzenia serwera źródłowego takie sfałszowane żądanie nie jest niedostrzegalne na podstawie innych żądań tego użytkownika zainicjowanych przez strony internetowe serwera źródłowego. Powodem tego jest fakt, że jest to agent użytkownika, który wysyła te żądania, a ponadto automatycznie uwzględniałby wszelkie poświadczenia, takie jak pliki cookie, uwierzytelnianie HTTP, a nawet certyfikaty SSL po stronie klienta.

Teraz takie wnioski można łatwo sfałszować: Rozpoczynając od prostych żądań GET, za pomocą <img src="…">, aż do żądań POST, za pomocą formularzy i przesyłając je automatycznie.Działa to tak długo, jak długo można przewidzieć, jak fałszować takie ważne żądania.

Ale to nie jest główny powód, dla którego nie wolno zgłaszać żądań krzyżowych dotyczących XHR. Ponieważ, jak pokazano powyżej, istnieją sposoby na fałszowanie żądań nawet bez XHR, a nawet bez JavaScript. Nie, głównym powodem, dla którego XHR nie dopuszcza wniosków o krzyżowe pochodzenie, jest to, że jest to JavaScript na stronie strony trzeciej, do której zostanie wysłana odpowiedź. Tak więc nie byłoby możliwe wysyłanie żądań o różnych nazwach pochodzenia, ale także otrzymywanie odpowiedzi, która może zawierać poufne informacje, które byłyby wtedy dostępne przez JavaScript.

Dlatego oryginalna specyfikacja XHR nie zezwalała na żądania różnych źródeł. Jednak wraz z rozwojem technologii pojawiły się uzasadnione wnioski o poparcie wniosków o krzyżowe pochodzenie. Dlatego oryginalna specyfikacja XHR została rozszerzona na XHR level 2 (XHR i XHR poziom 2 są teraz połączone), gdzie głównym rozszerzeniem jest obsługa żądań krzyżowych w ramach określonych wymagań, które są określone jako CORS. Teraz serwer ma możliwość sprawdzenia pochodzenia żądania, a także może ograniczyć zbiór dozwolonych początków, a także zestaw dozwolonych metod HTTP i pól nagłówka.

Teraz do JSONP: Aby uzyskać odpowiedź JSON z żądania w JavaScript i móc ją przetworzyć, musi to być żądanie tego samego pochodzenia lub, w przypadku żądania połączenia krzyżowego, serwer i agent użytkownika musiałby obsługiwać CORS (z których ten ostatni jest obsługiwany tylko przez nowoczesne przeglądarki). Ale aby móc pracować z dowolną przeglądarką, wymyślono JSONP, który jest po prostu ważnym połączeniem funkcji JavaScript z JSON jako parametrem, który można załadować jako zewnętrzny JavaScript przez <script>, który podobnie jak <img>, nie jest ograniczony do tego samego pochodzenia upraszanie. Ale tak samo jak każde inne żądanie, żądanie JSONP jest również podatne na CSRF.

więc zawrzeć ją z punktu widzenia bezpieczeństwa:

• XHR wymagane jest, aby wnioski o zasobach JSON, aby uzyskać ich reakcje w JavaScript
• XHR2/CORS jest zobowiązany do żądania krzyż pochodzenia dla zasobów JSON, aby uzyskać ich reakcje w JavaScript
• JSONP jest obejście w celu obejścia żądania krzyż pochodzenia z XHR

ale również:

• Kucie żądania jest śmiesznie łatwe, chociaż kucie ważnych i uzasadnionych żądań jest trudniejsze (ale często bardzo proste, jak również)
• ataki CSRF są nie należy lekceważyć zagrożenia, więc nauczyć się protect against CSRF