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


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

Por ejemplo, aquí hay una respuesta al encender y apagar un calendario en calendario de Google:

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 las personas hagan una eval() en él, pero todo lo que realmente tendrías que hacer es reemplazar el while y luego estarías listo. Asumiría que la prevención de evaluación es para asegurarse de que la gente escriba el código de análisis seguro de JSON.

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 los Contactos de Google parecen comenzar con while(1); &&&START&&&.

¿Que está pasando aqui?


3483
2018-04-19 18:00


origen


Respuestas:


Previene JSON secuestro.

Ejemplo de error: digamos que Google tiene una URL como mail.google.com/json?action=inbox que devuelve los primeros 50 mensajes de tu bandeja de entrada en formato JSON. Los sitios web malignos en otros dominios no pueden realizar solicitudes AJAX para obtener estos datos debido a la política de origen mismo, pero pueden incluir la URL a través de un <script> etiqueta. La URL se visita con tu 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), lo que les permite leer el contenido JSON.

los while(1); o &&&BLAH&&& lo previene: una solicitud de AJAX en mail.google.com tendrá acceso completo al contenido de texto y puede quitarlo. Pero una <script> la inserción de etiquetas ejecuta ciegamente el JavaScript sin ningún procesamiento, lo que da como resultado un bucle infinito o un error de sintaxis.

Esto no aborda la cuestión de solicitud de falsificación a través del sitio.


3760
2018-04-19 18:11



Impide 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 misma política de origen: las páginas de un dominio no pueden obtener información de las páginas de otro dominio (a menos que esté explícitamente permitido).

Un atacante puede solicitar páginas en otros dominios en su nombre, p. usando un <script src=...> o <img>etiqueta, pero no puede obtener ninguna información sobre el resultado (encabezados, contenidos).

Por lo tanto, si visita la página de un atacante, no podría leer su correo electrónico desde gmail.com.

Excepto que cuando se usa una etiqueta de script para solicitar contenido JSON, el JSON se ejecuta como Javascript en el entorno controlado de un atacante. Si el atacante puede reemplazar el constructor Array o Object u otro método utilizado durante la construcción del objeto, cualquier elemento 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 ejecute

Al colocar 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 podría obtener todo el contenido, quitar el while(1);, y analizar el resto como JSON.

Cosas como for(;;); se han visto en Facebook, por ejemplo, con los mismos resultados.

Asegurándose de que el JSON no sea válido Javascript

Del mismo modo, agregar tokens no válidos antes de JSON, como &&&START&&&, se asegura de que nunca se ejecute.

Siempre devuelve JSON con un objeto en el exterior

Esto es OWASP camino recomendado para protegerse del secuestro de JSON, y es el menos intrusivo.

De forma similar a las contramedidas anteriores, se asegura de que el JSON nunca se ejecute como Javascript.

Un objeto JSON válido, cuando no está cerrado por nada, no es válido en Javascript:

eval('{"foo":"bar"}')
// SyntaxError: Unexpected token :

Sin embargo, esto es válido JSON:

JSON.parse('{"foo":"bar"}')
// Object {foo: "bar"}

Por lo tanto, asegurándose de que siempre devuelve un objeto en el nivel superior de la respuesta, se asegura de que el JSON no sea un código JavaScript válido, mientras siga siendo JSON válido.

Según lo observado por @hvd en los comentarios, el objeto vacío {} es Javascript válido, y saber que el objeto está vacío puede ser información valiosa.

Comparación de los métodos anteriores

El modo OWASP es menos intrusivo, ya que no necesita cambios de la biblioteca del cliente y transfiere JSON válido. Sin embargo, no está seguro si los errores del navegador pasados ​​o futuros podrían vencer esto. Como señala @oriadam, no está claro si los datos se pueden filtrar en un error de análisis mediante un tratamiento de errores o no (por ejemplo, window.onerror).

El camino de Google requiere la biblioteca del cliente para que admita la deserialización automática, y se puede considerar que es más seguro con respecto a los errores del navegador.

Ambos métodos requieren cambios en el servidor para evitar que los desarrolladores accidentalmente envíen JSON vulnerable.


442
2018-02-02 12:09



Esto es para asegurar que algún otro sitio no pueda hacer trucos desagradables para tratar de robar sus datos. Por ejemplo, por reemplazando el constructor de la matriz, luego incluye esta URL JSON a través de un <script> etiqueta, un sitio malicioso de terceros podría robar los datos de la respuesta JSON. Al poner un while(1); al principio, el script se bloqueará en su lugar.

Una solicitud en el mismo sitio que utiliza XHR y un analizador JSON separado, por otro lado, pueden ignorar fácilmente el while(1); prefijo.


343
2018-05-16 02:08



Eso sería para dificultar que un tercero inserte la respuesta JSON en un documento HTML con el <script> etiqueta. Recuerde que el <script> la etiqueta está exenta de La misma política de origen.


97
2018-04-19 18:04



Evita que se use como el objetivo de un simple <script> etiqueta. (Bueno, no lo previene, pero lo hace desagradable.) De esa manera, los chicos malos no pueden poner esa etiqueta de script en su propio sitio y confiar en una sesión activa para que sea posible recuperar su contenido.

editar - tenga en cuenta el comentario (y otras respuestas). El problema tiene que ver con las instalaciones incorporadas subvertidas, específicamente el Object y Array constructores Esos pueden ser alterados de tal forma que, de otro modo, un JSON inocuo, cuando se analiza, podría desencadenar un código de atacante.


65
2018-04-19 18:02



Desde el <script> etiqueta está exenta de la Política de Mismo origen que es una necesidad de seguridad en el mundo web, mientras que (1) cuando se agrega a la respuesta JSON evita el uso indebido de la misma en el <script>etiqueta.


3
2017-08-18 04:14