stop - skip for javascript
¿Por qué Google precede a while(1); a sus respuestas JSON? (6)
¿Por qué Google precede a while(1); a sus respuestas (privadas) JSON?
Por ejemplo, aquí hay una respuesta al activar y desactivar 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'']]]]
Asumiría que esto es para evitar que las personas eval() una eval() , pero todo lo que realmente tendrías que hacer es reemplazar el while y luego estarás listo. Asumiría que la prevención de evaluación es asegurarse de que las personas escriban código de análisis JSON seguro.
También he visto esto usado en un par de otros lugares, pero mucho más con Google (Correo, Calendario, Contactos, etc.) Curiosamente, Google Docs comienza con &&&START&&& lugar de eso, y Google Contacts parece comenzar con while(1); &&&START&&& while(1); &&&START&&& .
¿Que está pasando aqui?
Dado que la etiqueta <script> está exenta de la Política del mismo origen, que es una necesidad de seguridad en el mundo web, while(1) cuando se agrega a la respuesta JSON evita el mal uso de la misma en la etiqueta <script> .
Eso sería 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 .
Esto es para garantizar que algún otro sitio no pueda hacer trucos desagradables para intentar robar sus datos. Por ejemplo, al reemplazar el constructor de arreglos , 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 un while(1); al principio, el script se bloqueará en su lugar.
Una solicitud del mismo sitio que usa XHR y un analizador JSON separado, por otro lado, puede ignorar fácilmente el while(1); prefijo.
Evita el secuestro de JSON , un problema de seguridad JSON importante que se fixed formalmente en todos los navegadores principales desde 2011 con EMCA5.
Ejemplo práctico: digamos que Google tiene una URL como mail.google.com/json?action=inbox que devuelve los primeros 50 mensajes de su bandeja de entrada en formato JSON. Los sitios web malvados en otros dominios no pueden realizar solicitudes AJAX para obtener estos datos debido a la política del mismo origen, pero pueden incluir la URL a través de una etiqueta <script> . La URL se visita con sus cookies, y al anular el método de constructor de matriz global o de acceso , pueden tener un método llamado siempre que se establece un atributo de objeto (matriz o hash), lo que les permite leer el contenido JSON.
El while(1); o &&&BLAH&&& evita esto: una solicitud de AJAX en mail.google.com tendrá acceso completo al contenido del texto y puede eliminarlo. Pero una inserción de etiqueta <script> ejecuta ciegamente el JavaScript sin ningún procesamiento, lo que resulta en un bucle infinito o un error de sintaxis.
Esto no aborda el problema de la falsificación de solicitudes entre sitios .
Evita la divulgación de la respuesta a través del secuestro de JSON.
En teoría, el contenido de las respuestas HTTP está protegido por la Política del mismo origen: las páginas de un dominio no pueden obtener ninguna información de las páginas del otro dominio (a menos que se permita explícitamente).
Un atacante puede solicitar páginas en otros dominios en su nombre, por ejemplo, utilizando una etiqueta <script src=...> o <img> , pero no puede obtener ninguna información sobre el resultado (encabezados, contenido).
Por lo tanto, si visita la página de un atacante, no podrá leer su correo electrónico desde gmail.com.
Excepto que cuando se usa una etiqueta de secuencia de comandos para solicitar contenido JSON, JSON se ejecuta como Javascript en un entorno controlado de un atacante. Si el atacante puede reemplazar el constructor de Array u Objeto o algún otro método utilizado durante la construcción del objeto, cualquier cosa en el JSON pasará por el código del atacante y se divulgará.
Tenga en cuenta que esto ocurre en el momento en que JSON se ejecuta como Javascript, no en el momento en que se analiza.
Hay múltiples contramedidas:
Asegurándose de que el JSON nunca se ejecuta
Colocando un while(1); Declaración antes de los datos JSON, Google se asegura de que los datos JSON nunca se ejecuten como Javascript.
Solo una página legítima puede obtener todo el contenido, eliminar el while(1); , y analizar el resto como JSON.
Cosas como for(;;); Se han visto en Facebook por ejemplo, con los mismos resultados.
Asegurarse de que el JSON no es válido Javascript
De manera similar, agregar tokens no válidos antes de JSON, como &&&START&&& , se asegura de que nunca se ejecute.
Siempre devolver JSON con un objeto en el exterior
Esta es la forma recomendada por OWASP para protegerse del secuestro JSON y es la menos intrusiva.
Al igual que en las contramedidas anteriores, se asegura de que JSON nunca se ejecute como Javascript.
Un objeto JSON válido, cuando no está encerrado por nada, no es válido en Javascript:
eval(''{"foo":"bar"}'')
// SyntaxError: Unexpected token :
Sin embargo, esto es JSON válido:
JSON.parse(''{"foo":"bar"}'')
// Object {foo: "bar"}
Por lo tanto, asegurarse de que siempre devuelva un Objeto en el nivel superior de la respuesta se asegura de que el JSON no sea un Javascript válido, mientras que sigue siendo un JSON válido.
Como lo señaló @hvd en los comentarios, el objeto vacío {} es un Javascript válido, y saber que el objeto está vacío puede ser una información valiosa.
Comparación de los métodos anteriores
El modo OWASP es menos intrusivo, ya que no necesita cambios en la biblioteca del cliente y transfiere JSON válido. Sin embargo, no está seguro de si los errores del navegador pasados o futuros podrían vencer esto. Como lo señaló @oriadam, no está claro si los datos podrían filtrarse en un error de análisis mediante un manejo de errores o no (por ejemplo, window.onerror).
El método de Google requiere una biblioteca cliente para que sea compatible con la deserialización automática y puede considerarse más seguro con respecto a los errores del navegador.
Ambos métodos requieren cambios en el servidor para evitar que los desarrolladores envíen accidentalmente JSON vulnerables.
Evita que se utilice como objetivo de una etiqueta <script> simple. (Bueno, no lo impide, pero lo hace desagradable). De esa 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 recuperar su contenido.
editar - note el comentario (y otras respuestas). El problema tiene que ver con las instalaciones incorporadas subvertidas, específicamente los constructores Object y Array . Se pueden alterar de tal manera que, de otro modo, el JSON inocuo, cuando se analiza, podría desencadenar el código del atacante.