¿Cómo evitar que CAS filtre la identidad del usuario a sitios web visitados arbitrariamente?

Navega tus respuestas
3

Resumen

evil.example.com podría usar un marco oculto para solicitar un ticket de CAS de corporation.example.net, luego validarlo para recibir el nombre de usuario del infortunado usuario. De este modo, se deseanomiza de manera efectiva al usuario de CAS en cualquier sitio malicioso que visite.

  • Como autor / mantenedor de un servidor CAS, ¿cómo puedo evitar la desanomización de mis usuarios?
  • Como usuario de CAS, ¿cómo puedo evitar la desanomización de mí mismo?

Fondo:

CAS (Central Authentication Service) es un sistema de inicio de sesión único con un flujo basado en redireccionamiento:

  1. La página del cliente redirige al servidor CAS con un parámetro service que es la URL del sitio del cliente.
  2. El servidor CAS autentica al usuario a través de una cookie existente, una página de inicio de sesión, etc.
  3. El servidor CAS redirige a service URL con el parámetro ticket adjunto.
  4. El cliente llama a un punto final de validación del servidor, intercambiando el ticket por un nombre de usuario.

Ataque

  1. El usuario ya se ha autenticado con el servidor CAS de corporation.example.net y su navegador tiene la cookie de otorgamiento de tickets para ese dominio.
  2. El usuario navega a http://evil.example.com/dancing-bunnies.html , que incrusta http://corporation.example.net/cas/login?service=http://evil.example.com/attack.html como marco. (El marco es menos visible que una redirección, no hay diferencia de seguridad).
  3. El punto final /login del servidor CAS en el marco ve que el agente de usuario ya tiene cookies de inicio de sesión, por lo que redirige ciegamente a la URL del servicio, más un ticket: http://evil.example.com/attack.html?ticket=ST-abc123
  4. evil.example.com lee el ticket de la cadena de consulta y GETs http://corporation.example.net/cas/validate?service=http://evil.example.com/attack.html&ticket=ST-abc123 , que responde con yes\nalice\n .
  5. evil.example.com ahora sabe que el usuario es alice @ corporation.example.net .

Posible mejora

  1. Restrinja el dominio en las URL de los parámetros service a un conjunto seguro conocido
  2. Requieren la interacción del usuario antes de redirigir de nuevo al cliente
  3. Forbid framing (ya sea con encabezados o secuencias de comandos)

¿Alguna desventaja de cualquiera de estos? ¿Hay otras soluciones?

Notas

  • Es probable que no sea práctico restringir el parámetro service a una coincidencia de cadena en un conjunto de URL seguras conocidas, ya que los clientes lo utilizan para llevar el estado a través del proceso de redireccionamiento.

ETA: Estaré muy triste si tu respuesta asume lo siguiente ...

  • ... que el ataque se basa en la comunicación de origen cruzado.
  • ... que estoy diciendo que esto hace otra cosa que no sea desanonizar al usuario
pregunta phyzome 11.06.2013 - 22:02
fuente

3 respuestas

1

Parece que CAS 3 tiene un punto de extensión para Servicios Lista blanca como se indica aquí: enlace

Como indicó en sus notas, esto debería resolver su inquietud y debería estar disponible para usted.

    
respondido por el BoltzmannBrain 01.07.2014 - 20:32
fuente
1

Descargo de responsabilidad: no sé CAS, pero creo que entendí lo que hace y cómo funciona.

Su escenario de ataque no es posible de esta manera, incluso si el sitio web corporativo no tuviera encabezados que eliminen marcos. Estos encabezados que quitan el marco son más para evitar los click-jacking, pero ese es otro tema.

Si el marco realiza una redirección, solo se redirige el contenido del marco.

El sitio malvado no puede acceder a nada del marco que incrusta (ni siquiera la URL), porque está en otro sitio. Si pudiera, entonces tales escenarios serían posibles, pero todos los navegadores modernos (incluso desde IE4 creo) no permiten el acceso entre sitios, por lo que el sitio malvado no puede acceder a la nueva URL y, por lo tanto, no tiene acceso al usuario identificado de IFRAME.

Como usuario, puede protegerse siempre cerrando la sesión y, si algún sitio sospechoso solicita permisos, no se autentique.

Un buen ejemplo de este escenario que mencionas es Facebook. Muchos sitios incorporan la funcionalidad de comentarios de Facebook y otras cosas. Pero no obtienen su nombre de usuario de ninguna manera. Si fuera posible obtener el nombre de usuario de Facebook de alguna manera (los usuarios de Facebook rara vez cierran la sesión), esto sería un gran agujero de seguridad. Puede solicitar la recompensa de errores si encuentra una manera de obtenerla o iniciar sesión y publicar o votar en nombre del usuario.

    
respondido por el http 09.07.2013 - 01:06
fuente
0

Esa es una buena pregunta. Sin embargo, mi comprensión del protocolo CAS es que cuando llama al URI / serviceValidate, CAS verifica si el ticket de servicio obtenido del parámetro de solicitud está disponible en el registro de servicio Y luego comprueba si el servicio es un servicio registrado .

En su ejemplo, evil.example.com no se registrará, por lo que no debería poder obtener el ID DE USUARIO ya que el servidor CAS le lanzará una excepción de servicio no autorizado ;).

    
respondido por el Melvin 18.08.2013 - 19:18
fuente

Lea otras preguntas en las etiquetas

Permitiendo que el usuario acceda a un sitio web protegido por contraseña sin revelar la contraseña WSS (WSS4J): contraseña de texto claro en UsernameToken vs hash de contraseña con sal en la base de datos