El último tema que tratar antes de profundizar en la seguridad del manejo de sesiones es el tipo de sesión que se utiliza. Los dos principales acercamientos son cookies y tokens, cada uno con sus beneficios y desventajas.
Manejo de Sesiones Basado en Cookies
También llamado la forma de la "vieja escuela" de hacer las cosas. Una vez que la aplicación web quiere iniciar el tracking, como respuesta, el valor del header "Set-Cookie" se manda. Tu navegador lo interpreta y lo guarda como un nuevo valor cookie. Veamos un header "Set-Cookie":
Set-Cookie: session=12345;
Tu navegador creará una entrada para la cookie llamada session con el valor 12345 que será válido para el dominio desde el que se recibió la cookie. A este header se le pueden añadir múltiples atributos. Si quieres investigar sobre todos pulsa aquí. Los más relevantes son:
- Secure: Indica al navegador que la cookie sólo puede ser transmitida a través de canales HTTPS verificados. En caso de errores de certificados o uso de HTTP, no se transmitirá.
- HTTPOnly: Le indica al navegador que el valor de la cookie puede no ser leído por JavaScript del lado del cliente.
- Expire: Le indica al navegador cuándo el valor de la cookie dejará de ser válido y debe ser eliminado.
- SameSite: Le indica al navegador si la cookie puede ser transmitida en peticiones a través de sitios web (cross-site).
Un concepto clave que recordar con la autentificación basada en cookies es que el navegador mismo decidirá cuándo un cierto valor de cookie será mandado con una petición. Después de revisar el dominio y los atributos de la cookie, el navegador toma una decisión y la cookie se pone automáticamente sin necesidad de código JavaScript client-side.
Manejo de Sesiones Basado en Tokens
Es un concepto relativamente nuevo. En lugar de usar las funcionalidades automáticas de manejo de cookies del navegador, depende del código del lado del cliente para el proceso. Después de la autentificación, la apliación web ofrece un token con el resto del cuerpo. Usando JS del lado del cliente, este token se guarda en el LocalStorage del navegador.
Cuando se hace una nueva petición, el JS debe carggar el token desde el almacenamiento y ponerlo como header. Uno de los tipos más comunes es el JWT (JSON Web Token), que se pasan a través del header Authorization: Bearer. Sin embargo, al no usar el manejador de cookies automático del navegador, es un poco como el lejano oeste (cualquier cosa vale). Aunque hay estándares nada te impide saltártelos.
Ventajas y Desventajas
Los beneficios e inconvenientes de estos métodos son:
| Cookie-Session Management | Token-Based Session Management |
|---|---|
| La cookie es mandada automáticamente por el navegador. | El token debe ser subido al header usando JS client-side. |
| Los atributos de la cookie pueden usarse para realzar la seguridad de la cookie por parte del navegador. | Los tokens no tienen medidas de seguridad automáticas. |
| Las cookies pueden ser vulnerables a ataques CSRF. | Como no se puede añadir a una petición automáticamente y no puede leerse desde el LocalStorage por otros dominios, no existe riesgo de CSRF. |
| Como están relacionadas estrictamente con un dominio en concreto puede ser tedioso usarlas en sitios web descentralizados. | Funcionan bien en aplicaciones web descentralizadas ya que se manejan a través de JavaScript y pueden contener toda la información requerida para verificar el token. |