La mejor manera de establecer de forma segura una cookie de sesión en otro dominio

8

Actualmente tenemos 2 sitios http://www.foo.co.uk y https://secure.foo.com .

El sitio www no tiene un certificado SSL y está en un dominio diferente.

Tenemos un botón de inicio de sesión en http://www.foo.co.uk que cuando se hace clic abre un iframe de https://secure.foo.com con un formulario, cuando el usuario inicia sesión crea una cookie de sesión en ese dominio ( foo.com ).

La cookie de la sesión debe copiarse a foo.co.uk para que lo redireccione a http://www.foo.co.uk/setcookie.php?session=abcd1234 , lo que nos permite configurar la misma cookie en el dominio de origen.

Esta no es una solución muy segura, así que he estado investigando cómo hacerlo mejor. La mejor idea que he encontrado es enviar un hash usando algo como HMAC junto con los parámetros al script setcookie.php y luego verifíquelo en el otro extremo antes de crear la cookie.

Si bien esto es mejor, no impide que el hombre en el medio ataque. Teniendo en cuenta que www no tiene seguridad SSL, no creo que pueda evitarlo por completo, por lo que lo mejor sería incluir una marca de tiempo en el hash para que sea válida durante 5 minutos.

¿Alguien tiene alguna idea sobre cómo puedo mejorar esto, o señala algún inconveniente con este enfoque? Estaría muy agradecido.

    
pregunta fire 25.10.2012 - 10:21
fuente

2 respuestas

2
  

botón de inicio de sesión en enlace que al hacer clic abre un iframe

Recomiendo encarecidamente que esto se modifique para que la página actual redirija al sitio SSL o abra una nueva ventana. ¡Como usuario quiero ver 'https' en la barra de direcciones antes de ingresar cualquier token de autenticación!

Sí, usar el mismo ID de sesión en ambos sistemas es inseguro y lo expone al secuestro de sesión. Idealmente, desearía generar un valor diferente que haga referencia a los mismos datos de sesión. Ya que está usando PHP, agregar su propio controlador de sesión es trivial: necesita tomar algunas decisiones sobre qué lado obtiene leer / escribir qué en el otro lado. Usar HMAC o cualquier otro mapeo funcional entre los dos identificadores de sesión no es tan seguro como crear un nuevo identificador aleatorio y vincular las dos sesiones dentro de los datos.

    
respondido por el symcbean 25.10.2012 - 17:35
fuente
4

Como ya notó, la creación de este token en el sitio www no cifrado esencialmente eliminará la ventaja de correr sobre SSL para el sitio seguro, ya que un atacante puede simplemente olfatear el token cuando se transfiere al sitio no cifrado y luego usarlo el sitio cifrado para disfrazarse de usuario.

El hecho de tener un enlace desde el sitio sin cifrar al sitio encriptado en el que inicias sesión te deja abierto a un ataque MITM activo en el que el atacante redirige la solicitud a su propio sitio para obtener las credenciales.

Si no hay una razón particular para no hacerlo, puede colocar SSL en ambos sitios, lo que ayudaría a eliminar el riesgo mencionado anteriormente. Es posible que la antigua razón principal para no usar SSL en todas partes (rendimiento) no se aplique a usted, dependiendo de cuán ocupado esté su sitio y cuánta carga tenga.

Fuera de esas respuestas dependería de tu arquitectura. Por ejemplo, ¿los dos sitios comparten una base de datos? Si es así, ¿podría tener dos valores de sesión diferentes para un usuario (uno para www y otro para el sitio seguro) y correlacionarlos allí?

    
respondido por el Rоry McCune 25.10.2012 - 17:18
fuente

Lea otras preguntas en las etiquetas