¿Por qué Google antepone while(1); a sus respuestas JSON?
¿Por qué Google antepone while(1); a sus respuestas JSON (privadas)?
Por ejemplo, esta es una respuesta mientras se activa y desactiva un calendario en Google Calendar:
while(1);[['u',[['smsSentFlag','false'],['hideInvitations','false'],
['remindOnRespondedEventsOnly','true'],
['hideInvitations_remindOnRespondedEventsOnly','false_true'],
['Calendar ID stripped for privacy','false'],['smsVerifiedFlag','true']]]]Supongo que esto es para evitar que la gente haga un eval() en él, pero todo lo que tienes que hacer es reemplazar el while y entonces estarás listo. Supongo que la prevención de la evaluación es para asegurarse de que la gente escriba un código de análisis JSON seguro.
He visto que esto se utiliza en un par de otros lugares, también, pero mucho más con Google (Correo, Calendario, Contactos, etc.) Curiosamente, Google Docs comienza con &&&START&&& en su lugar, y Google Contacts parece comenzar con while(1); &&&START&&.
¿Qué está pasando aquí?
3929
3
Esto es para asegurar que algún otro sitio no pueda hacer trucos desagradables para intentar robar tus datos. Por ejemplo, al reemplazar el constructor del array, y luego incluir esta URL JSON a través de una etiqueta
<script>, un sitio malicioso de terceros podría robar los datos de la respuesta JSON. Poniendo unwhile(1);al principio, el script se colgará en su lugar.Por otro lado, una solicitud del mismo sitio que utilice XHR y un analizador JSON independiente, puede ignorar fácilmente el prefijo
while(1);.Esto sería para dificultar que un tercero inserte la respuesta JSON en un documento HTML con la etiqueta
<script>. Recuerde que la etiqueta<script>está exenta de la Política del mismo origen.Nota: a partir de 2019, muchas de las antiguas vulnerabilidades que dan lugar a las medidas preventivas comentadas en esta pregunta ya no son un problema en los navegadores modernos. Dejaré la respuesta a continuación como una curiosidad histórica, pero realmente todo el tema ha cambiado radicalmente desde 2010 (¡!) cuando se preguntó esto.
Impide que se utilice como objetivo de una simple etiqueta
<script>. (Bueno, no lo impide, pero lo hace desagradable.) De esta manera los malos no pueden simplemente poner esa etiqueta de script en su propio sitio y confiar en una sesión activa para hacer posible la obtención de su contenido.edit — nota el comentario (y otras respuestas). El problema tiene que ver con las facilidades incorporadas subvertidas, específicamente los constructores
ObjectyArray. Estos pueden ser alterados de tal manera que un JSON inocuo, al ser analizado, podría activar el código de un atacante.