¿Deben evitarse las variables de sesión?

Solía ​​depender mucho de las variables de sesión en el pasado, pero recientemente he encontrado que muchas de ellas son innecesarias, utilizando cosas como parámetros de cadena de consulta.

Un colega mío se niega a usar variables de sesión. ¿Es este un objetivo realista y deben evitarse las variables de sesión por alguna razón práctica? ¿Se pueden evitar completamente las variables de sesión (excepto las cookies de sesión para permitir inicios de sesión) y esto daría lugar a mejores diseños?

Algunas de las razones que tiene mi colega para no usarlas:

• Naturaleza sin tipo de variables de sesión
• Tiempos de espera de sesión que causan pérdida de estado
• Naturaleza del alcance global de las variables de sesión
• Servidores de equilibrio de carga que pierden sesiones (¿específico de .Net?)
• Grupos de aplicaciones / servidores reiniciando
• Son innecesarios

Si tiene una variable de sesión en su aplicación, pregúntese esto:

Cuando hago clic en el botón Atrás de mi navegador, ¿qué valor quiero que tenga mi variable?

Si la respuesta es "el valor actual", las variables de sesión pueden ser útiles. Un ejemplo sería un carrito de compras: no espera que se eliminen cosas del carrito de compras a medida que retrocede en el historial. Siempre está en su estado actual.

Si la respuesta es "un valor anterior", no debe usar variables de sesión. Los malos usos que he visto incluyen pasar un parámetro entre páginas. Si hago clic en el botón Atrás para volver a una página, la página no necesariamente obtiene el parámetro correcto. Además, si abro dos pestañas, ¿cómo se comportará mi sitio?

Obtener el comportamiento correcto del botón de retroceso no es en absoluto el principio y el fin de todo, pero le ayuda a pensar en un sitio web como una aplicación sin estado. En general, encuentro que los usos apropiados de las variables de sesión son pocos y distantes entre sí.

El protocolo HTTP no tiene estado. Las sesiones son una forma de preservar el estado del cliente en las solicitudes HTTP. Puede elegir hacer eso con el manejo de sesión integrado de una plataforma o hacerlo usted mismo con parámetros de cadena de consulta. De cualquier manera, es necesario algún concepto de sesión para muchas tareas.

Probablemente a su colega no le guste una implementación específica o no haya estado usando sesiones para los fines previstos. Si necesita conservar información sobre una conexión de cliente específica a través de solicitudes HTTP, necesita algún tipo de persistencia de sesión.

Los siguientes problemas son específicos de la implementación:

Naturaleza sin tipo de variables de sesión

Naturaleza del alcance global de las variables de sesión

Servidores de equilibrio de carga que pierden sesiones

Grupos de aplicaciones / servidores reiniciando

Por ejemplo, a menudo trabajo en PHP y almaceno la información de mi sesión en una base de datos relacional. Entonces mis variables de sesión están escritas. El equilibrio de carga y los reinicios del servidor no causan problemas de sesión.

Este es más interesante:

Tiempos de espera de sesión que causan pérdida de estado

Las sesiones se conservan con mayor frecuencia a través de cookies. El cliente puede eliminarlos en cualquier momento. Pero también se pueden conservar mediante un parámetro de cadena de consulta y, por lo tanto, nunca se agota el tiempo de espera en el cliente. El tiempo de espera del servidor depende de usted. Entonces, incluso este problema es específico de la implementación.

No descartemos todo el concepto de sesiones solo porque no nos gusta una implementación particular. Cualquier buen marco de aplicación web facilitará el uso adecuado de las sesiones para preservar los inicios de sesión de los usuarios o retener cualquier otra cosa específica para la visita actual del usuario. El registro de la base de datos de un usuario puede (y debe) usarse para almacenar cosas específicas para ellos cuando inician sesión. Sin embargo, los visitantes anónimos pueden tener información temporal que también vale la pena conservar en su sesión, como una breve lista de páginas recientes visitadas o la preferencia de esconder un aviso que ya han visto. En general, solo la información temporal más pequeña es apropiada para el almacenamiento de la sesión.

Otros han hecho muchos puntos buenos (que evitaré repetir), pero hay un aspecto de la técnica de tu amigo que aún no se ha discutido: la seguridad .

Es imposible saber qué tipo de vulnerabilidades abre sin mirar el código, pero aquí hay algunas cosas que puedo pensar fuera de mi cabeza.

