Co oznacza odpowiedź wywołania Ajax typu ' for (;;); {JSON data}'? [duplikat]

Podejrzewam, że głównym powodem jest kontrola. To zmusza do pobierania danych przez Ajax, a nie przez JSON-P lub podobny (który używa znaczników script, a więc zawiedzie, ponieważ pętla for jest nieskończona), a tym samym zapewnia, że ta sama polityka pochodzenia działa. Pozwala to im kontrolować, jakie dokumenty mogą wywoływać API - w szczególności tylko dokumenty, które mają takie samo pochodzenie jak to wywołanie API lub takie, do których Facebook przyznaje dostęp za pośrednictwem CORS (w przeglądarkach obsługujących CORS). Więc musisz zażądać danych za pomocą mechanizmu, w którym przeglądarka będzie egzekwować SOP, i musisz wiedzieć o tym przedmowie i usunąć go przed deserializacją danych.

Facebook ma mnóstwo programistów pracujących wewnętrznie nad wieloma projektami i bardzo często zdarza się, że ktoś popełnia drobny błąd; czy jest to coś tak prostego i poważnego, jak brak ucieczki danych wstawionych do szablonu HTML lub SQL, czy coś tak skomplikowanego i subtelnego, jak użycie eval (czasami nieefektywnego i prawdopodobnie niepewnego) lub JSON.parse (zgodne, ale nie powszechnie zaimplementowane rozszerzenie) zamiast "znanego dobrego" dekodera JSON, ważne jest, aby dowiedzieć się, jak łatwo egzekwowanie najlepszych praktyk w tej populacji deweloperów.

Aby stawić czoła temu wyzwaniu, Facebook ostatnio "na całego" z wewnętrznymi projektami zaprojektowanymi, aby z wdziękiem egzekwować te najlepsze praktyki, i szczerze mówiąc, jedynym wyjaśnieniem, które naprawdę ma sens w tym konkretnym przypadku, jest to, że: ktoś wewnętrznie zdecydował, że wszystkie parsowanie JSON powinno przejść przez pojedynczą implementację w ich podstawowej bibliotece, a najlepszym sposobem na egzekwowanie tego jest każda pojedyncza odpowiedź API, aby uzyskać for(;;); automatycznie przyklejany z przodu.

Robiąc to, programista nie może być "leniwy": zauważy natychmiast jeśli użyje eval(), zastanowi się, co się dzieje, a następnie uświadomi sobie swój błąd i skorzysta z zatwierdzonego API JSON.

Pozostałe odpowiedzi wydają się należeć do jednej z dwóch kategorii:

1. nieporozumienie JSONP, lub
2. nieporozumienie "porwanie JSONA".

Ci z pierwszej kategorii polegają na pomyśle, że napastnik może w jakiś sposób złożyć żądanie "używając JSONP" do API, które go nie obsługuje. JSONP jest protokołem, który musi być obsługiwany zarówno na serwerze, jak i na kliencie: wymaga od serwera zwrócenia czegoś podobnego do myFunction({"t":"continue"}), tak aby wynik został przekazany do funkcji lokalnej. Nie można po prostu "używać JSONP" przez przypadek.

Ci z drugiej kategorii powołują się na bardzo realną lukę, która została opisana, pozwalając na fałszowanie żądań między witrynami za pomocą tagów do interfejsów API, które nie używają JSONP (takich jak ten), pozwalając na formę "JSON hijacking". Odbywa się to poprzez zmianę konstruktora tablicy / obiektu, który umożliwia dostęp do informacji zwracanych z serwera bez funkcji owijania.

Jest to jednak po prostu niemożliwe w tym przypadku: powodem, dla którego to działa, jest to, że czysta tablica (jeden z możliwych wyników wielu interfejsów API JSON, takich jak słynny przykład Gmaila) jest poprawnym wyrażeniem, co nie jest prawdą w przypadku gołego obiektu.

W rzeczywistości, składnia obiektów zdefiniowanych przez JSON (która zawiera cudzysłowy wokół nazw pól, Jak pokazano w tym przykładzie) jest sprzeczna ze składnią bloków i dlatego nie może być używana na najwyższym poziomie skryptu.

js> {"t":"continue"}
typein:2: SyntaxError: invalid label:
typein:2: {"t":"continue"}
typein:2: ....^

Aby ten przykład był możliwy do wykorzystania poprzez remapowanie konstruktora Object (), wymagałoby to, aby API zamiast tego zwróciło obiekt wewnątrz zestawu nawiasów, czyniąc go poprawnym JavaScript (ale nie poprawnym JSON).

js> ({"t":"continue"})
[object Object]

Teraz, to Może być tak, że ta sztuczka z prefiksem for(;;); pojawia się tylko "przypadkowo" w tym przykładzie i jest w rzeczywistości zwracana przez inne wewnętrzne interfejsy API Facebook, które zwracają tablice; ale w tym przypadku należy to naprawdę zauważyć, ponieważ to byłaby "prawdziwa" przyczyna, dla której for(;;); pojawia się w tym konkretnym fragmencie.

Cóż, for(;;); jest nieskończoną pętlą (możesz użyć konsoli JavaScript Chrome, aby uruchomić ten kod w karcie, jeśli chcesz, a następnie oglądać użycie procesora w Menedżerze Zadań przejść przez dach, aż przeglądarka zabije kartę).

Więc podejrzewam, że może to być umieszczone tam, aby sfrustrować każdego, kto próbuje parsować odpowiedź za pomocą eval lub jakiejkolwiek innej techniki wykonującej zwrócone dane.

Aby wyjaśnić dalej, było dość powszechne, aby analizować trochę JSON-sformatowane dane za pomocą funkcji eval() JavaScript, wykonując coś w stylu:

var parsedJson = eval('(' + jsonString + ')');

...jest to jednak uważane za niebezpieczne, ponieważ z jakiegoś powodu Twoje dane sformatowane w JSON zawierają wykonywalny kod JavaScript zamiast (lub dodatkowo do) sformatowanych w JSON danych, kod ten będzie wykonywany przez eval(). Oznacza to, że jeśli rozmawiasz z niezaufanym serwerem lub jeśli ktoś kompromituje zaufany serwer, może uruchomić dowolny kod na twojej stronie.

Z tego powodu używanie rzeczy takich jak eval() do parsowania danych sformatowanych w formacie JSON jest generalnie źle widziane, a deklaracja for(;;); W JSON Facebook uniemożliwi ludziom przetwarzanie danych w ten sposób. Każdy, kto spróbuje, otrzyma nieskończoną pętlę. Zasadniczo Facebook Facebook stara się wymuszać, aby ludzie pracowali z jego API w sposób, który nie pozostawia ich podatnych na przyszłe exploity, które próbują przejąć interfejs API Facebooka, aby użyć go jako wektora.

To wygląda jak hack, aby zapobiec atakowiCSRF . Istnieją specyficzne dla przeglądarki sposoby łączenia się z tworzeniem obiektów, więc złośliwa witryna może najpierw to zrobić, a następnie wykonać następujące czynności:

<script src="http://0.131.channel.facebook.com/x/1476579705/51033089/false/p_1524926084=0" />

Gdyby nie było nieskończonej pętli przed JSONEM, powstałby obiekt, ponieważ JSON może być eval()ed jako javascript, a Hooki wykrywałyby go i wąchały elementy obiektu.

Teraz, jeśli odwiedzasz tę stronę z przeglądarki, po zalogowaniu się na Facebook, to może dostać się na swoje dane tak, jakby to było ty, a następnie wysłać je z powrotem do własnego serwera za pośrednictwem np. AJAX lub javascript post.