Use la variable javascript en lugar de la cookie de sesión

2

Decidí sumergirme profundamente en las tecnologías de tipo angular, donde todas las páginas son prácticamente solo una página que nunca se vuelve a cargar. Y en este punto tuve la idea, en lugar de usar cookies (que en realidad no necesito), ¿por qué no autenticarme con el servidor, obtener una clave y mantener esta clave en el ram como una variable de Javascript, desechando la tecnología de cookies? y el letal "este sitio usa cocineros para almacenar, etc." mensaje.

En mi opinión, esto es más seguro ya que no se escribe nada, todo está en la memoria RAM y al menos es tan seguro como con el método de cookies tradicional.

Pero antes de usarlo, quiero preguntarte si crees lo mismo o si se trata de un problema de seguridad mayor del que creo.

    
pregunta Panayotis 19.06.2018 - 00:12
fuente

2 respuestas

4

La principal razón de seguridad para evitar las cookies sería prevenir CSRF , que es Un gol válido. Las cookies no estaban bien pensadas desde el punto de vista de la seguridad. Por otro lado, hay enfoques bien establecidos para evitando CSRF, por lo que no es Una técnica muy valiosa.

Desde el punto de vista de la privacidad, las cookies (especialmente las cookies de terceros) son peligrosas. Por esta razón, algunos usuarios y / o navegadores los bloquean, lo que puede proporcionar a los desarrolladores una razón funcional para usar otra cosa.

Sin embargo, incluso para una aplicación de una sola página (SPA), es probable que desee conservar su token de sesión. La forma estándar de hacer esto desde JS es usar el almacenamiento local (ya sea almacenamiento persistente o de sesión), que es básicamente una manera de almacenar las variables de JS para un sitio en particular a través de las visitas de los usuarios, o al menos la carga de páginas dentro de una sesión determinada. Todos los navegadores modernos admiten almacenamiento local.

El principal inconveniente de la seguridad del almacenamiento local (o cualquier otra forma de realizar la administración programática de sesiones en el cliente, en lugar de confiar en el comportamiento automático de las cookies), es que un atacante que obtiene XSS (secuencias de comandos entre sitios) dentro de su La aplicación web puede robar el token y secuestrar la sesión para hacerse pasar por la víctima, incluso después de que la víctima cierre el navegador (por el contrario, la cookie de sesión típica se marca como httponly , lo que evita que JS lo lea y restringe el secuestro de la sesión a solo como siempre que la víctima deje abierta la aplicación web).

    
respondido por el CBHacking 19.06.2018 - 06:37
fuente
1

Su pregunta se basa en varios supuestos erróneos.

  

desechando la tecnología de cookies y el implacable "este sitio utiliza cocineros para almacenar, etc." mensaje

No sé a qué jurisdicción se refiere, pero en el caso de la UE, no importa si conserva los datos en una cookie o en un almacenamiento local, o en otro lugar, es el uso y el contenido de Datos que determinan la información que debe proporcionar al usuario y para la que necesita su consentimiento, no el sustrato de almacenamiento.

  

todo está en la memoria RAM

No necesariamente. La mayoría de los navegadores mantendrán el estado en todas las sesiones (del navegador, es decir, se separa de todas las demás sesiones que se realizan en TCP, TLS, HTTP), incluido el estado de Javascript. OTOH, las cookies tienen características muy bien definidas.

  

y es al menos tan seguro como con el método de cookies tradicional

¿Entonces, tiene un medio para asegurarse de que no se expone a través de conexiones no TLS implementadas fuera de banda desde el contenido en sí? (por ejemplo).

    
respondido por el symcbean 19.06.2018 - 14:20
fuente

Lea otras preguntas en las etiquetas