¿Es segura la siguiente solución de autenticación o me falta algo?

Question

¿Es segura la siguiente solución de autenticación o me falta algo?

#1 de Jay (2 votos)
#2 de symcbean (2 votos)

4

Context:

Tengo dos servidores web ServerA (pila LAMP) y ServerB (pila ASP.NET). Creo que la tecnología (con suerte) no importa. Ambos servidores requieren autenticación y, supuestamente, hacen bien su trabajo, si no está fuera de alcance en esta pregunta.

Tarea:

Me gustaría implementar una página con contenido iframe. ServerA sirve el contenido externo ServerB sirve el contenido interno (el iframe). Los servidores están en el dominio diferente . Cuando el usuario X se registra en el Servidor A y navega a la página, me gustaría mostrar un personal y contenido sensible proveniente del ServidorB en el iframe. El contenido pertenece a la identidad del usuario X en el servidor B.

Solución propuesta:

ServerA y ServerB tienen un secreto compartido (lado del servidor)
Los usuarios se replican de ServerA a ServerB. Los nombres de usuario coinciden, las contraseñas en ServerB se generan aleatoriamente y no se usan en absoluto. (sigue leyendo)
ServerA autentica al usuario a través de https usando una autenticación basada en formularios
La página externa contiene el siguiente html fragement donde la extensión .any en la url está configurada para ejecutarse y responder en el servidor, por ejemplo .aspx o .cshtml o .php etc:

.

<img src="https://serverb.com/dummy.any?parameter=crypted_username_and_date_using_thesecret" style="display:none;" />

En ServerB, cuando se recibe una solicitud al dummy.any url descifra el parámetro, realiza algunas comprobaciones y en la respuesta establece una cookie cifrada que contiene el nombre de usuario. La clave de cifrado podría ser el secreto compartido o, mejor aún, puede ser el secreto privado de un ServerB.
En ServerB, cuando se recibe una solicitud a la página interna (el iframe) debe contener la cookie, lo que se configuró para este mismo dominio ( enlace ) si la cookie está allí y el usuarioX existe, y digamos que, a los 5 minutos, el período de tiempo está bien, entonces el Servidor B usa su subsistema de autenticación para iniciar sesión en el usuario mediante programación (no se proporciona una contraseña). (el subsistema de autenticación establece sus propias cookies o lo que sea, esta caja negra esperemos en nuestro punto de vista)
Después de esto, ServerB sirve contenido confidencial que pertenece a userX.

Tenga en cuenta que soy un desarrollador y no un experto en seguridad. Por eso pregunto antes de implementar un agujero de seguridad.

web-application authentication cookies crossdomain

pregunta g.pickardou 22.03.2016 - 14:16

fuente

2 respuestas

Lea otras preguntas en las etiquetas web-application authentication cookies crossdomain

¿Debería 'openssl Verify' reconocer una restricción de 'Longitud de ruta' excedida en una CA raíz / intermedia? Cómo detectar el uso de mimikatz en la LAN

score 2 · Answer 1

No estoy seguro de que esto deba ser una respuesta, pero tengo mucho que escribir para un comentario ...

Lo que estás sugiriendo me parece bien, con algunas suposiciones:

El secreto compartido es bueno: no hay 'test123' etc.
El cifrado que usas es bueno. No ROT13;)
Los nombres de usuario distinguen entre mayúsculas y minúsculas, suena obvio, pero puedo imaginar que el usuario abc y obtener acceso a la información de aBc del usuario

Como director creo que funciona. Lo único en lo que puedo pensar es si un usuario puede registrar de alguna manera una cuenta en el servidor A que ya existe en el servidor B, pero estoy seguro de que lo ha pensado.

Obviamente, si tiene otros problemas de seguridad (vulnerabilidades en cualquiera de los servidores, los ataques web habituales, etc.), todas las apuestas están desactivadas.

score 2 · Answer 2

El problema para mí es que, en ausencia de la administración de la sesión, la solicitud al servidor B es susceptible de ataques de repetición. Es de esperar que TODAS las comunicaciones entre los servidores y el cliente se realicen a través de HTTPS, no solo la autenticación (de lo contrario, es un gran problema de seguridad), lo que reduce la posibilidad de interceptación. Sin embargo, 5 minutos es mucho tiempo para que el token sea válido en el servidor remoto. También significa que deberá asegurarse de que los relojes en los servidores estén sincronizados.

¿No sería más simple pasar un token único, con marca de tiempo y de caducidad rápida en la URL del iframe?

Una solución alternativa sería que el servidor A solicite una contraseña única al servidor B cuando se solicite la página externa, e incluya esa en la URL del iframe. Pero eso no se escala tan fácilmente.