mostrar - leer json javascript

¿Mejores prácticas de seguridad de JSON?

Question

Mientras investigaba el tema de JSON vs XML , me encontré con esta pregunta . Ahora, una de las razones para preferir JSON se mencionó como la facilidad de conversión en Javascript, concretamente con eval() . Ahora esto inmediatamente me pareció potencialmente problemático desde una perspectiva de seguridad.

Así que comencé a investigar un poco sobre los aspectos de seguridad de JSON y en esta publicación de blog sobre cómo JSON no es tan seguro como la gente cree que es . Esta parte sobresalió:

Actualización: si está haciendo JSON 100% correctamente, entonces solo tendrá objetos en el nivel superior. Arrays, Strings, Numbers, etc. estarán todos envueltos. Un objeto JSON fracasará en eval () porque el intérprete de JavaScript pensará que está mirando un bloque en lugar de un objeto. Esto ayuda en gran medida a protegerse contra estos ataques, sin embargo, es mejor proteger sus datos seguros con URL no predecibles.

Ok, esa es una buena regla para empezar: los objetos JSON en el nivel superior siempre deben ser objetos y nunca matrices, números o cadenas. Suena como una buena regla para mí.

¿Hay algo más que hacer o evitar cuando se trata de seguridad relacionada con JSON y AJAX?

La última parte de la cita anterior menciona URL impredecibles. ¿Alguien tiene más información sobre esto, especialmente cómo lo haces en PHP? Tengo mucha más experiencia en Java que en PHP y en Java es fácil (en el sentido de que puedes mapear toda una gama de URL a un solo servlet), mientras que todos los PHP que he hecho han mapeado una sola URL para el script PHP.

Además, ¿cómo usa exactamente las URL impredecibles para aumentar la seguridad?

Answer 1

aún así es mejor proteger sus datos seguros con URL no predecibles.

Énfasis mío ¡Qué absurdo! Lo mejor es proteger sus datos seguros con una autenticación adecuada y, posiblemente, algo de cifrado además de eso. Los intercambios JSON aún pueden usar técnicas de autenticación existentes (por ejemplo, sesiones a través de cookies) y SSL.

Confiar en alguien que no adivine una URL (de lo que están hablando efectivamente) solo será una técnica razonable (e incluso así, solo) cuando esté usando JSON para exportar datos a un tercero anónimo (por ejemplo, un servicio web) . Un ejemplo es la API de varios servicios web de Google, donde los usuarios anónimos acceden a datos de Google a través de otros sitios web. Usan claves de referencia de dominio y API para asegurarse de que el sitio web man-in-the-middle pueda proporcionar datos de Gooogle.

Si solo está utilizando JSON para enviar datos privados desde y hacia un agente de usuario directo y conocido, use alguna autentificación y cifrado real. Si intenta proporcionar un servicio web, realmente depende de cuán "seguros" sean estos datos. Si solo se trata de datos públicos y no te importa quién pueda leerlos, no veo el sentido de crear una URL hashy.

Editar: para demostrar lo que significan, considera esto. Imagine que su banco proporcionó una API JSON para obtener declaraciones. Si pudiera simplemente escribir http://yourbank.com/json-api/your-name/statement , probablemente no estaría satisfecho.

Sin embargo, podrían generar una cadena única para su cuenta que se requería en cualquier solicitud de JSON, por ejemplo: http://yourbank.com/json-api/your-name/big-long-key-unique-to-you/statement

Tendría muchas menos posibilidades de poder adivinar eso. ¿Pero realmente querrías que fuera el único amortiguador entre tus datos genuinamente seguros y los posibles ladrones de identidad? No.

Answer 2

El agujero de seguridad principal del blog (CSRF) no es específico de JSON. Es un agujero tan grande usando XML en su lugar. De hecho, es igual de malo sin llamadas asíncronas; los enlaces regulares son igual de vulnerables.

Cuando las personas hablan de URL únicas, generalmente NO se http://yourbank.com/json-api/your-name/big-long-key-unique-to-you/statement . En cambio, es más común hacer que otra cosa sobre la solicitud sea única; es decir, un valor en la publicación FORM o un parámetro URL.

Por lo general, esto implica un token aleatorio insertado en el FORMULARIO en el lado del servidor, y luego se verifica cuando se realiza una solicitud.

Lo del conjunto / objeto es nuevo para mí:

Script-Tags: El atacante puede insertar una etiqueta de script apuntando a un servidor remoto y el navegador evaluará () la respuesta de manera efectiva, sin embargo, descarta la respuesta y como JSON es toda la respuesta, estás a salvo.

En ese caso, su sitio no necesita usar JSON en absoluto para ser vulnerable. Pero sí, si un atacante puede insertar HTML aleatorio en tu sitio, estás muy bien.

Answer 3

Hay una serie de ataques de seguridad contra JSON, especialmente XSRF.

La vulnerabilidad se produce cuando un servicio web utiliza cookies para la autenticación y responde con una matriz JSON que contiene datos confidenciales en respuesta a una solicitud GET.

Si un atacante puede engañar a un usuario que está conectado a un servicio, naive-webapp.com, para que visite su sitio (o cualquier sitio que incorpore un IFRAME que controle, por ejemplo, a través de anuncios integrados), entonces puede insertar una etiqueta <script> con un SRC para naive-webapp.com, y potencialmente robar los datos del usuario. Esto depende de una peculiaridad de javascript con el constructor Array JavaScript de esta manera:

 <script>
   // Overload the Array constructor so we can intercept data
   var stolenArrays = [];
   var RealArray = Array;
   Array = function () {
     var arr = RealArray.apply(arguments);
     stolenArrays.push(arr);
     return arr;
   }
 </script>
 <!-- even though the attacker can''t access the cookies,
   - he can cause the browser to send them to naive-webapp.com -->
 <script src="//naive-webapp.com/..."></script>
 <script>
   // now stolenArrays contains any data from the parsed JSON
 </script>

EcmaScript 5 ha corregido el comportamiento confuso que causaba que [] buscara Array en el objeto global y muchos navegadores modernos ya no son susceptibles a este ataque.

Por cierto, Oil está equivocado sobre las URL impredecibles. Los identificadores aleatorios criptográficamente seguros en las URL son una buena forma de proteger los recursos. La seguridad basada en la identidad no es una panacea, como sugiere Oil. Consulte http://waterken.sourceforge.net/ para obtener un ejemplo de un esquema de aplicación distribuida segura basada en identificadores criptográficamente seguros en las URL que no requieren un concepto de identidad.

EDITAR:

Al considerar JSON vs XML, también debe conocer los vectores de ataque específicos de XML.

XXE , XML Ataques de entidades externas: use XML creado para acceder al sistema de archivos y recursos de red a través del firewall.

<!DOCTYPE root 
[
<!ENTITY foo SYSTEM "file:///c:/winnt/win.ini">
]>
...
<in>&foo;</in>

La aplicación incorpora la entrada (parámetro "en", que contiene el archivo win.ini) a la respuesta del servicio web.