Ataque de repetición de conexión Openid

9

La especificación de conexión openid agrega un parámetro nonce al punto final autorizado, que debe devolverse como una reclamación en el identificador de identidad. Afirma que el propósito de este parámetro es evitar los ataques de reproducción y tiene algunas sugerencias de implementación sobre el uso de cookies de solo http.

Comprendo qué es el ataque de repetición en general, pero me gustaría comprender mejor los detalles de qué ataque de repetición podría proteger este ataque, para poder tener una mejor idea de si lo he implementado. efectivamente, o cometió algún error sutil.

Supongo que el ataque de repetición es contra el punto final autorizado para que un tercero obtenga un token correspondiente a un usuario diferente. ¿Es eso o es otra cosa? ¿Qué nivel de información esperamos que el atacante tenga que reproducir? ¿Tienen el tráfico entre el agente de usuario y el servidor de autorización pero no la aplicación cliente, por lo que podrían reproducir el tráfico en el punto final autorizado pero no podrían reproducir una cookie anterior en la aplicación cliente? ¿O tienen el historial del navegador de ambos, pero no el tráfico de la red, por lo que no tienen valores de cookies anteriores? ¿Importa si el agente de usuario todavía tiene la sesión del usuario anterior con el servidor de autorización cuando se produce la reproducción? Si el usuario anterior tiene una sesión válida con el servidor de autorización y el atacante tiene acceso a eso, ¿no pueden obtener acceso a un token sin hacer una repetición? Si no tienen una sesión válida con el servidor de autorización, ¿no se le pedirá al usuario de todos modos, incluso si repiten una solicitud anterior? Si se le solicitará al usuario que se autentique, probablemente con credenciales que no tiene, ¿cuál es el peligro de una repetición?

He hecho mucha búsqueda y hay algunas preguntas similares ( Replay Ejemplo de ataque para validar nonce? y Propósito de la validación de nonce en el flujo implícito de OpenID Connect ) ninguno de estos responde realmente a la pregunta sobre cómo funciona este ataque de reproducción específico. El primero simplemente cita la implementación recomendada de la especificación, luego habla de tokens filtrados, lo que me parece diferente de un ataque de repetición (si el atacante tiene un token filtrado, ¿no han ganado ya?). El segundo explica la idea general de un ataque de repetición, pero no habla de cómo realmente funciona este ataque en particular.

Como fondo, estoy haciendo una aplicación openid connect utilizando el flujo de código de autorización (por lo tanto, reproducir la redirección desde el AS a mi aplicación no debería hacer nada porque solo puedes intercambiar el mismo código de autorización por un token una vez que aparezca AFAICT, por lo tanto, tendría que volver a reproducir el punto final de autorización para que un ataque de repetición sea significativo.) Mi aplicación está utilizando tokens. Recibo como tokens de portador para autenticar solicitudes en mi servidor web, y son la totalidad del estado de la sesión. no hay otro estado de sesión significativo o identidad gestionada localmente para vincular los tokens. Mi proveedor de conexión openid requiere un nonce porque es una buena práctica de seguridad. ¿Es realmente útil en mi caso de uso particular? ¿Es la razón por la que estoy tan confundido porque en realidad no brinda una protección significativa para lo que estoy haciendo en particular? Si esto tiene implicaciones de seguridad para mí, el 110% quiero asegurarme de hacer lo correcto, pero me cuesta mucho entender de qué me protege.

Algunas preguntas detalladas sobre la implementación en las que estoy confuso debido a que no entiendo exactamente el vector de amenazas:

  • ¿Valido que el nonce coincida con lo que se envió al punto final autorizado después de retirarlo del punto final de token y luego asumo que es bueno para la sesión? ¿O debería validar la cookie id_token contra la cookie de nonce como parte de cada solicitud al igual que verificar la firma?
  • Se supone que el nonce está vinculado a la sesión, pero el término nonce implica que solo debe usarse una vez. Si necesito enviar un usuario con una sesión válida a través del punto final de autorización por algún motivo (¿obtener un nuevo id_token con una caducidad adicional en el futuro? ¿Solicitar un conjunto más amplio de ámbitos?) ¿Creo un nuevo nonce? ¿Es un nonce por sesión o por llamada para autorizar?
pregunta user3072507 06.01.2017 - 20:15
fuente

0 respuestas

Lea otras preguntas en las etiquetas