it-swarm-es.com

¿Por qué Google precede a while (1); a sus respuestas JSON?

¿Por qué Google añade while(1); a sus respuestas JSON (privadas)?

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 realicen una eval() en él, pero todo lo que tendría que hacer es reemplazar la while y luego se establecería. 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&&& en su lugar, y parece que los Contactos de Google para empezar con while(1); &&&START&&&.

¿Que está pasando aqui?

3824
Jess

Previene secuestro JSON , un problema de seguridad JSON importante que es formalmente fijo en todos los navegadores principales desde 2011 con ECMAScript 5.

Ejemplo elaborado: 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 AJAX solicitudes para obtener estos datos debido a la misma política de Origin, pero pueden incluir la URL a través de una etiqueta <script>. La URL se visita con su cookies, y por anulando el constructor de matriz global o los métodos de acceso pueden tener un método llamado cada vez que se establece un atributo de objeto (matriz o hash), permitiéndoles para leer el contenido de JSON.

El while(1); o &&&BLAH&&& evita esto: una _ AJAX solicitud 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 falsificación de solicitud entre sitios .

4079
rjh

Evita la divulgación de la respuesta a través del secuestro 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 ningún tipo de 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 sucede 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

Al colocar una declaración while(1); antes de los datos JSON, Google se asegura de que los datos JSON nunca se ejecuten como Javascript.

Solo una página legítima podría obtener todo el contenido, eliminar la 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 OWASPforma recomendada para protegerse del secuestro JSON y es la menos intrusiva.

De manera similar a las contramedidas anteriores, se asegura de que el 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, al tiempo 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 si los errores pasados ​​o futuros del navegador podrían derrotar esto. Como 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 lado del servidor para evitar que los desarrolladores envíen accidentalmente JSON vulnerables.

513
Arnaud Le Blanc

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 la matriz , 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. Al poner una 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 prefijo while(1);.

354
bdonlan

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 .

104
Daniel Vassallo

Nota : a partir de 2019, muchas de las vulnerabilidades antiguas que conducen a las medidas preventivas discutidas en esta pregunta ya no son un problema en los navegadores modernos. Dejaré la respuesta a continuación como una curiosidad histórica, pero en realidad todo el tema ha cambiado radicalmente desde 2010 (!!) cuando esto se solicitó.


Evita que se use como el objetivo de una etiqueta <script> simple. (Bueno, no lo impide, pero lo hace desagradable). De esa manera, los malos no pueden 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.

72
Pointy

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 uso incorrecto de la misma en la etiqueta <script>.

9
kg11