Zapobiega ujawnieniu odpowiedzi poprzez porwanie JSON.

Teoretycznie zawartość odpowiedzi HTTP jest chroniona tą samą Polityką pochodzenia: strony z jednej domeny nie mogą pobierać żadnych informacji ze stron z drugiej domeny (chyba że jest to wyraźnie dozwolone).

Atakujący może żądać stron w innych domenach w Twoim imieniu, np. używając znacznika <script src=...> lub <img>, ale nie może uzyskać żadnych informacji o wyniku (nagłówki, zawartość).

Tak więc, jeśli odwiedzisz strona atakującego, nie mogła odczytać twojego maila z gmail.com.

Z wyjątkiem tego, że podczas używania znacznika script do żądania zawartości JSON, JSON jest wykonywany jako JavaScript w kontrolowanym środowisku atakującego. Jeśli atakujący może zastąpić tablicę lub konstruktor obiektu lub inną metodę używaną podczas budowy obiektu, wszystko w JSON przejdzie przez kod atakującego i zostanie ujawnione.

Zauważ, że dzieje się tak w momencie, gdy JSON jest wykonywany jako JavaScript, a nie w czas to przeanalizować.

Istnieje wiele środków zaradczych:

Upewnianie się, że JSON nigdy nie wykonuje

Umieszczając instrukcję while(1); przed danymi JSON, Google upewnia się, że dane JSON nigdy nie są wykonywane jako JavaScript.

Tylko legalna strona może pobrać całą zawartość, usunąć while(1); i przetworzyć resztę jako JSON.

Rzeczy takie jak for(;;); były widziane na przykład na Facebook, z takimi samymi wynikami.

Upewnienie się, że JSON jest not valid JavaScript

Podobnie, dodanie nieprawidłowych tokenów przed JSON, jak &&&START&&&, zapewnia, że nigdy nie zostanie on wykonany.

Zawsze zwracaj JSON z obiektem Na Zewnątrz

To jestzalecany przez OWASP sposób ochrony przed porwaniem JSON i jest mniej inwazyjny.

Podobnie jak poprzednie przeciwdziałanie, zapewnia, że JSON nigdy nie jest wykonywany jako JavaScript.

Poprawny obiekt JSON, gdy nie jest zamknięty niczym, nie jest valid in JavaScript:

eval('{"foo":"bar"}')
// SyntaxError: Unexpected token :

Jest to jednak poprawne JSON:

JSON.parse('{"foo":"bar"}')
// Object {foo: "bar"}

Tak więc, upewnienie się, że zawsze zwracasz Obiekt na najwyższym poziomie odpowiedzi upewnia się, że JSON nie jest poprawnym JavaScript, podczas gdy nadal jest poprawnym JSON.

Jak zauważył @hvd w komentarzach, pusty obiekt {} jest prawidłowym JavaScript, a wiedząc, że obiekt jest pusty może być cenną informacją.

Porównanie powyższych metod

Sposób OWASP jest mniej inwazyjny, ponieważ nie potrzebuje biblioteka klienta zmienia i przenosi poprawny JSON. Nie jest jednak pewne, czy przeszłe lub przyszłe błędy przeglądarki mogłyby to pokonać. Jak zauważył @oriadam, nie jest jasne, czy dane mogły zostać wycieknięte w błędzie analizy poprzez obsługę błędów (np. window.onerror).

Obie metody wymagają zmian po stronie serwera w celu unikaj przypadkowego wysyłania przez deweloperów podatnego JSON.

Ma to na celu zapewnienie, że inna strona nie może robić paskudnych sztuczek, aby spróbować ukraść Twoje dane. Na przykład, poprzez zastąpienie konstruktora tablicy , a następnie włączenie tego adresu URL JSON za pomocą znacznika<script>, złośliwa strona trzecia może ukraść dane z odpowiedzi JSON. Po umieszczeniu while(1); na początku skrypt zostanie zawieszony.

Żądanie z tej samej strony przy użyciu XHR i oddzielnego parsera JSON, z drugiej strony, może łatwo zignorować prefiks while(1);.

Byłoby to trudne dla osób trzecich, aby wstawić odpowiedź JSON do dokumentu HTML z tagiem <script>. Pamiętaj, że znacznik <script> jest zwolniony z tej samej polityki pochodzenia .

Uwaga: od 2019 r. wiele starych luk, które prowadzą do środków zapobiegawczych omówionych w tym pytaniu, nie jest już problemem we współczesnych przeglądarkach. Odpowiedź zostawię poniżej jako ciekawostkę historyczną, ale tak naprawdę cały temat zmienił się radykalnie od 2010 roku (!!), kiedy to zostało zapytane.

Uniemożliwia użycie go jako celu prostego znacznika <script>. (Cóż, to nie zapobiega, ale sprawia, że nieprzyjemne.) That way bad guys can ' t just put ten znacznik skryptu we własnej witrynie i polegać na aktywnej sesji, aby umożliwić pobieranie treści.

edit - zwróć uwagę na komentarz (i inne odpowiedzi). Problem dotyczy wywrotowych obiektów wbudowanych, w szczególności konstruktorów Object i Array. Te mogą być zmienione tak, że w przeciwnym razie nieszkodliwy JSON, po przetworzeniu, może wywołać kod atakujący.

