¿Por qué no eval() JSON?

Por lo que sé, se considera una mala práctica eval() objetos JSON en JavaScript, debido a la seguridad. Puedo entender esta preocupación si el JSON proviene de otro servidor.¿Por qué no eval() JSON?

Pero si el JSON es proporcionado por mi propio servidor y se crea usando PHP json_encode (supongamos que no tiene errores), ¿es legítimo simplemente usar eval() para leer el JSON en JS o hay algún problema de seguridad I Actualmente no se puede pensar?

Realmente no quiero ocuparme de cargar dinámicamente un analizador JSON y me alegraría simplemente usar eval().

PD: obviamente usaré el objeto nativo JSON si está disponible, pero quiero volver a eval() para IE/Opera.

Fuente

2010-11-24 NikiC

JavaScript 'eval' evaluará * cualquier código * JavaScript y no solo el pequeño subconjunto que es igual a JSON. – Gumbo

Por supuesto que es bueno codificar sus datos, pero no va a mantener la misma base de código para siempre (con suerte), eventualmente alguien más tendrá que mantenerla, y ¿qué pasa si hay una nueva parte de una corrección de error que alguien puso y no llama al método de codificación, o lo llama, pero en el lugar equivocado, y abre una vulnerabilidad de seguridad, tener la segunda red de seguridad allí ya que un repliegue podría ser la diferencia entre un anuncio de PR embarazoso), costosos litigios y consecuencias legales, versus un simple parche de código para arreglar la red de seguridad de nivel medio. – BrainSlugs83

La otra cosa a tener en cuenta es también la facilidad de mantenimiento: acatar normas bien conocidas facilitará la transición de la propiedad del código a otro desarrollador/equipo, etc. cuando llegue el momento, que es bastante poderoso por sí mismo, pero para poner eso en el contexto de la seguridad: los desarrolladores que saben lo que hace su código y cómo funciona (porque usa las mejores prácticas estandarizadas para su nicho particular) serán menos propensos a poner código que derive las cosas y agrega nuevos fallos de seguridad por accidente, etc. – BrainSlugs83

Hay un número de maneras en que su seguridad puede verse comprometida.

Los ataques de hombre en el medio podrían alterar teóricamente el contenido de los datos que se entregan al cliente.
El tráfico de su servidor podría ser interceptado en otra parte y se podría proporcionar diferente contenido (no exactamente lo mismo que un ataque MIM)
Su servidor podría verse comprometido y la fuente de datos podría ser manipulada.

y estos son solo los ejemplos simples. XSS es desagradable.

"una onza de prevención vale una libra de curación"

Fuente

2010-11-24 19:19:29 zzzzBov

Si el servidor está en peligro, el atacante puede modificar la página original. – SLaks

no siempre. (cuatro caracteres más) – zzzzBov

@zzzzBov: ¿Podrían explicarlo mejor? Si alguien ha tomado el control de mi conexión, puede manipular cualquier cosa, y es mucho más efectivo manipular el JS que el JSON. – NikiC

En su escenario, la pregunta es: ¿de dónde obtiene PHP el javascript para ejecutar? ¿Es ese canal seguro y está libre de manipulaciones potenciales del usuario? ¿Qué pasa si no controlas ese canal directamente?

Fuente

2010-11-24 19:16:11

No sé qué puede manipular el usuario aquí. Construyo correctamente la salida con 'json_encode'. El usuario solo puede manipular el contenido de JSON, no su sintaxis. Por lo tanto, no veo una forma de cómo podría inyectar JS arbitraria. – NikiC

@nikic: piense en los ataques de hombre en el medio. – Gumbo

@Gumbo: un hombre en el medio podría manipular directamente el JavaScript. ¿Por qué molestarse en hackear el JSON si puede hackear el JS? – NikiC

Además de las cuestiones obvias de seguridad:

nativo JSON es más rápido
Usted no tiene que "cargar" un analizador JSON es sólo otra función llamada al motor de JavaScript

Fuente

2010-11-24 19:17:16

Bueno, * algunas personas todavía quieren tener soporte para IE y Opera. Yo soy uno de ellos. Obviamente, si el objeto JSON nativo está disponible, lo llamaré. – NikiC

Opera? ¿Qué versión de Opera estás usando? Opera tiene soporte JSON desde hace casi un año. Además, aún puede recurrir a Crockfords JSON, que * realiza la validación * antes de pasar el material a eval. –

@ Ivo: realmente hago exactamente eso. Pero no quiero, si no es necesario;) – NikiC

Consejo: en asp.net utilizando JSON se considera malo porque el análisis de DateTime difiere entre el servidor y el cliente, por lo que utilizamos un specia Funciono para deserializar la fecha en javascript. No estoy seguro de si PHP tiene el mismo problema, pero vale la pena mencionarlo.

Fuente

2010-11-24 19:18:30

la salida siguiente: http://blog.mozilla.com/webdev/2009/02/12/native-json-in-firefox-31/

así que al menos para Firefox que puede utilizar el construido en el analizador JSON

Fuente

2010-11-24 19:18:56 Daniel

-2

En serio? Algunos de los tipos aquí son paranoicos. Si está entregando el JSON y sabe que es seguro, está bien de respaldo (*) a eval(); en lugar de una js lib para IE. Después de todo, los usuarios de IE tienen mucho más de qué preocuparse.

Y el argumento de man-in-the-middle es bullsh * t.

(*) las palabras repliegue y segura están en negrita porque algunas personas aquí no los vi.

Fuente

2010-12-08 03:51:40

Respuesta

Cuestiones relacionadas