Este es el problema que intenta evitar mediante la validación del token :
Como ejemplo simplificado, imagine que hay dos aplicaciones: (1) FileStore, un
aplicación de almacenamiento de archivos legítimos, y (2) EvilApp. Ambas aplicaciones utilizan Google
Proceso de autenticación para aplicaciones del lado del cliente. Alice es un final inocente
usuario, y su ID de usuario de Google es XYZ.
- Alice inicia sesión en FileStore utilizando Google.
- Después del proceso de autenticación, FileStore crea una cuenta para Alice y la asocia con el ID de usuario de Google XYZ.
- Alice carga algunos archivos en su cuenta de FileStore. Hasta ahora todo está bien.
- Más tarde, Alice inicia sesión en EvilApp, que ofrece juegos que parecen divertidos.
- Como resultado, EvilApp obtiene un token de acceso asociado con el ID de usuario de Google XYZ.
- El propietario de EvilApp ahora puede construir el URI de redirección para FileStore, insertando el token de acceso que se emitió para el Google de Alice.
cuenta.
- El atacante se conecta a FileStore, que tomará el token de acceso y consultará con Google para ver para qué usuario está. Google lo hará
decir que es usuario XYZ.
- FileStore le dará al atacante acceso a los archivos de Alice porque el atacante tiene un token de acceso para el usuario de Google XYZ.
El error de FileStore no fue verificar con Google que el acceso
el token que se le dio fue realmente enviado a FileStore; el token era realmente
emitido a EvilApp.
Creo que el uso adecuado del parámetro "estado" OAuth también puede prevenir
esta vulnerabilidad. "Uso correcto" siendo criptográficamente y de forma segura.
vincular el valor del parámetro de estado a la sesión actual del navegador. Esta
se puede hacer mediante una combinación de hashing de la ID de sesión y un nonce
(No estoy seguro de si es necesario incluir el nonce).
Tengo dos preguntas:
Mi pregunta principal es: ¿Se puede usar correctamente el parámetro "estado" de OAuth,
junto con el uso de TLS con la validación de certificados del servidor, mitigar el
Confuso problema del diputado, sin validar la audiencia del acceso.
token, para alguna definición de "uso adecuado" que mitiga el sitio cruzado
pedir falsificación?
No, necesita validar audience , no el estado, según este artículo :
Algunas personas creen que el uso del parámetro de estado en OAuth protege
contra la sustitución de fichas. El único enlace de una cookie de navegador para indicar
protege contra es Cross Site Scripting [creo que se refieren a CSRF] . En el ataque soy
Proponer al cliente genera una petición legítima a un mal usuario.
Agente que lo captura y proporciona una respuesta que incluye el estado.
sin cambios desde la solicitud. No hay nada en el lado del cliente de OAuth.
Flujo que prueba el emisor al que envió la solicitud a través del
El navegador nunca lo recibió y es el que responde. Solo el
El servidor de autorización genera el parámetro access_token, todos
Los otros parámetros se eliminan o devuelven el eco. El cliente no tiene
forma de saber quién pensó el servidor de autorización que emitía
access_token to.
Imagine que un atacante hace clic en un botón de su aplicación para darle acceso a su cuenta de Google para validar su identidad (es decir, la autenticación). Sin embargo, en lugar de seguir el redireccionamiento, en cambio toma el valor del estado y lo almacena en algún lugar. Luego obtiene un token de su aplicación maliciosa y luego lo reproduce en su redirect_uri , sustituyendo al state que ella misma ha capturado.
Su aplicación luego autentificará al usuario como el que le dio acceso a su aplicación maliciosa. En su lugar, validar a la audiencia es un enfoque seguro porque Google lo verifica cuando valida el token del lado del servidor.
Mi pregunta secundaria es: ¿Es la falsificación de solicitud entre sitios un tipo de problema de diputado confundido? Y si la respuesta es "sí", ¿no es la respuesta a mi pregunta principal también "sí" necesariamente?
Sí, CSRF es otro tipo de problema de diputado confuso.
state puede usarse para esto, ya que validaría que una parte maliciosa no ha atraído a un usuario a su sitio y lo ha redirigido a su punto final para autorizar la cuenta del atacante contra su aplicación. Por ejemplo, si su aplicación copia contenido de sí misma y se sincroniza con una cuenta de Google, el atacante podría redirigir al usuario a su punto final, luego verificará que el token coincida con el token y luego comenzar a sincronizar su contenido con la cuenta de Google como esta es la cuenta del atacante, ahora han obtenido acceso a los archivos de su usuario. Por lo tanto, la razón por la que verificar el state es una buena mitigación contra esto.