Problemas para evitar el secuestro JSON con AntiForgeryToken de MVC3, o una validación de token similar

Dudo en implementar las soluciones de secuestro anti-JSON propuestas desde

1. Las soluciones recomendadas para mitigar el secuestro JSON implican POST JSON no REST-REST para obtener datos

2. La solución alternativa (ajuste de objetos) causa problemas con los controles de terceros a los que no tengo acceso con código fuente.

3. No puedo encontrar una implementación verificada por la comunidad que implemente la Solución alternativa (que se muestra a continuación) sobre cómo componer el token de seguridad, o entregarlo de manera segura dentro de la página web. Tampoco pretendo ser un experto suficiente para rodar mi propia implementación.

4. No se puede confiar en los encabezados de referencia

Background

Este blog describe un problema de CSRF relacionado con el secuestro de JSON y recomienda usar POST de JSON para Obtener datos. Dado que el uso de HTTP POST para obtener datos no está muy lleno de REST, buscaría una solución más RESTfull que habilite acciones REST por sesión o por página.

Otra técnica de mitigación es envolver los datos JSON en un objeto como se describe aquí . Me temo que esto puede retrasar el problema hasta que se encuentre otra técnica.

Implementación alternativa

Para mí, parece natural extender el uso ASP.NET MVC's AntiForgeryToken con jQuery HTTP GET para mi JSON.

Por ejemplo, si OBTENGO algunos datos confidenciales, de acuerdo con el enlace de Haacked anterior, el siguiente código es vulnerable:

$.getJSON('[url]', { [parameters] }, function(json) {
    // callback function code
});

Estoy de acuerdo en que no es RESTfull para obtener datos utilizando la solución POST recomendada. Mi pensamiento es enviar un token de validación en la URL. De esa manera, el atacante al estilo CSRF no sabrá la URL completa. En caché, o no en caché, no podrán obtener los datos.

A continuación se muestran dos ejemplos de cómo se podría realizar una consulta JSON GET. No estoy seguro de qué implementación es la más efectiva, pero puedo suponer que la primera es más segura de los proxies errantes que almacenan en caché estos datos, lo que los hace vulnerables a un atacante.

enlace

o

enlace

... que bien podría ser AntiForgeryToken de MVC3, o una variante ( see swt ) del mismo. Este token se establecería como un valor en línea en cualquier formato de URL que se haya elegido anteriormente.

Preguntas de muestra que me impiden lanzar mi propia solución

1. ¿Qué formato de URL (arriba) usaría para validar el JSON GET (barra diagonal, cuestionario, etc.) responderá un proxy a enlace con enlace data?

2. ¿Cómo entregaría ese token codificado a la página web? ¿En línea o como variable de página?

3. ¿Cómo compondrías el token? ¿Construido en AntiforgeryToken, o por algún otro medio?

4. El AntiForgeryToken utiliza una cookie. ¿Se usaría / necesitaría una cookie de respaldo en este caso? Sólo HTTP? ¿Qué pasa con SSL junto con HTTP solamente?

5. ¿Cómo establecería los encabezados de su caché? Algo especial para el acelerador web de Google (por ejemplo)

6. ¿Cuáles son las implicaciones de solo hacer la solicitud JSON de SSL?

7. ¿Debería la matriz JSON devuelta todavía estar envuelta en un objeto solo por razones de seguridad?

8. ¿Cómo se interoperará esta solución con la propuesta de Microsoft? características y enlaces de datos

Las preguntas anteriores son las razones por las que no estoy avanzando y haciendo esto por mí mismo. Sin mencionar que es probable que haya más preguntas en las que no haya pensado y que, sin embargo, son un riesgo.