• Fijación de sesión : un ataque poderoso que es un poco más fácil si solo puede hacer que el usuario haga clic en un enlace que ya tiene la información necesaria en la URL (en lugar de intentar que el usuario use una máquina que tenga sus cookies configuradas adecuadamente).
• Inyección SQL (u otra entrada maliciosa) : nunca confíe en nada que provenga del usuario. Las variables de sesión tienen la ventaja de nunca abandonar el servidor, por lo que el usuario no puede cambiarlas directamente. Si bien debe desinfectar los datos antes de ponerlos en la sesión, siempre puede confiar en los valores que obtendrá después. Si todo se pasa a través de la cadena de consulta, tiene MUCHA validación que debe hacer para asegurarse de que no acepta entradas maliciosas.
• Datos corruptos mediante el uso de entradas falsificadas : similar a la inyección SQL, ¿cuántos datos está pasando de un lado a otro? ¿Qué tan crucial es? ¿Puedo cambiar el comportamiento de su aplicación cambiando un valor en la cadena de consulta? ¿Puedo corromper los datos en su servidor cambiando los valores? Si logro dañar los datos en el servidor, ¿afectará a otros usuarios? (Si su respuesta fue "no", mi respuesta es "¿está seguro? Tiene muchos lugares que debe consultar").

Todo esto puede suceder cuando usas Sesiones, pero pueden ser mucho más fáciles si tu amigo no sabe lo que está haciendo.

Las variables de sesión son como las antiguas variables globales básicas hasta cierto punto. El usuario tiene la responsabilidad de realizar un seguimiento de ellos, lo que hay en ellos, su alcance y cómo se utilizan; al igual que en las versiones anteriores de BASIC. Dicho esto, ¿por qué alguien descartaría totalmente el uso de un mecanismo que obviamente está diseñado para ser una parte integral y muy importante del modelo de programación (ASP, MVC, etc.)?

Lo único malo con lo que me he encontrado al usar las variables de sesión es que te obliga a realizar un seguimiento de ellas, a asegurarte de que estén pobladas con datos relevantes y a deshacerse de ellas.

¿No es eso lo que hacemos cuando estamos programando de alguna manera?

Solía ​​pensar como su colega debido a algunas malas experiencias que había tenido problemas de depuración relacionados con las variables de sesión, que en realidad eran solo incompetencia de mi parte. Sí, puede llegar hasta cierto punto sin variables de sesión, utilizando cadenas de consulta, campos ocultos en formularios y otras cosas. Sin embargo, rápidamente se vuelve engorroso hacerlo de esta manera si su aplicación tiene algo más allá del flujo lógico más básico para determinar el estado. También existe el riesgo de seguridad de mostrar el funcionamiento interno de su aplicación a través de cadenas de consulta y campos ocultos, cualquiera de los cuales puede servir como vectores de ataque.

Cuando trabaje con variables de sesión, solo necesita realizar un seguimiento de cuándo se configuran y desactivan, ya que esto determinará el flujo lógico de la aplicación. Es como la gestión de la memoria en un lenguaje como C.

Tenga en cuenta que esto es solo por mi experiencia trabajando con PHP en un proyecto relativamente pequeño sin marcos, las cosas pueden ser diferentes en otras plataformas, pero creo que el principio general todavía se aplica.

Como se indicó anteriormente, HTTP no tiene estado y la variable de sesión lo rompe. El diseño HTTP para estar sin estado ayuda al almacenamiento en caché de los recursos. Para recursos que están disponibles públicamente.

Es posible diseñar un sitio web sin variable de sesión, pero es más difícil. Lo más difícil (en mi humilde opinión) es el elegante inicio de sesión / cierre de sesión, los esquemas de autenticación HTTP no proporcionan las herramientas necesarias para autenticarse a través de un formulario HTML (puede hackear algo con javascript - XHR a https: // untel: passowrd@mydomain.com ) y es aún más difícil cerrar sesión y ser compatible con varios navegadores. hubo algunas discusiones sobre las listas de correo de w3 sobre eso, pero si recuerdo bien, la idea fue descartada.

Por lo demás, debería poder vivir sin variables de sesión. Tendrá algún estado en una base de datos, archivos o en cualquier lugar, pero el uso de variables de sesión debe ser poco frecuente.

Si su usuario tiene un carrito de compras, es una sesión variable solo si se supone que el usuario puede navegar en dos computadoras / navegador sin compartir el carrito.