¿Cómo deben defenderse los desarrolladores de aplicaciones web contra el secuestro JSON?

La primera defensa es atenerse a la especificación utilizando JSON válido que requiere un objeto como entidad de nivel superior . Todos los ataques conocidos se basan en el hecho de que si el objeto de nivel superior es una matriz, la respuesta es un código Java Script válido que se puede analizar utilizando un < script > etiqueta.

  

Si la respuesta JSON contiene datos confidenciales / no públicos, solo envíe la respuesta si la solicitud está autenticada (por ejemplo, viene con cookies que indican una sesión autenticada).

Ese es el requisito previo para el ataque , no una mitigación. Si el navegador tiene una cookie para el sitio A, la incluirá en todas las solicitudes al sitio A. Esto es cierto incluso si la solicitud fue activada por un < script > etiqueta en el sitio B.

  

Si los datos JSON contienen algo confidencial o no público, hospédelos en una URL secreta e indiscutible (por ejemplo, una URL que contenga un número aleatorio de calidad criptográfica de 128 bits) y solo comparta esta URL secreta con usuarios / clientes autorizados para ver los datos.

Las URL no se consideran una función de seguridad . Todos los motores de búsqueda comunes tienen complementos / barras de herramientas del navegador que informan cualquier URL visitada al proveedor del motor de búsqueda. Si bien es posible que solo informen las URL que se visitan explícitamente, tampoco me arriesgaría a esto por las URL de JSON.

  

Haga que el cliente envíe solicitudes de datos JSON como POST (no un GET), y haga que el servidor ignore las solicitudes GET para datos JSON.

Esto evitará que < script > incluir.

  

Poner while (1); al comienzo de la respuesta JSON, y haga que el cliente la elimine antes de analizar JSON.

Sugiero una versión modificada de este enfoque: Agregue </* al principio . while(1) es problemático por dos razones: Primero, es probable que active el escáner de malware (en clientes, proxies y motores de búsqueda). En segundo lugar, se puede utilizar para ataques DoS contra la CPU de los internautas. Esos ataques obviamente se originan en su servidor.

Google usa " unparseable cruft " para defenderse contra este tipo de ataque. Esta vulnerabilidad se solucionó en firefox 3 . La vulnerabilidad surge de cómo los navegadores implementan la especificación JSON.

  

1) Si la respuesta JSON contiene datos confidenciales / no públicos, solo envíe la respuesta si la solicitud está autenticada (por ejemplo, viene con cookies que indican una sesión autenticada).   2) Si los datos JSON contienen algo confidencial o no público, hospédelos en una URL secreta e indiscutible (por ejemplo, una URL que contenga un número aleatorio de calidad criptográfica de 128 bits) y solo comparta esta URL secreta con usuarios / clientes autorizados para ver los datos.

No hay una buena razón para hacer ambas cosas (1) y (2).

El primero es ABAC y el segundo es ZBAC. Tratar de obtener una defensa en profundidad mediante el uso de múltiples esquemas de control de acceso es solo una complicación excesiva.

  

3) Coloque while(1); al inicio de la respuesta JSON, y haga que el cliente la elimine antes de analizar el JSON.

     

4) Haga que el cliente envíe solicitudes de datos JSON como POST (no un GET), y haga que el servidor ignore las solicitudes GET para datos JSON.

Esto suena como ideas finas y agrega defensa en profundidad ya que ayuda a garantizar que las credenciales no puedan ser mal aprovechadas.

Además,

5) Solo sirve JSON con datos confidenciales a través de SSL o algún otro canal seguro.

para evitar fugas de datos a través de MITM.