2009-03-05 18 views
57

Czy są jakieś problemy z bezpieczeństwem, które należy wziąć pod uwagę podczas korzystania z JSONP?Czy JSONP jest bezpieczny w użyciu?

+0

strona jest naprawdę bezpieczna witryna ... chcę tylko wiedzieć, czy jest jakiś problem bezpieczeństwa z plikiem cookie przechowywanym przez mój serwer. –

+0

Poniższy link autorstwa naugtur daje dobre rozwiązanie i wnikliwe wyjaśnienie, w jaki sposób można go złamać i jak działa to rozwiązanie. Proszę spojrzeć. – minghua

+0

powiązane pytanie w celu rozwiązania problemów: [Czy możliwe jest utworzenie bezpiecznego żądania JSONP?] (Http://stackoverflow.com/q/16660145/1048572) – Bergi

Odpowiedz

61

Aktualizacja: JSONP jest powszechnym hackem do wykonywania żądań między domenami. Współczesne przeglądarki mają teraz Cross Origin Resource Sharing, a IE8 + ma XDomainRequest, który jest podobny. Aby uzyskać więcej informacji, patrz http://enable-cors.org/.

JSONP to tylko skrypt, który umożliwia korzystanie z oddzwaniania. Powinieneś jednak pamiętać o Cross-site request forgery (CSRF).

Dopóki kontrolujesz skrypt i serwer, JSONP nie jest już bardziej niebezpieczny niż zawiera skrypt. Chyba, że ​​masz usługę JSONP, która zwraca poufne dane do zalogowanych użytkowników. Złośliwa strona może wysłać żądanie do usługi (mając nadzieję, że użytkownik jest zalogowany w Twojej witrynie) i odzyskać dane. Usługa może sprawdzić stronę odsyłającą żądanie, ale możliwe jest sfałszowanie wywoływacza za pomocą lampy błyskowej (dzięki Chris Moschini).

Wyobraź sobie ten senario: - Użytkownik loguje się na swoje konto bankowości internetowej. Przechowywanie pliku cookie sesji w przeglądarce użytkowników. Ta strona ma serwis jsonp z poufnymi informacjami o użytkowniku i jego kontach. - Inne witryny nie będą wiedziały, że użytkownik jest zalogowany, ale mogliby się domyślić i spróbować uzyskać dostęp do usługi jsonp. Ponieważ użytkownik ma plik cookie sesji, przeglądarka otrzyma odpowiedź i nic nie powstrzyma strony przed wykonaniem posta ajaxowego, aby zapisać wrażliwe dane na swoim serwerze.

Aktualizacja 28 czerwca 2012: Jeśli chcesz, aby chronić przed CSRF atakuje powinieneś przeczytać ten w głębi blogu przez eksperta bezpieczeństwa: http://erlend.oftedal.no/blog/?blogid=130

+2

W innym miejscu podkreślono, że HTTP_REFERER można sfałszować za pomocą Flasha, więc wrażliwe dane, które serwer oferuje ponad jsonp, są podatne na ataki. –

+0

To tylko jedna strona ryzyka. Link naugtur pokazuje drugą stronę ryzyka i lepsze rozwiązanie tej części. – minghua

21

Tak, trzeba być ostrożnym, ale kiedy jest stosowany prawidłowo z zaufane usługi są względnie bezpieczne.

Oto podsumowanie kwestii bezpieczeństwa z jsonp, jak rozumiem:

Z punktu widzenia konsumenta:

  • Musisz zaufać usługodawcy nie powrócić złośliwy JavaScript zamiast oczekiwanego JSON owinięte w określeniu wywołania zwrotnego JSONP.
  • To samo dotyczy wszystkich wbudowanych dodatków JavaScript innych firm, takich jak Google Analytics.
  • Podobna jest tylko do ataków XSS, ponieważ umożliwia zewnętrznym stronom wykonywanie dowolnych skryptów JavaScript w aplikacji, jednak najpierw należy zaufać tej stronie trzeciej, wysyłając żądanie w pierwszej kolejności.

Z punktu widzenia usługodawcy:

  • Nie należy zakładać, że choć cookies (s) Klientów są obecne we wniosku, że konsument jest strona internetowa pod kontrolą. Sprawdź nagłówek Referer na białej liście autoryzowanych adresów URL i/lub nie korzystaj z uwierzytelniania opartego na plikach cookie.
  • Analogicznie do zastępczego ataku CSRF/zdezorientowanego.
12

Występują problemy bezpieczeństwa dla obu stron. Najpoważniejsza z nich dotyczy strony, w tym JSONP.

Jeśli dołączasz coś z innej domeny (której nie kontrolujesz), ta domena może w każdej chwili zmienić skrypt. Mogą sprawić, że javascript zrobi cokolwiek w kontekście twojej strony internetowej, którą mógłby zrobić twój własny javascript. Nie ma sposobu obejścia tego, jeśli używasz JSONP. Powinieneś zajrzeć do komunikacji między domenami za pomocą elementów iframe, najlepiej w doskonałej bibliotece EasyDXM.

Jeśli oferujesz usługę internetową, która obsługuje JSONP, musisz zabezpieczyć się przed fałszywymi żądaniami (CSRF). W tym miejscu Twoja usługa zwraca wrażliwe informacje zalogowanym użytkownikom. Jeśli użytkownik zalogował się do Twojej witryny, każda inna strona może wygenerować żądanie GET do usługi JSONP, a pliki cookie Twojej domeny są przesyłane wraz z żądaniem - w istocie, uwierzytelniając zalogowanego użytkownika - poza tym, że teraz domena otrzymuje odpowiedź i jest w stanie odczytać poufne dane!

Najlepszym sposobem zabezpieczenia się przed CSRF jest wygenerowanie numeru jednorazowego (numeru losowego, który jest trudny do odgadnięcia, losowo wygenerowany) i zapisanie go w sesji. Wypisz tę wartość we wszystkich swoich formularzach na swoich stronach internetowych i umieść ją we wszystkich żądaniach JSONP na TWOICH stronach. Na serwerze upewnij się, że numer jest obecny i poprawny w żądaniu (czy jest to GET, POST itd.). Inne domeny nie będą w stanie odgadnąć tego nonce, a zatem nie będą w stanie uzyskać wrażliwych informacji pomimo plików cookie. wysyłane.

Wreszcie istnieje inny rodzaj problemu związanego z bezpieczeństwem: JSONP po prostu nie obsługuje uwierzytelniania użytkownika w przeglądarce, takiego jakie jest możliwe w OAuth. Możesz oczywiście uzyskać serwer tokena dostępu (jak w OAuth) i użyć go. Jeśli jednak chcesz całkowicie uwierzytelniać się w przeglądarce, musisz używać komunikacji międzydomenowej z iFrame. Myślę, że tak właśnie działa OAuth 2.0. Oto, jak to skonfigurować: strony hostowane w Twojej witrynie mają pełny dostęp do Twojego serwera. Korzystaj z biblioteki javascript, która ładuje EasyDXM i używa jej do skonfigurowania ukrytej struktury iframe w Twojej witrynie i porozmawiaj z nią za jej pomocą.

Powiązane problemy