Nie widzę, jak funkcja zwrotna w JSONP różni się od funkcji zwrotnej sukcesu w AJAX.Nie rozumiem, jak JSONP jest KAŻDĄ różną od AJAX
Biorąc pod uwagę # 1, nie widzę, jak to jest fundamentalnie bezpieczniejsze.
Czy jedyna różnica polega na sztucznym ograniczeniu domeny z AJAX?
Dlaczego AJAX nie zezwala na żądania w wielu domenach; jeśli może to spowodować lukę w zabezpieczeniach, czy atak XSS nie byłby żądaniem JSONP?
Confused, Max
wywołanie AJAX jest faktyczna żądania HTTP bezpośrednio od klienta do serwera. Wywołania Ajax mogą być synchroniczne (blokowanie aż do zakończenia) lub asynchroniczne. Ze względu na zabezpieczenia pochodzące z tego samego źródła, wywołania ajax mogą być wykonywane tylko na tym samym serwerze, z którego pochodzi strona internetowa, chyba że serwer docelowy wyraźnie zezwala na żądanie pochodzenia krzyżowego przy użyciu CORS.
Połączenia JSONP są interesującym hackerem ze znacznikiem <script>, który umożliwia komunikację krzyżową. W wywołaniu JSONP klient tworzy znacznik skryptu i umieszcza na nim adres URL z parametrem zapytania callback=xxxx. To żądanie skryptu (poprzez wstawienie znacznika skryptu) jest wysyłane przez przeglądarkę do serwera zagranicznego. Przeglądarka po prostu myśli, że żąda jakiegoś kodu javascript. Następnie serwer tworzy specjalny javascript dla celów tego wywołania, a w tym javascript, który zostanie wykonany przez przeglądarkę po jego zwróceniu, serwer wywołuje funkcję do funkcji o nazwie w parametrze zapytania callback=xxxx. Poprzez zdefiniowanie zmiennych poprzez przekazanie danych do tej funkcji, serwer może przekazać dane z powrotem do klienta. W przypadku JSONP zarówno klient, jak i serwer muszą współpracować w zakresie działania wywołania JSONP i sposobu definiowania danych. Klient nie może nawiązać połączenia JSONP z serwerem, który nie obsługuje jawnie JSONP, ponieważ dokładny typ odpowiedzi JSONP musi zostać zbudowany przez serwer lub nie będzie działał.
Tak więc obie metody komunikacji działają zupełnie inaczej. Tylko wywołania ajax mogą być synchroniczne. Z natury wstawiania znaczników <script>, wywołania JSONP są zawsze asynchroniczne.
W wywołaniu Ajax odpowiedź powraca w obsłudze zdarzeń ajax.
W wywołaniu JSONP odpowiedź przychodzi, gdy zwrócony Javascript wywołuje funkcję użytkownika.
Pod pewnymi względami JSONP to luka w zabezpieczeniach, która omija mechanizm bezpieczeństwa krzyżowego. Ale można tylko wywoływać serwery, które jawnie wybierają obsługę mechanizmu podobnego do JSONP, więc jeśli serwer nie chce, aby można było go nazwać pochodzeniem krzyżowym, może temu zapobiec, nie wspierając JSONP. Nie możesz wykonywać zwykłych wywołań ajaxów na tych innych serwerach.
Twórcy przeglądarki naprawdę nie mogą zamknąć tej luki, ponieważ gdyby zliberiony stron internetowych się zepsuły, to albo już używają JSONP albo ładują skrypty z innych domen. Na przykład każda strona w sieci korzystająca z jQuery z sieci CDN firmy Google lub Microsoft zostanie przerwana, ponieważ przeglądarka nie będzie mogła pobierać kodu javascript z domen różnych domen.
JSONP został w dużej mierze wymyślony jako obejście, aby móc wysyłać żądania krzyżowe.Ponieważ jednak JSONP wymaga jawnej obsługi serwera w celu działania, nie był to tak naprawdę problem związany z bezpieczeństwem, ponieważ wywołanie JSONP może być wywołane tylko na serwerze, który wyraźnie zdecydował się zezwolić na ten typ wywołania o krzyżowym pochodzeniu. JSONP jest teraz używany znacznie mniej niż kiedyś, ponieważ CORS został wymyślony jako bardziej elegancki sposób kontrolowania/zezwalania na to. CORS oznacza Cross Origin Resource Sharing i zapewnia serwerowi docelowemu informację o tym, jaki typ żądań pochodzenia krzyżowego jest dozwolony, a nawet o tym, które domeny stron internetowych mogą wysyłać takie żądania. Ma on znacznie lepszą kontrolę niż JSONP i wszystkie nowoczesne przeglądarki obsługują teraz CORS.
Oto przykład, w jaki sposób wywołanie krzyżowe powoduje problemy. Jeśli możesz załadować dowolną dowolną stronę WWW z dowolnej innej strony internetowej lub wykonać dowolne wywołanie ajaxowe, to wyobraź sobie, że byłeś już zalogowany do swojego interfejsu poczty internetowej na Yahoo w innym oknie przeglądarki. Oznacza to, że pliki cookie są ustawione tak, aby umożliwić żądaniom przeglądarki pobieranie danych z Yahoo. Jeśli javascript na innej stronie internetowej pozwoliłby na wysłanie żądania Yahoo do Yahoo (automatycznie dołączającego pliki cookie), wówczas mógł pobrać wszystkie dane poczty internetowej i wysłać je z powrotem do swojej strony. Jedna strona internetowa może zedrzeć wszystkie zalogowane dane z dowolnej innej strony internetowej. Wszystkie zabezpieczenia sieciowe zostaną zerwane.
Ale tak, jak mamy to dzisiaj, dopóki Yahoo nie obsługuje interfejsu JSONP, który używa tych samych ciasteczek sieciowych, jest bezpieczny przed nieautoryzowanymi żądaniami JSONP.
Oto kilka innych dobrych writeups o zagrożeniach związanych z cross-pochodzenia ajax i dlatego musi być zabezpieczone:
Why the cross-domain Ajax is a security concern?
Why Cross-Domain AJAX call is not allowed?
Why are cross-domain AJAX requests labelled as a "security risk"?
Dzięki za odpowiedź. Ale mam kilka pytań dotyczących twojej odpowiedzi. Po pierwsze, kiedy mówisz "wywołanie ajax jest faktycznym żądaniem HTTP", czy sugerujesz, że JSONP nie jest? Po drugie, nie widzę powodu, dla którego odpowiedzi serwera JSONP muszą być wywołaniami funkcji, ponieważ jeśli może wywołać funkcję, to musi być w stanie wykonać dowolne instrukcje. Po trzecie, zawsze uważałem, że
Podstawową różnicą jest to, że z jakiegoś powodu ładowanie plików javascript zlokalizowanych w innych domenach (za pomocą znacznika skryptu) jest całkowicie w porządku, ale domyślnie nie jest w porządku ładowanie innych zasobów w wielu domenach.
Jestem z wami, ponieważ rozgraniczenie wydaje się dość arbitralne. W
jQuery, gdy wykonujesz wywołanie JSONP, efektywnie tworzysz znacznik skryptu, ładując zasób, a następnie biblioteka jQuery wykonuje skrypt, wywołując funkcję zdefiniowaną w tym wyniku JSONP.W moich oczach nie mogę myśleć o dodatkowym wektorze ataku wprowadzonym przez zezwolenie na istnienie domeny AJAX, która nie jest już szeroko otwarta, umożliwiając ładowanie skryptów krzyżowych, co jest powszechną praktyką stosowaną wszędzie (jQuery by googleCDN, skrypty reklamowe , google analytics i niezliczone inne).
Od wikipedia
In addition, many legacy cross-domain operations predating JavaScript are not subjected to same-origin checks; one such example is the ability to include scripts across domains, or submit POST forms.Źródło
2012-04-23 23:53:20 Nucleon
Dzięki za odpowiedź. Ale jeśli tak jest, czy przeglądarki nie powinny po prostu usuwać ograniczenia pochodzenia? Nie zmniejszyłoby to bezpieczeństwa, ale może tylko ułatwić i uprościć programowanie. – Max
@Max and Nucleon - przeczytaj ostatnie dwa akapity mojej odpowiedzi (właśnie skończyłem je dodawać), które opisują poważny problem z wywoływaniem ajaxów pochodzących z różnych źródeł. – jfriend00
@ jfriend00 przekonała mnie bobrzenna odpowiedź na temat CSRF. Dzięki za zamieszczenie linku! – Max
zwrotna jsonp jest nie rzeczywiste zwrotna. Zamiast tego, JSONP działa przez wstrzyknięcie skryptu. Na przykład, jeśli chcesz nawiązać połączenie jsonp, wstawić ten element skryptu do DOM:
odpowiedź serwera będzie coś takiego:
Będzie oceniano w globalny zasięg okna.Zasadniczo JSONP jest jak zdalny
exec(), gdzie serwer jest informowany o tym, jaki łańcuch należy utworzyć, aby go wykonać.To bardzo różne z Ajax: z jsonp, odpowiedź jest oceniano w zasięgu globalnym skryptu; z XMLHttpRequest, odpowiedź jest odbierana jako ciąg i nie jest oceniana. (JSONP może być używany tylko z GET, podczas gdy AJAX dopuszcza dowolną metodę http.)
Tak więc do twojego drugiego numeru, "Nie widzę, jak to jest fundamentalnie bezpieczniejsze." Cóż, masz rację, JSONP jest w rzeczywistości bardzo niezabezpieczony . Serwer może zwrócić dowolny skrypt, który chce, i zrobić wszystko, co chce w przeglądarce!
Żądania międzydomenowe nie są bezpieczne, ponieważ można ich użyć do ujawnienia informacji o bieżącej stronie na stronie w innej domenie.
Masz rację, że każdy atak XSS może po prostu użyć JSONP. Celem CORS nie jest zapobieganie XSS (jeśli masz niezaufane skrypty działające na twojej stronie, to i tak jesteś podcięty).
Źródło
2012-04-24 00:05:00