OAuth Flujo de autorización y redireccionamiento

La entrega del Código de Autorización no es más un problema de seguridad que el envío de la contraseña del usuario desde el navegador al servidor de Facebook (por ejemplo). Eso significa que, si hay una conexión insegura, un atacante podría poner en peligro la autenticación del usuario de todos modos. Por esa razón, OAuth está destinado a ser ejecutado con HTTPS.

La razón por la que necesita para implementarse de esta manera es porque solo de esta manera el cliente OAuth puede identificar al usuario que solicitó OAuth. Esto se debe a que cuando un usuario, por ejemplo, hace clic en el botón de Facebook en StackOverflow, lo conecta inmediatamente a Facebook, donde comienza el proceso de OAuth. Hasta ahora, StackOverflow no sabe que este usuario solicitó OAuth a través de Facebook. Solo a través de la redirección del usuario a StackOverflow junto con el Código de autenticación, StackOverflow sabe que este usuario (con su ID de sesión) usó OAuth de Facebook y obtuvo este Código de autenticación. Ahora StackOverflow puede conectar la ID de sesión con el código de autenticación y sabe quién solicitó el OAuth de Facebook.

editar He mirado el RFC de OAuth, y tengo que hacer una corrección con respecto a mi primer punto. Si bien es altamente recomendable que el punto final de redireccionamiento use HTTPS, todavía no es no obligatorio . Consulte Confidencialidad de la solicitud de punto final . Por lo tanto, el Código de Autentificación puede enviarse sin cifrar en algún momento, es decir, al redirigir al servidor original que no tiene activado HTTPS. Pero aún así, para mí este es un gran problema de seguridad con todo el proceso de OAuth. HTTPS debería ser obligatorio. Si un servidor no puede HTTPS su conexión, no debería jugar con OAuth después de todo.

Se envía de vuelta al navegador porque es esencial hacerlo de esta manera.

Puede ser una locura, pero toda la seguridad de OAuth / OpenId se basa en el hecho de que su navegador hará la redirección correcta.

Veamos un ataque si no usa el navegador como una redirección, pero primero definamos una versión simplificada del "marco" de OAuth para nuestro ejemplo.

• Cliente: la aplicación a la que desea conectarse
• navegador: tu navegador ...
• Proveedor: el proveedor de OAuth (Ej .: Google o Facebook)
• Mal: el atacante.

El flujo normal

1. El navegador le pide al cliente que inicie sesión
2. Navegador de redirección del cliente al proveedor
3. El navegador de autenticación del proveedor luego redirige al Cliente con el token
4. El cliente se comunica con el proveedor dando el token de autorización.
5. Autorización de concesión de cliente al navegador.

Tu flujo

1. El navegador le pide al cliente que inicie sesión
2. Navegador de redirección del cliente al proveedor
3. El proveedor autentica el navegador y envía el token al cliente dándole la autorización
4. Autorización de concesión de cliente para navegador

El problema aquí es que el cliente no está seguro de que el navegador con el que se está comunicando es el mismo que se autentica con el proveedor.

Un ataque en tu flujo

1. El navegador accede al mal por alguna mala razón
2. Evil impersonate Browser y pide al Cliente que inicie sesión.
3. El cliente envía un enlace de redireccionamiento a Evil
4. El mal reenvía el enlace al navegador que lo redirecciona a Proveedor
5. El proveedor autentica el navegador y envía el token al Cliente dándole la autorización
6. Autorización de concesión de cliente para Evil pensando que es un navegador

¿Ves el problema en el último paso?

Esto no habría ocurrido si estuviera utilizando una redirección del navegador para enviar el token al cliente. Al utilizar una redirección del navegador, se asegura de que el Navegador que se autentica con el Proveedor sea el mismo que intenta obtener la autorización correcta con el Cliente.

Este es un paso crucial. Especialmente ya que muchos proveedores enviarán el token automáticamente después de la primera vez si inicias sesión. Por lo tanto, Evil podría obtener acceso a tu cuenta solo al visitar su página y ni siquiera lo sabrías.

El mismo ataque con flujo normal

1. El navegador accede al mal por alguna mala razón
2. Evil impersonate Browser y pide al Cliente que inicie sesión.
3. El cliente envía un enlace de redireccionamiento a Evil
4. El mal reenvía el enlace al navegador que lo redirecciona a Proveedor
5. El navegador de autenticación del proveedor luego redirige al Cliente con el token
6. El cliente se comunica con el proveedor dando el token de autorización.
7. Autorización de concesión de cliente al navegador.

Aquí el mal se eclipsó al final debido a la redirección. Esta es la razón por la que los protocolos realizan tantas comprobaciones en la URL de redireccionamiento para asegurarse de que no se redireccionarán a un sitio malicioso que robe el token de autorización.

OAuth / OpenId lo protege de nuevo al intento de phishing. Pero solo pueden hacerlo porque su navegador está haciendo la redirección correcta. En la aplicación de escritorio / móvil esto no funciona realmente, por lo tanto, los protocolos son menos seguros en la aplicación de escritorio / móvil.

Específicamente, protege al Cliente contra intentos de phishing. El cliente debe tomar una decisión muy difícil: ¿el navegador solicita la autorización igual que el navegador que se autentica con el proveedor? Y lo único que ayuda al cliente a hacer eso es la redirección y el hecho de que su navegador es seguro.

Ya que protege directamente al Cliente contra el phishing, lo protege indirectamente.