it-swarm-es.com

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

Dudo en implementar las soluciones de secuestro anti-JSON propuestas ya que

  1. Las soluciones recomendadas para mitigar el secuestro de JSON implican POST JSON sin REST para obtener datos

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

  3. No puedo encontrar una implementación aprobada por la comunidad que implemente la Solución alternativa (que se enumera a continuación) sobre cómo componer el token de seguridad o entregarlo de forma segura dentro de la página web. Tampoco pretendo ser lo suficientemente experto para implementar mi propia implementación.

  4. No se puede confiar en los encabezados de referencia

Fondo

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

Otra técnica de mitigación es envolver 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 AntiForgeryToken de ASP.NET MVC con jQuery HTTP GET para mi JSON.

Por ejemplo, si OBTENGO algunos datos confidenciales, según el enlace pirateado anterior, el siguiente código es vulnerable:

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

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

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

http: // localhost: 54607/Inicio/AdminBalances/ENCODEDTOKEN-TOKEN-AQUÍ

o

http: // localhost: 54607/Inicio/AdminBalances? ENCODEDTOKEN-TOKEN-HERE

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

Ejemplos de preguntas que me impiden lanzar mi propia solución

  1. ¿Qué formato de URL (arriba) usarías para validar JSON GET (barra, signo de interrogación, etc.) ¿Responderá un proxy a http: // localhost: 54607/Home/AdminBalances con http: // localhost: 54607/Inicio/AdminBalances? ENCODEDTOKEN-TOKEN-HERE datos?

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

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

  4. AntiForgeryToken utiliza una cookie. ¿Se utilizaría/necesitaría una cookie de respaldo en este caso? ¿Solo HTTP? ¿Qué pasa con SSL junto con HTTP Only?

  5. ¿Cómo configurarías los encabezados de tu caché? Cualquier cosa especial para Google Web Accelerator (por ejemplo)

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

  7. ¿La matriz JSON devuelta debería estar envuelta en un objeto solo por motivos de seguridad?

  8. ¿Cómo interopera esta solución con las características de creación de plantillas y enlace de datos de Microsoft

Las preguntas anteriores son las razones por las que no estoy avanzando y haciendo esto yo mismo. Sin mencionar que probablemente hay más preguntas en las que no he pensado y, sin embargo, son un riesgo.

5

Esta técnica fue iniciada por Jeremiah Grossman . Esto fue solo un problema porque el json devuelto también contiene javascript que podría incluirse en una página a través de un <script> etiqueta. La mayoría de las respuestas json no se pueden abusar de esta manera porque la política del mismo origen prohíbe que javascript obtenga los resultados. Para corregir este problema Google usó un cuft no analizable .

2
rook

Este artículo resume una variedad de defensas razonables.

Incluir un token impredecible en la URL es de hecho una forma razonable de defenderse de la amenaza. (Consulte la Sección 3 del documento para mencionar esto). Una forma razonable de entregarlo al servidor es como parámetro. El token puede ser una copia de la cookie de sesión o un valor secreto que el servidor conoce y que un atacante no puede predecir. Las técnicas para implementar esto son probablemente muy similares a las de la defensa contra CSRF.

Creo que HTTP vs HTTPS es un problema ortogonal; No veo ninguna relevancia aquí.

2
D.W.