¿Es seguro este diseño de SSO?

Question

¿Es seguro este diseño de SSO?

#1 de Bob Watson (1 votos)
#2 de rook (1 votos)

4

Estamos trabajando en una implementación de SSO que se usaría en todos los dominios. Me doy cuenta de que hay modelos de trabajo comprobados como CAS para esto, pero estoy jugando con un enfoque diferente y quiero recibir comentarios de todos ustedes para ver si esto es seguro o no. La premisa básica es que no queremos utilizar redireccionamientos si no tenemos que hacerlo y queremos que los sitios de productos puedan diseñar sus propias páginas de inicio de sesión. Esto apunta a IE8 +, FF moderno y webkit solamente. Entonces, sin más dilación la implementación:

El cliente navega al sitio del producto A.com. No tienen una cookie de sesión para a.com, por lo que el sitio inicia el script de autenticación principal.
El script principal crea un iframe que carga una página desde el servidor de autenticación en auth.com. Auth.com valida la solicitud basándose en el encabezado del remitente y si el remitente no es de confianza, responde con x-frame-options: DENY y / o una redirección de eliminación de marcos.
El script en esta página (el script enmarcado) realiza una solicitud ajax al servidor de auth.com solicitando un token de tiempo de SSO 1 (1TT).
El cliente no tiene una cookie de auth.com, por lo que se rechaza, y el script iframe le dice al script principal que cree un formulario de autenticación usando window.postMessage (y el script principal valida el origen) para comunicarse, ya que es dominio cruzado.
El usuario ingresa sus credenciales y pulsa enviar.
Las credenciales se pasan del script principal al script enmarcado a través de postMessage nuevamente, y el script enmarcado los usa para iniciar sesión en auth.com, recibiendo una cookie auth.com y una 1TT.
El 1TT se devuelve a la secuencia de comandos principal.
La secuencia de comandos principal pasa el 1TT al servidor de A.com.
A.com usa 1TT para obtener la información del usuario del servidor de auth.com a través de una API interna privada, y auth.com invalida el 1TT por lo que no se puede usar nuevamente.
A.com devuelve una cookie de sesión para A.com para el cliente, y ahora el cliente continúa con su negocio en A.com.
Luego, el cliente navega a B.com, pero nuevamente no tiene una cookie de sesión para B.com. La secuencia de comandos principal se ejecuta de nuevo, lo que crea un iframe nuevamente que apunta a auth.com. El script de iframe solicita un 1TT de auth.com, y como tiene una cookie de sesión para auth.com, esta vez obtiene uno.
El 1TT pasa del script iframe al script principal al servidor de B.com, que lo utiliza para obtener al usuario de auth.com y emitir una cookie de sesión para B.com.

Mi principal preocupación es en el paso 2. ¿Es esta una forma sólida de evitar el encuadre malicioso? ¿A qué otras vulnerabilidades de seguridad es susceptible?

Editar: todos los sitios y scripts se cargarán HTTPS.

sso

pregunta rbrc 15.02.2013 - 20:27

fuente

2 respuestas

Lea otras preguntas en las etiquetas sso

¿Es posible explotar XSS dentro del encabezado User-Agent? [duplicar] ¿Hay información pública sobre proyectos de código abierto de Java auditados?

score 1 · Answer 1

Realmente no hay suficiente información en tu lista (tan difícil como es creer, con 12 pasos y todos) para responder correctamente, pero como mencionaste en tu comentario anterior, esto es muy parecido al modelo StackExchange.

Con eso en mente; ¿Ha considerado ejecutar su propio proveedor de OpenID ? La especificación de protocolo se parece bastante a lo que estás buscando. Este también es un modelo bien probado, por lo que muchas de las preocupaciones ya han sido bien resueltas. OAuth puede ser adecuado, pero está diseñado para tokens de acceso limitado: no sabe lo que está haciendo para decir cuál es más apropiado.

Regresando a tu modelo: lo que has especificado se ve bien, aunque como está escrito, hay una mezcla de cosas 'modelo' y cosas de 'implementación' que hacen que sea un poco difícil de analizar. Confía en el remitente, pero parece que en este escenario, falsificar el remitente solo registrará un cliente en un sitio diferente al que tendrían acceso de todos modos. Sin embargo, depende de referer . ¿Tal vez solo cargue el marco con una solicitud GET incluyendo el referente?

También confías en la capacidad de pasar información de un lado a otro entre marcos; es posible que desee considerar el uso de una página provisional en auth.com en su lugar (es decir, reenviar usuario a auth.com, si el usuario ya inició sesión allí, vuelva a POST a enlace con 1TT). El uso de iframes complica las cosas (¿Qué sucede si ya está en un marco? Está confiando en el navegador aquí para "salir" con éxito, ¿podría subvertirse al jugar con el DOM?). Usted puede ser capaz de hacer esto seguro, pero es un factor de complicación, y el enemigo de la buena seguridad tiende a ser esquemas demasiado complicados.

score 1 · Answer 2

Este diseño de SSO tiene una serie de limitaciones técnicas que imposibilitan su implementación. Hay problemas de seguridad con este diseño.

La vulnerabilidad peor que implementa este diseño es OWASP A9-Insufficient Transport Layer Protección . Se debe usar SSL para proteger toda la información de autenticación, por lo tanto, si derrama una cookie de autenticación a través de HTTP, una sesión podría ser secuestrada. Entonces, si un usuario en una red wifi se autenticara con este diseño de SSO, podría hackear su cuenta con una herramienta como firesheep .

# 2 no es posible: El sitio de origen A.com debe cargar el iframe de autenticación mediante una página HTTPS. Sin embargo, al hacer esto, faltará el elemento de encabezado referer y no hay manera de verificar de dónde se origina la solicitud. Propuesta de Encabezado de Origen de Mozilla está tratando de solucionar este problema, pero No es compatible con todos los navegadores. OAuth utiliza una URL de devolución de llamada firmada para asegurarse de que un navegador se autentique en un dominio de confianza .

Para # 9, en lugar de compartir datos de usuario con "API interna privada", intente usar un estándar público como OAuth. De hecho, lo que ha descrito suena muy parecido a OAuth de 3 patas . OAuth es probablemente la forma en que se autenticó en enlace para hacer esta pregunta, y se ha comprobado que es seguro.