Waarom zet Google while(1);
in hun (prive) JSON antwoorden?
Bijvoorbeeld, hier's een reactie tijdens het aan- en uitzetten van een agenda in Google Agenda:
while(1);[['u',[['smsSentFlag','false'],['hideInvitations','false'],
['remindOnRespondedEventsOnly','true'],
['hideInvitations_remindOnRespondedEventsOnly','false_true'],
['Calendar ID stripped for privacy','false'],['smsVerifiedFlag','true']]]]
Ik zou aannemen dat dit is om te voorkomen dat mensen er een eval()
op doen, maar alles wat je'zou moeten doen is de while
vervangen en dan ben je klaar'd. Ik zou aannemen dat de eval preventie is om ervoor te zorgen dat mensen veilige JSON parsing code schrijven.
Ik'heb dit ook op een paar andere plaatsen gebruikt zien worden, maar veel meer bij Google (Mail, Agenda, Contacten, etc.) Vreemd genoeg begint Google Docs in plaats daarvan met &&&START&&&
, en Google Contacten lijkt te beginnen met while(1); &&&START&&&
.
Wat's hier aan de hand?
Dit is om ervoor te zorgen dat een andere site geen gemene trucs kan uithalen om te proberen je gegevens te stelen. Bijvoorbeeld, door de array constructor te vervangen, en dan deze JSON URL op te nemen via een <script>
tag, zou een kwaadwillende derde site de gegevens van het JSON antwoord kunnen stelen. Door een while(1);
aan het begin te plaatsen, zal het script in plaats daarvan hangen.
Een verzoek van dezelfde site dat XHR gebruikt en een aparte JSON parser, aan de andere kant, kan gemakkelijk de while(1);
prefix negeren.
Dat zou zijn om het voor een derde partij moeilijk te maken om het JSON antwoord in een HTML document in te voegen met de <script>
tag. Vergeet niet dat de <script>
tag is vrijgesteld van de Same Origin Policy.
Note: vanaf 2019 zijn veel van de oude kwetsbaarheden die leiden tot de preventieve maatregelen die in deze vraag worden besproken, niet langer een probleem in moderne browsers. Ik'laat het antwoord hieronder staan als een historische curiositeit, maar eigenlijk is het hele onderwerp radicaal veranderd sinds 2010 (!!) toen dit werd gevraagd.
Het voorkomt dat het gebruikt kan worden als het doelwit van een eenvoudige <script>
tag. (Wel, het verhindert het niet, maar het maakt het onaangenaam.) Op die manier kunnen slechteriken niet zomaar die script-tag in hun eigen site zetten en vertrouwen op een actieve sessie om het mogelijk te maken je inhoud op te halen.
edit — let op de opmerking (en andere antwoorden). Het probleem heeft te maken met ondermijnde ingebouwde faciliteiten, in het bijzonder de Object
en Array
constructors. Deze kunnen zodanig worden aangepast dat anders onschadelijke JSON, wanneer geparseerd, aanvalscode kan activeren.