php - ejemplos - Integración de sesión, ¿este enfoque es seguro?
django (4)
Un usuario inicia sesión utilizando la autenticación Laravel predeterminada, que coloca una cookie encriptada en el navegador y guarda la sesión en la base de datos.
El usuario se traslada a una página ASP clásica, donde verifico el valor de la cookie, obtengo el hash y llamo a la aplicación laravel para que pase el hash del ID de la sesión.
Luego uso eso en laravel para ver si hay una sesión activa para esa identificación, y si es así, devuelvo la verdad, para que el usuario pueda iniciar sesión, en asp clásico.
En cada solicitud de página en la aplicación clásica, verifico la última_actualidad_data en el archivo db y la actualizo en cada página. Todo el inicio y cierre de sesión se realiza en laravel, y el clásico se basa en la base de datos para ver si una sesión está activa.
También llamaría a una url pública para obtener variables de sesión y agregar variables de sesión usando laravel, ya que está todo encriptado y usar asp clásico para esto sería difícil.
El único riesgo que veo es el secuestro de la sesión, pero no creo que sea un riesgo mayor al habitual.
¿Es importante bloquear el URL de laravel que llamo para verificar si es una sesión válida?
¿Me estoy perdiendo un agujero de seguridad aquí?
Aparte del secuestro de la sesión, no. Esta es la manera estándar en que las aplicaciones interactúan internamente. Por supuesto, podría haber una mejor manera de obtener los datos si elige un tipo diferente de tienda de sesión que no sea su base de datos, Memcached, por ejemplo.
Hay un par de cosas que se pueden hacer.
- Haz el canal HTTPS. Será casi imposible olfatear su capa de transporte.
- En lugar de interactuar con su cookie, podría usar un JWT para realizar esta tarea. Lo cual lo ayudará a usar la funcionalidad existente en su sistema al mismo tiempo que se conecta con el sistema ASP. Puede escribir un pequeño servicio web REST que permite que ASP se conecte. Podrías usar esta lib . Puede consultar este artículo que le dará una idea de cómo se debe hacer.
Por favor, avíseme si necesita más información.
¿Este método es seguro?
Por lo que has dicho, probablemente no has abierto ningún agujero de seguridad. La cookie de sesión no está encriptada en la máquina de los usuarios, pero se asegura de que esté encriptada entre sus máquinas y la suya, así como entre cada una de sus máquinas. Debe asegurarse de haber configurado la Bandera segura para ayudar a evitar que la cookie se envíe accidentalmente a través del transporte tradicional no encriptado (HTTP), pero como se indicó, esto no afecta el almacenamiento de la cookie.
Habiendo dicho eso, básicamente estás secuestrando tus propias sesiones de usuarios. Si bien es posible que no se introduzca un orificio ahora, está debilitando potencialmente todo el sistema, lo que podría ocasionar un agujero en el futuro.
Hay una mejor manera de hacerlo?
Esta podría ser una pregunta tonta, pero ¿estás seguro de que necesitas la sesión? Si está haciendo malabarismos con las credenciales entre los servidores, parece más bien que quiere usar los tokens de acceso y eliminar la sesión.
Usar Access Tokens es similar al uso de sesiones, pero necesita hacer que sus servicios sean sin estado. Esto significa que ya no se almacena información sobre el usuario que ha iniciado sesión en una máquina específica, por lo que deberá extraer todo lo que necesite de la base de datos cada vez que acceda a un servidor que requiera esa información.
Esto es algo bueno a largo plazo, ya que es mucho más fácil escalar sus servicios cuando no necesita preocuparse tanto sobre dónde está la sesión y qué hay dentro de ella.
OAuth 2.0 es un estándar ampliamente utilizado ( Facebook , Twitter , Google ) y fue diseñado específicamente para ser fácil de usar. El RFC es complejo, pero hay un registro de buenas guías por ahí, no se preocupe.
El único inconveniente leve (si se puede llamar así) para OAuth 2 es que DEBE pasar por una conexión cifrada. Si su caso de uso no puede garantizar el cifrado sobre SSL o (preferiblemente) TLS, entonces debe usar OAuth 1.0 (CON revisión A ) en su lugar.
Esto se debe al hecho de que OAuth 2.0 expone su token "secreto" en las solicitudes, mientras que OAuth 1.0 solo lo usa para proporcionar un hash de firma. Si toma esta ruta, es aconsejable usar la biblioteca de otra persona, ya que el hash es muy específico.
Mejoramiento adicional
(Nota: esta sección se agregó después de que se aceptara la respuesta)
Un sistema que he estado explorando recientemente es Json Web Tokens . Estos almacenan información sobre el usuario para guardar cada máquina repetidamente buscándolo en una base de datos. Debido a que el token tiene hash con un secreto, puede estar seguro de que, siempre que su secreto no esté expuesto, un token válido representa un usuario que ha iniciado sesión correctamente, sin tener que tocar la base de datos.
Debes evitar poner algo demasiado personal en los tokens si es posible. Si debe almacenar información privada o secreta en el token, puede encriptarla, o puede usar un proxy de caché inverso para intercambiar el JWT por un token de seguridad tradicional. Inicialmente, esto parece frustrar el propósito, pero significa que algunos de sus servicios pueden no necesitar acceso a la base de datos en absoluto.
No soy un experto en seguridad, pero no veo un problema con esto. El manejador de sesión de la base de datos Laravel empaquetado funciona de la misma manera. La cookie contiene un hash que hace referencia a un registro en la base de datos. Los datos de la sesión están codificados en base64, pero eso no está ni aquí ni allá. Creo que en realidad podría evitar rodar el suyo y simplemente usar DatabaseSessionHandler de Laravel.
Iluminar / Sesión / DatabaseSessionHandler
... Acabo de leer un poco más en profundidad en su pregunta y noté la parte sobre la URL pública para establecer y recuperar los datos de la sesión. Creo que esta es una muy mala idea. Principalmente porque brindará una puerta abierta al usuario final, permitiéndole leer y escribir datos de sesión . Esto solo puede terminar mal.
Como dije antes, los datos solo están codificados en base64, así que creo que podrás analizarlos, leerlos y escribirlos en el contenido de tu corazón dentro de asp.
Editar
Ok ... creo que esta es la última edición. Los datos están serializados por php y codificados en base64. Esta pregunta parece que puede ayudarte con ese fin. Si no es así y un punto final API es la única forma, encuentre alguna manera de evitar que el usuario final acceda a él.