Las aplicaciones de escritorio y móvil son navegadores integrados en la aplicación para ayudar a completar todo el proceso OAuth 2.0
El proceso se muestra en la figura
OAuth2.0 web
1) Devolver el authCode al Web redirectUri especificado (este URI lo configura el desarrollador de la aplicación)
2) Para cambiar el token, necesitas pasar el clientId y el clientSecret para verificar la identidad del cliente (obtenida por el servicio backend de la aplicación)
Teniendo en cuenta los dos puntos anteriores,
1) Porque no es válida la detección de redireccionamiento de Uri en la aplicación web
2) Como no hay un cliente de servicio backend, el secreto no es seguro
Entonces, el ataque que podemos encontrar es como se muestra en la figura siguiente: puede haber una aplicación maliciosa interceptando authCode para enviar un mensaje al AuthorizationServer y obtener el token, de modo que el token se obtenga sin la autorización del cliente para la aplicación sino para otra autorización oficial de aplicación, logrando así el propósito del ataque.
Solución:
1. El cliente genera una cadena aleatoria verificadora de código y guarda esta cadena aleatoria
code_challenge = transformación(code_verifier, [Llanura| S256])
Si el método de transformación es simple, entonces el desafío de código es equivalente a verificador de código
Si el método de transformación es S256, entonces el desafío del código es igual al hash Sha256 del verificador de código
2. Llevar un desafío de código a la solicitud de código de autorización y cómo generar un desafío de código. Estos dos están vinculados al código de autorización emitido por el servidor
3. Tras obtener el código de autorización, el cliente trae el verificador de código inicialmente generado al intercambiar el código de autorización por el Token de Acceso. El servidor calcula el verificador de código según el método de transformación acotada, compara el resultado calculado con el desafío del código acotado y emite un Token de Acceso si es consistente. |
Publicado en 28/11/2020 20:51:48
|
|
|
|
