Gestión de sesiones en HTTP

HTTP es un protocolo «sin estado». Lo que significa que no existe un estándar «incorporado» para realizar un seguimiento de las requests interrelacionadas. Cada solicitud se trata como independiente. Actualmente, la mayoría de las aplicaciones web utilizan HTTP 1.1, que se lanzó en 1996. Estas aplicaciones web son muy avanzadas y generalmente manejan operaciones complejas que requieren más de un par de requests/respuestas para completarse, esto requiere algo para rastrear el estado actual de operación. Estas aplicaciones también presentan contenido personalizado para cada usuario. Esto requiere identificar a un usuario a través de múltiples requests. Entonces debe haber algo que agregue una «mejora» a HTTP.
Hay soluciones que son el resultado del pensamiento inteligente de los programadores web.

HTTP usa una arquitectura cliente-servidor y usa TCP como su protocolo de transmisión y se pueden enviar múltiples requests a través de una sola conexión TCP, pero también se consideran independientes tanto para el cliente como para el servidor. Hay dos aspectos de la sesión en HTTP como se discutió anteriormente. Existen principalmente dos formas de lograr el seguimiento de las requests.

1. Parámetros de solicitud:
El token que representa el estado actual de un proceso de varios pasos o identifica a un usuario puede ser almacenado por el servidor en la página web en un campo de formulario, que se enviará automáticamente cada vez que el usuario realice una acción. El token está contenido como un valor de un campo de entrada. Este token se puede enviar como un parámetro de solicitud GET o como un parámetro de solicitud POST. Los parámetros de solicitud en una solicitud GET están incrustados en la URL y se registran en el historial del navegador. Si bien POST envía los parámetros como cuerpo de la solicitud, no se incrusta en la URL y tampoco aparece en el historial del navegador. Obviamente, para enviar información confidencial se deben usar requests POST, mientras que las requests GET se pueden usar para información confidencial. Por ejemplo, si el token es un identificador para un usuario, siempre debe enviarse en una solicitud POST.
Hay otra forma de enviar identificadores en requests GET. Que usa el nombre de la ruta en lugar de los parámetros.

2. Cookies
Las cookies son pares de nombre y valor que se almacenan en el navegador y se envían automáticamente en requests posteriores. El servidor los genera y los envía al cliente mediante el encabezado HTTP «set-cookie». Una cookie se envía utilizando el encabezado «cookie».

El encabezado de la cookie envía pares de nombre y valor separados por punto y coma. El encabezado set-cookie contiene directivas y parámetros adicionales para las cookies. Estos ayudan al navegador a comprender cómo y cuándo enviarlos.
Los parámetros más comunes son: dominio, ruta y expira, mientras que las directivas son: «seguro» y «solo http». El parámetro de dominio especifica el dominio para el cual la cookie es válida, la cookie también será válida para todos sus subdominios. El parámetro ruta especifica la ruta URL. Caduca se explica por sí mismo.
La directiva «segura» indica al navegador que envíe la cookie solo a través de HTTPS, mientras que «httponly» indica al navegador que no permita que el JavaScript del sitio web acceda a la cookie. Esto se hace para evitar la explotación de XSS que roba cookies, en caso de que el sitio web sea vulnerable a XSS.

Prácticas
recomendadas Las sesiones de seguimiento requieren la generación, transmisión y almacenamiento de tokens confidenciales. Cualquier configuración incorrecta en cualquier etapa puede poner en riesgo la seguridad de los datos de los usuarios. Hay algunos puntos que deben tenerse en cuenta al desarrollar una aplicación que mantiene sesiones de usuario.

• Nunca envíe ningún token a través de un canal no cifrado (HTTP).
• Invalide los tokens en el lado del servidor cuando el usuario cierra la sesión, simplemente borrar las cookies en el navegador del usuario es insuficiente y puede llevar a la toma permanente de la cuenta.
• Implemente siempre la protección CSRF en acciones confidenciales que requieran autenticación.
• Nunca envíe tokens anti CSRF en una solicitud GET (y ni siquiera piense en enviar tokens de sesión en una solicitud GET)
• Siempre use nonce y padding mientras genera tokens confidenciales y evite usar esquemas de codificación reversibles como Base64.
• No almacene contraseñas en el servidor en texto sin formato. Siempre hash ellos y almacenar el hash. Esto protegerá al usuario de un evento desafortunado de violación de datos.