Ponieważ znacznik <script> jest wyłączony z tej samej polityki Origin, która jest koniecznością bezpieczeństwa w świecie sieci, while(1) po dodaniu do odpowiedzi JSON zapobiega jego niewłaściwemu wykorzystaniu w znaczniku <script>.

Po uwierzytelnieniu JSON hijacking protection może zająć różnorodność form. Google dodaje while(1) do swoich danych JSON, więc że jeśli jakiś złośliwy skrypt go oceni, złośliwy skrypt wejdzie nieskończona pętla.

Reference: Web Security Testing Cookbook: Systematic Techniques to Find Problems Fast

Ponieważ jest to post o dużym natężeniu ruchu, mam nadzieję, że udzielę tutaj odpowiedzi nieco bardziej nieokreślonej na pierwotne pytanie, a tym samym dostarczę dalsze tło na temat ataku porwania JSON i jego konsekwencji.]} [12]}JSON Hijacking, jak sama nazwa wskazuje, jest atakiem podobnym do Cross-Site Request Forgery, w którym atakujący może uzyskać dostęp do poufnych danych JSON z różnych domen z aplikacji, które zwracają poufne dane jako literały tablicy, aby uzyskać żądania. Przykład wywołania JSON zwracającego tablicę literal jest pokazany poniżej:

[{"id":"1001","ccnum":"4111111111111111","balance":"2345.15"}, 
{"id":"1002","ccnum":"5555555555554444","balance":"10345.00"}, 
{"id":"1003","ccnum":"5105105105105100","balance":"6250.50"}]

Ten atak można osiągnąć w 3 głównych krokach:

Krok 1: poproś uwierzytelnionego użytkownika o odwiedzenie złośliwej strony. Krok 2: złośliwa strona spróbuje uzyskać dostęp do poufnych danych z aplikacji, do której użytkownik jest zalogowany.Można to zrobić poprzez osadzenie znacznika skryptu na stronie HTML, ponieważ zasada tego samego pochodzenia nie ma zastosowania do znaczników skryptu.

<script src="http://<jsonsite>/json_server.php"></script>

Przeglądarka wyśle żądanie GET do json_server.php i wszelkie uwierzytelniające pliki cookie użytkownika zostanie wysłany wraz z żądaniem. Krok 3: w tym momencie, gdy złośliwa witryna wykonała skrypt, nie ma dostępu do żadnych poufnych danych. Uzyskanie dostępu do danych można uzyskać za pomocą obiektu prototype setter. W poniższym kodzie właściwość prototypy obiektu jest powiązana z zdefiniowaną funkcją, gdy podejmowana jest próba ustawienia właściwości" ccnum".

Object.prototype.__defineSetter__('ccnum',function(obj){

secrets =secrets.concat(" ", obj);

});

W tym momencie złośliwa strona z powodzeniem przechwyciła poufne dane finansowe (ccnum) Return byjson_server.php JSON

Należy zauważyć, że nie wszystkie przeglądarki obsługują tę metodę; proof of concept został wykonany na Firefoksie 3.x. ta metoda została wycofana i zastąpiona przez useObject.defineProperty Istnieje również odmiana tego ataku, która powinna działać na wszystkich przeglądarkach, w których zwracany jest pełny JavaScript (np. pi=3.14159) zamiast tablicy JSON.

• Ponieważ znaczniki skryptu mogą generować tylko HTTP Pobieraj żądania, zwracaj tylko obiekty JSON do wysłania prośby.

• Uniemożliwia przeglądarce internetowej interpretację obiektu JSON jako poprawnego kodu JavaScript.

• Zaimplementuj ochronę Cross-Site Request Forgery, wymagając, aby predefiniowana losowa wartość była wymagana dla wszystkich żądań JSON.

Więc jak widzisz While(1) jest pod ostatnią opcją. Najprościej mówiąc, while(1) jest nieskończoną pętlą, która będzie działać aż do wyrażenia break wydane wyraźnie. A więc to, co byłoby opisane jako blokada dla klucza, który ma być zastosowany(Google break statement). Dlatego porwanie JSON, w którym haker nie ma klucza, będzie konsekwentnie odrzucane.Niestety, jeśli czytasz blok JSON za pomocą parsera, pętla while(1) jest ignorowana.

Podsumowując, pętla while(1) może łatwiej wizualizować jako prosty szyfr instrukcji złamania, który google może używać do kontrolowania przepływu danych.

Jednak słowo kluczowe w tym stwierdzeniu to słowo " proste ". Korzystanie z uwierzytelnionych pętli nieskończonych zostało na szczęście usunięte z podstawowej praktyki w latach od 2010 roku ze względu na jego absolutne dziesiątkowanie użycia procesora, gdy izolowane (i fakt, że internet odszedł od wymuszania przez prymitywne "szybkie poprawki"). Dziś zamiast tego baza kodowa ma wbudowane środki zapobiegawcze, a system nie jest już kluczowy ani skuteczny. (częścią tego jest przejście od porwania JSON do bardziej owocnego techniki datafarming, w które nie będę się obecnie wdawać)

*