¿Repetir el ejemplo de ataque para validar nonce?

Question

¿Repetir el ejemplo de ataque para validar nonce?

#1 de SilverlightFox (1 votos)

3

Estoy intentando validar un token JWT recibido de Windows Azure. Estoy siguiendo la documentación aquí: enlace

Cuando solicita un token, Azure le hace suministrar un nonce, y el token JWT devuelto contiene el nonce que envió, y se supone que debe asegurarse de que coincidan. Un problema común en esta situación es que el servidor no tiene estado y puede haber varios servidores, por lo que no es fácil almacenar el nonce para comparar el valor en el token cuando se recibe el token.

Esto es lo que planeo hacer: cuando redireccione el navegador a enlace almacenaré el nonce en una cookie. Cuando se reciba el token de Azure, y el navegador lo envíe a mi servidor, también recibiré el nonce en la cookie y puedo compararlos para asegurarme de que coincidan.

Esta es una solución fácil para el problema de dónde almacenar el nonce. Pero la pregunta es, ¿es esta estrategia consistente con la forma en que se supone que se debe usar el nonce? Dado que el nonce se transfiere al / del cliente, ¿eso rompe la protección ofrecida por nonce? ¿Habilitará esto los ataques de repetición y dejará el nonce sin valor? Para responder a estas preguntas, necesito saber qué tipo de ataques estoy tratando de prevenir.

Entonces, la pregunta es, ¿cuáles son algunos ejemplos de escenarios de ataques de repetición que el nonce está diseñado para prevenir? ¿Está el atacante en algún lugar de Internet, en cuyo caso se puede usar SSL para evitar que vea alguna comunicación? ¿O está el atacante en la misma computadora que el usuario, es decir, después de que el usuario deja la computadora, el atacante usa la computadora y el navegador que el usuario no pudo cerrar?

¿Cómo funciona exactamente un ataque de reproducción?

man-in-the-middle nonce jwt

pregunta User52016 17.05.2016 - 16:56

fuente

1 respuesta

Lea otras preguntas en las etiquetas man-in-the-middle nonce jwt

Sulley - Lógica detrás de los primitivos Convertir el token en una cookie

score 1 · Accepted Answer

Según documentación de OpenID Connect Core :

El valor del parámetro nonce debe incluir el estado por sesión y ser Indiscutible para los atacantes. Un método para lograr esto para el servidor web Los clientes deben almacenar un valor criptográficamente aleatorio como HttpOnly cookie de sesión y utilizar un hash criptográfico del valor como el nonce parámetro. En ese caso, el nonce en el token de ID devuelto es en comparación con el hash de la cookie de sesión para detectar la reproducción del token de ID por terceros. Un método relacionado aplicable a los clientes de JavaScript es para almacenar el valor aleatorio criptográficamente en almacenamiento local HTML5 y use un hash criptográfico de este valor.

Entonces, sí, es aceptable almacenarlo en una cookie, pero se recomienda usar un hash seguro como SHA-2 cuando este valor se envía al servidor de autorización desde el navegador del usuario.

Esto protege contra un token robado, porque el atacante que ha robado el token no tendrá esta cookie de sesión en su sitio, y no podrá adivinarlo o reconstruirlo porque el valor está descifrado cuando se envía externamente.

El atacante estaría en Internet, porque si el usuario es local, todas las apuestas están desactivadas; podrían acceder al token enviado a su aplicación, y podrían acceder a esta sesión cookie.

Entonces, ¿contra qué protege?

Recuerde que si confía en OpenID para autenticar a sus usuarios, confía en un tercero. En un mundo ideal, la seguridad del proveedor es absoluta y nadie puede interceptar el token. Sin embargo, si hay una debilidad en la cadena entre el usuario y el proveedor de OpenID, por ejemplo, existe una vulnerabilidad de fuga de token no reportada que permite a un atacante observar el token, el nonce se asegurará de que no pueda iniciar sesión en su aplicación al repetir la redirección a su sitio.

El valor de un nonce sobre la simple validación que tienen de cualquier sesión en su sitio es que empareja su acceso original a su sitio cuando lo redirige al proveedor, con el retorno a su sitio.