¿Prefiere envolver matrices JSON en otro objeto JSON o siempre requiere POST para evitar el secuestro JSON?

Question

Recientemente comencé a buscar la creación de aplicaciones web usando .NET MVC y tropecé con esta publicación de blog de Phil Haack: JSON Hijacking. Para aquellos de ustedes que no conocen esta vulnerabilidad cuando usan JSON para transferir datos confidenciales, es realmente una lectura obligada.

Parece que hay tres formas de manejar esta vulnerabilidad.

1. Requiere un POST en lugar de GET en su servicio JSON.
2. Envuelva las respuestas de su matriz JSON en un objeto JSON.
3. No exponga los datos sensibles de cualquier servicio que no está protegido por 1 o 2.

La tercera alternativa no es realmente una opción, ya que realmente limita el uso de JSON.

Entonces, ¿cuál de los otros dos prefiere?

La vista previa de .NET MVC 2 requiere un POST para las respuestas JSON de forma predeterminada, creo que esta es una excelente manera de proteger a cualquier desarrollador que aún no conozca este problema. Pero para mí se siente un poco "hacky" para romper REST de esta manera. A menos que alguien me convenza de ello, me estoy quedando envolver mis matrices en otro objeto y desenvolverlo en el lado del cliente.

Answer 1

personalmente envolver todas mis respuestas en un comentario:

/* { 
    "foo": 3, 
    "bar": "string with *\x2F sequence in" 
} */ 

y tiras que antes JSON.parsing. Esto lo hace inútil como objetivo para las etiquetas de script.

Vale la pena señalar que este problema no solo tiene que ver con JSON, sino con cualquier respuesta HTTP que sirva y que pueda interpretarse como JavaScript. Incluso, por ejemplo, un archivo de texto .htaccess-protected es vulnerable a la filtración a través de la inclusión de etiquetas de script de terceros, si está en un formato que resulta ser JavaScript válido.

Y aquí está la contracción: gracias a E4X, incluso los documentos XML estáticos son también válidos JavaScript. E4X es una extensión desastrosa e inútil para JavaScript, implementada e inventada en Mozilla, que le permite escribir <element>content</element> literales XML en línea en JS; como tal, un archivo XML protegido ahora es vulnerable a los mismos riesgos de fuga entre sitios que JSON. Gracias Mozilla. Ver el artículo de Google doctype sobre esto.

Answer 2

Dado que esto es básicamente un ataque CSRF, puede poner un token (por ejemplo, hash de identificación de sesión y secreto) en cada una de sus llamadas JSON y verificar la validez de ese token en el servidor. Es lo mismo que debe hacer para las solicitudes POST regulares de todos modos.

Answer 3

Este es un clásico csrf (falsificación de solicitudes entre sitios).

Aquí es una solución:

http://blog.codeville.net/2008/09/01/prevent-cross-site-request-forgery-csrf-using-aspnet-mvcs-antiforgerytoken-helper/