¿Cómo administrar una sesión personalizada en una aplicación web?

0

Estaba leyendo la Cheat Sheet de OWASP y algo que se menciona en la fila "Autenticación débil y gestión de la sesión" No tenía sentido para mí.

Se recomienda en la Columna de diseño, que se use la administración de sesión integrada y que los identificadores de sesión personalizados se almacenen en el objeto de sesión nativo y no se envíen como encabezados o cookies adicionales. No entiendo la segunda parte de la declaración. Si no es como un encabezado o una cookie, ¿de qué otra manera puedo establecer / enviar información de sesión adicional? ¿No es una práctica estándar agregar una cookie segura para la función para la que escribo?

¿Qué es un objeto de sesión nativo como se menciona en el documento?

¿En qué se diferencia de la administración de sesión integrada?

    
pregunta user220201 18.05.2015 - 23:11
fuente

1 respuesta

2

Para citar directamente:

  

Utilice solo la gestión de sesiones integrada.

     

Almacene SSO secundario / framework / identificadores de sesión personalizados en el objeto de sesión nativo, no los envíe como encabezados o cookies adicionales.

Lo que esto dice es que, si tienes un sistema secundario que no puede / no puede usar sesiones integradas, no debes enviar ese segundo token de sesión como una cookie o encabezado, sino que debes poner eso token en su sesión incorporada. De esa manera, tiene un solo token de sesión que puede apuntar a otros si es necesario.

Cuando dicen "la administración de sesión nativa", significan algo como $_SESSION en PHP, o el objeto Session en ASP.NET, donde los datos de la sesión se almacenan en el lado del servidor y se mantiene un token en la del lado del cliente para identificar la sesión para ese usuario.

Por ejemplo, digamos que tienes tres aplicaciones web. Posteriormente, implementará un sistema de inicio de sesión único (SSO) para que no tenga que iniciar sesión por separado en cada uno. De acuerdo con las pautas de OWASP, sería una mala idea implementarla de tal manera que al visitar cada aplicación por separado, se reciban tokens de sesión por separado. En su lugar, el SSO debería proporcionarle un único token de sesión, que debe usarse para las tres aplicaciones. Si se requieren identificadores separados para cada uno, estos identificadores deben almacenarse en la sesión datos , para que puedan leerse desde allí.

Los beneficios de esto son:

  • El vencimiento de la sesión principal expira a otros automáticamente, no hay sesiones latentes.
  • Menos superficie de ataque para problemas de administración de cookies (por ejemplo, Secure o HttpOnly flags).
  • Menos probabilidad de pérdida de token de sesión.

Un ejemplo rápido en PHP de cómo podría manejar esto en una aplicación web:

<?php
session_start();
$sid = isset($_SESSION['app3_session']) ? $_SESSION['app3_session'] : NULL;
if ($sid != NULL)
{
    // verify SID for this particular app
}
?>

El SSO crearía la sesión inicial y llenaría el valor app3_session .

    
respondido por el Polynomial 18.05.2015 - 23:25
fuente

Lea otras preguntas en las etiquetas