¿JSON.parse() es realmente más seguro que eval() cuando la página web y la llamada ajax provienen del mismo servidor?

Question

consigo que JSON.parse() evita que un atacante inyectar JavaScript en la respuesta desde un analizador JSON es sólo un programa de análisis de texto, no un programa de análisis de la escritura por lo que no cierre esta es una DUP de todas las otras preguntas que hablan sobre eso. Esta es una pregunta diferente.

Si un atacante puede secuestrar su llamada Ajax y poner javascript en la llamada Ajax, ¿no es probable que puedan secuestrar su página web real y poner javascript arbitrario en su página desde la que puedan realizar exactamente el mismo ataque? ?

Claro, no tiene nada que perder al usar JSON.parse() en lugar de eval() (a menos que aún no tenga un analizador JSON en su entorno y tenga que agregar más código para obtener uno), pero situaciones ¿realmente agrega seguridad si su página web está siendo servida por el mismo host que su llamada ajax?

Answer 1

Sí, es realmente más seguro. Cada precaución que no tome es un conjunto de exploits potenciales que no evita.

Un atacante podría tener cierto control sobre la salida de su servidor sin poder cambiarlo por completo. Nadie está sugiriendo que sea una bala mágica, pero es potencialmente más rápido y no estás creando una vulnerabilidad potencial que podría volver y lastimarte.

Tal vez alguien que ejecuta el servidor está teniendo un mal día, y hace algo tonto como la construcción de JSON mediante la concatenación de la entrada del usuario unsanitized:

<?php 
    print '{"foo": ' . $_GET['bar'] . '}'; 
?> 

Si está utilizando JSON.parse, lo peor que pueden hacer es meter una objeto grande en tu memoria. Si usas eval, pueden secuestrar todo.

Answer 2

Bueno, si son capaces de inyectar en sus respuestas AJAX que probablemente ya con éxito que el hombre-en-el-middle'd de una manera u otra (ARP, DNS o algo más).

Ver http://en.wikipedia.org/wiki/Man-in-the-middle_attack para más detalles sobre este tipo de ataque.

Tiene usted razón en que, si se puede inyectar en su respuesta AJAX, pueden inyectarse páginas enteras también. En realidad, cualquier cosa que reciba O envíe a través de una red ahora es vulnerable en un MitM a menos que se esté utilizando algo como HTTPS \ SSL.

Answer 3

Ese es un muy buen punto. Lo único que se me ocurre es que JSON.parse tendría la oportunidad de ser más rápido que eval.

Una ventaja mucho menos probable es si el navegador ya tiene el HTML/JavaScript en caché y el servidor usa Cache-Control para decir que no necesita volver a cargar. Si eso sucede, por supuesto, una persona que intercepta no tendría la oportunidad de modificar la página. Pero ese es un conjunto de circunstancias muy raro. Lo más probable es que requiera que el navegador busque una versión más nueva de HTML/JavaScript, que es el comportamiento predeterminado.

En cuanto a la diferencia de seguridad, creo que estás en lo correcto.

En cuanto a mí, yo trabajo con HTTPS confirmada sólo sistemas. Pero tengo una función que usa JSON.parse si está disponible y vuelve a eval solo para la mejora de la velocidad.

Answer 4

Bien ...No defiendo el uso de eval, pero no creo que constituya un problema de seguridad en Javascript, porque Javascript es el idioma del lado del cliente. Si no usa eval en su código, ¿qué impide que ejecute javascript:my_own_evil_code() en la consola o en la barra de direcciones? Es Javascript, puedo ejecutar mi propio código o modificar el suyo, crear mis propias solicitudes HTTP y hacer cualquier cosa con respuestas HTTP, o incluso agregar mi propio eval a sus funciones.

Usted no debe usar eval si hay otra solución comparable, pero si, sólo por simplicidad, quiere hacer eval('('+jsonstring+')') emular JSON.parse, no creo que es un gran error.