CNet informa que todo OpenID y OAuth Los sitios son vulnerables a un ataque llamado "Redirección Encubierta". ¿Qué es este ataque, cómo funciona y, como usuario final, cómo puedo mitigar el riesgo?
CNet informa que todo OpenID y OAuth Los sitios son vulnerables a un ataque llamado "Redirección Encubierta". ¿Qué es este ataque, cómo funciona y, como usuario final, cómo puedo mitigar el riesgo?
Esto no es una vulnerabilidad de / en OAuth 2.0 en absoluto. El problema ha sido exageradamente exagerado por CNET y el buscador original.
Aquí está en pocas palabras: si su sitio web (example.com) implementa un punto final de redireccionamiento abierto, es decir, implementa una URL que redireccionará el navegador a cualquier URL que se proporciona en la URL parámetros: Y su redireccionamiento copia los parámetros de la URL entrante a la URL de redireccionamiento saliente, entonces es posible que terceros aprovechen este artefacto de su sitio web en una amplia variedad de formas desagradables.
El peor de los casos: evil.com puede obtener el código de autenticación originalmente destinado a su sitio web (example.com) y puede utilizar ese código de autenticación para extraer información del usuario del proveedor de autenticación (Google, Facebook, etc.) ) o posiblemente incluso tome el control de la cuenta del usuario en su sitio web.
¿Podría evil.com tomar el control de la cuenta de Google del usuario con ese código de acceso? No, porque el código de acceso se acuñó para su sitio, example.com, y solo funciona allí.
¿De quién es la culpa? Tuyo, para implementar un redireccionamiento abierto en tu sitio. No culpe a Google ni a Facebook ni a otros por su mala implementación.
Hay algunos casos de uso legítimos para tener una redirección en su sitio. La más importante es redirigir el navegador después de iniciar sesión en la página web (en su sitio) que el usuario solicitó originalmente. Esto solo necesita redirigir desde su sitio web a las páginas de su sitio web, en su dominio.
¿Cómo solucionarlo? Haga que su punto final de redirección (example.com/redirect? & destination = ht.tp: //foo.com ...) valide la URL de destino. Solo permita redireccionamientos a páginas en su sitio, en su dominio.
Más información en mi blog: enlace
Actualización: Hay un problema de redireccionamiento abierto cuando se utiliza Facebook para el inicio de sesión de usuario de OAuth. Cuando configure la definición de su aplicación en Facebook, asegúrese de ingresar la URL de redireccionamiento específica de su dominio en el campo de redirección provisto. Facebook permite que este campo se deje en blanco. Si se deja en blanco, Facebook actúa como un redireccionamiento abierto al procesar los inicios de sesión de los usuarios para su sitio web.
Facebook debería solucionar esto simplemente no permitiendo que el campo de URL de redireccionamiento se deje en blanco.
Como han dicho otros, esto no es una idea nueva. Eran Hammer (uno de los creadores de la especificación Oauth 1.0, que dimitió del comité Oauth 2.0 escribió una buena sinopsis de la vulnerabilidad, hace casi 3 años. Su descripción no obtuvo un logotipo elegante ni ninguna cobertura sensacional de los medios.
Aquí hay un video de Youtube que el buscador original recopiló y lo guía a través de la vulnerabilidad: enlace .
OpenId y OAuth proporcionan un campo que permite que un sitio de terceros especifique una redirección cuando la autenticación se haya completado y sea exitosa. Por ejemplo, si va a Good Reads, quieren que inicie sesión con su cuenta de Facebook. Good Reads le dirá a Facebook, "hey, cuando el usuario se autentique correctamente, reenvíelos a enlace ". La vulnerabilidad es que algunos de estos sitios de terceros permiten que se especifiquen redirecciones en sus URL ( enlace ) y no puede validarlos antes de que redirijan al usuario. Por lo tanto, un atacante podría crear un enlace "Iniciar sesión con Facebook" para un sitio válido como Good Reads y podría especificar que la url de redireccionamiento sea algo como enlace (asumiendo que Good Reads hizo este tipo de redirección), su ventana emergente de inicio de sesión en Facebook mostrará que Good Reads (un sitio perfectamente normal para usted) desea autenticarse en Facebook, pero cuando se autentique y redirija a Good Reads, si Good Reads no valida la URL de redireccionamiento, será redirigido inmediatamente a enlace .
La corrección sería para que terceros validen los redireccionamientos, pero eso puede llevar un tiempo. La otra cosa es que CNet informó que los atacantes podrían robar información a través de este pequeño intercambio, pero no estoy seguro de si eso es posible. Alguien más puede comentar sobre el asunto. Pero, llevar a un usuario a un sitio malo es probablemente lo suficientemente bueno para ellos.
Esta es una forma de hombre en el ataque central donde un sitio puede tomar sus credenciales de OpenID. Funciona porque las fuentes de openID (facebook, google, etc.) no realizan suficientes comprobaciones cuando se envían las consultas de openID.
No hay nada que usted como usuario pueda hacer al respecto, todo lo que puede hacer es tener mucho cuidado con el uso de Oath y openID. Si un sitio en el que no esperaría usar openID aparece una ventana de openID, entonces no lo permita. Si sospechas que tus credenciales de openID han sido capturadas, ve a la fuente de autenticación (facebook, google, lo que sea) y cámbiala allí lo antes posible.
Desde el sitio web,
Covert Redirect es una aplicación que toma un parámetro y redirige a un usuario al valor del parámetro SIN validación SUFICIENTE. Este es a menudo el resultado del exceso de confianza de un sitio web en sus socios.
En otras palabras, existe la vulnerabilidad de Redireccionamiento encubierto porque no hay suficiente validación de las URL redirigidas que pertenecen al dominio de los socios.
Así que imagina que ejecuté algún tipo de enlace de phishing que abriste. Digamos que simulé ser tu banco. En condiciones normales, tendría que crear un dominio falso para engañarte. www.y0urb4nk.com y espero que haya hecho clic en el enlace. Con el ataque Covert Redirect, un atacante explota Oath / OpenID para usar la información real del banco para obtener el phish para mí. En lugar de que yo use y0urb4nk.com, ahora puedo usar yourbank.com (el sitio real) para tirar del hack. Esta es la falla explicada.
En pocas palabras:
attacker [ exploit oauth/openid ]
generate phishing attack
send vulnerability to target
domain is legitimate attacker abuses this
user falls for exploit and enters data
now send this data to attacker instead of legit domain
game over
corregir? A corto plazo sería dejar de usar OpenID / Oauth hasta que se encuentre una solución