¿Mejores prácticas de seguridad de JSON?

Question

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

Así que comencé a investigar sobre los aspectos de seguridad de JSON y en esta publicación de blog sobre cómo JSON is not as safe as people think it is. Esta parte pegada a cabo:

Actualización: Si usted está haciendo JSON 100% correctamente, entonces usted sólo tiene objetos en el nivel superior. Arrays, Strings, Numbers, etc. serán todos envueltos. Un objeto JSON fallará a eval() porque el intérprete de JavaScript pensará que está mirando a un bloque en lugar de un objeto. Este ayuda en gran medida a proteger contra estos ataques, sin embargo, sigue siendo el mejor para proteger sus datos de seguridad con URL no predecibles.

Bien, 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 la 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 utilizas las URL impredecibles para aumentar la seguridad?

Answer 1

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 REFIEREN a 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.

La matriz cosa/objeto es nuevo para mí:

Script-Etiquetas: el atacante puede incrustar una etiqueta guión que apunta a un servidor remoto y el navegador lo hará efectiva eval() la respuesta de usted, sin embargo, descarta la respuesta y dado que JSON es toda la respuesta, está 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 2

es todavía mejor para proteger sus datos seguros con direcciones URL de la ONU-predecible.

Énfasis mío. ¡Qué absurdo! Es mejor para proteger sus datos de seguridad con alguna autenticación adecuada y posiblemente algún 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 que alguien no adivine una URL (de lo que están hablando efectivamente) será solo una técnica razonable (e incluso así, solo) cuando esté usando JSON para exportar datos a una tercera parte anónima (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á usando JSON para enviar datos privados desde y hacia un agente de usuario directo y conocido, use alguna autentificación y cifrado reales. Si está tratando de proporcionar un servicio web, realmente depende de cómo "asegurar" esta información va a ser. 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, considere esto. Imagine que su banco proporcionó una API JSON para obtener declaraciones. Si pudiera escribir http://yourbank.com/json-api/your-name/statement, probablemente no estaría satisfecho.

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

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