¿Cuál es el propósito de la comprobación de redirect_uri de OAuth 2.0?

Al no validar el redirect_uri , se puede usar un proveedor OAuth como un vector de phishing ideal. El redirect_uri es una dirección utilizada por los proveedores de OAuth como una ubicación para entregar el access_token por medio de una redirección del navegador. El popular proveedor de OAuth Facebook se ha encontrado con muchas vulnerabilidades relacionadas con la redirección de OAuth.

En este ataque, el atacante presenta a la víctima una URL a un portal de autenticación en el que la víctima confía (como Facebook), y al usar este portal de autenticación, el token de acceso secreto de la víctima se entrega a un servidor HTTP controlado por el atacante.

La autenticación tiene que ver con la intención, engañar a un usuario para que permita el acceso a un recurso no deseado es una vulnerabilidad.

Editado en base a los comentarios. Anteriormente pensé que el OP se refería a la validación redirect_uri durante la solicitud de autorización, y lo vinculé a un ejemplo de un ataque aquí . He actualizado la respuesta a continuación.

TL; DR: si se requiere que se registre una URL de redireccionamiento estático y el proveedor la coincida estrictamente, no creo que se requiera redirect_uri durante la solicitud del token de acceso.

Los requisitos de registro (3.1.2.2) indican que se debe registrar el URI de redireccionamiento. Sin embargo, no todos los proveedores realizan coincidencias exactas del URI de redireccionamiento, aunque la especificación lo requiere. La especificación OAuth intenta múltiples contramedidas para protegerse contra estas posibilidades, con redirect_uri < - > requisito de enlace del código de autorización descrito en el modelo de amenaza y consideraciones de seguridad RFC (5.2.4.5) .

Por ejemplo, GitHub hizo coincidir los prefijos de URL, que llevaron al ataque descrito aquí por Egor Homakov. En particular, los errores 1 y 2 permitieron a un atacante usar un URI de redireccionamiento en lista blanca para obtener un código, y luego usar ese código para completar el flujo de devolución de llamada y obtener acceso a la cuenta de la víctima. En este caso, el cliente (Gist), envió el URI de redireccionamiento correcto al proveedor (GitHub), y GitHub no habría concedido el token de acceso si hubiera verificado que el URI de redireccionamiento era el mismo utilizado durante la solicitud de autorización:

  

Fue defectuoso: no importa qué redirect_uri envió el Cliente para obtener un token, el Proveedor respondió con access_token válido.

     

El atacante podría secuestrar el código de autorización emitido para un redirect_uri "con fugas", luego aplicar el código filtrado en la devolución de llamada del Cliente real para iniciar sesión en la cuenta de la Víctima.

Para resumir, se requiere redirect_uri al obtener un token de acceso para garantizar que un código filtrado de una redirección a una página en la que el atacante puede insertar código no comprometa de inmediato el flujo de OAuth. Una descripción más completa del vector de ataque se describe aquí por Egor también:

  

El ataque es sencillo: encuentre una página con filtraciones en el cliente   dominio, inserte una imagen de dominio cruzado o un enlace a su sitio web, luego use   Esta página como redirect_uri. Cuando tu víctima carga un URL creado   lo enviará a leaking_page? code = CODE y el agente de usuario de la víctima   expone el código en el encabezado del Referer.

     

Ahora puede reutilizar el código de autorización filtrado en el real   redirect_uri para iniciar sesión en la cuenta de la víctima.

     

Remediación: redirect_uri flexible es una mala práctica. Pero si necesitas   Guarde redirect_uri para cada código que emita y verifíquelo en   creación access_token.

Como dijo Egor, enlace 1 :

  

todas las vulnerabilidades de auth se basan en la manipulación de redirect_uri   parámetro.

y enlace 2 :

  

Vector 2. Si la especificación se implementó correctamente, se manipula redirect_uri   para otros, "fugas", los valores no tienen sentido. Porque para obtener el token de acceso.   debe enviar el valor redirect_uri con credenciales de cliente. Si es real   redirect_uri fue "leaky" y no es igual a redirect_uri real.   no poder obtener access_token para este código.

redirect_uri es la devolución de llamada para que el Cliente reciba el Authorization Code .   El Cliente trata a cualquiera que traiga el código como el Propietario del recurso.

El atacante puede reemplazar el redirect_uri con uno malicioso en el Paso A para obtener el código.   Luego puede reconstruir y activar el uri para secuestrar la sesión que pertenece al propietario del recurso.

Sin embargo, cada código tiene un redirect_uri correspondiente para el que se emitió ,   es decir, el código se calculará en función del redirect_uri contaminado en el Paso C.

Tenga en cuenta que la solicitud en el Paso D es realizada por el Cliente. Siempre usará la forma correcta de redirect_uri . Finalmente, Authorization Server determina que el código no coincide con el uri, por lo que no se responderá ningún token en el Paso E.