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.¿Prefiere envolver matrices JSON en otro objeto JSON o siempre requiere POST para evitar el secuestro JSON?
Parece que hay tres formas de manejar esta vulnerabilidad.
- Requiere un POST en lugar de GET en su servicio JSON.
- Envuelva las respuestas de su matriz JSON en un objeto JSON.
- 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.
el artículo e4x mencionas habla de los riesgos de seguridad en la dirección opuesta: que los consumidores * * de datos E4X deben tener cuidado de no ejecutarlo w/o análisis. Si * produces * datos e4x, ¿cuál es la preocupación? –
La página trata la inyección en ambas direcciones. Anteriormente (y aún en Firefoxen anterior) se podía alterar el prototipo XML para acceder a los objetos E4X creados recientemente por script externo, y aún existen peligros potenciales para el contenido de JavaScript anidado en E4X para invocar devoluciones de llamada de atacante.Este es especialmente el caso para las páginas que incluyen contenido proporcionado por el atacante, incluso escapado adecuadamente. – bobince