¿Decidir si el usuario ha abandonado el sitio sin cerrar sesión o simplemente ha dejado el sitio abierto para recibir notificaciones sin realizar ningún trabajo?

Sí, para la mayoría de los sitios está bien dejar una sesión válida por horas (por ejemplo, 24 horas).

Como con cualquier pregunta de seguridad, comienza preguntando: ¿qué recursos estoy tratando de proteger? ¿Cuál es el modelo de amenaza? ¿Contra qué estoy tratando de defenderme?

En este caso, le preocupa que un atacante pueda "robar" una cookie de sesión. Entonces, la siguiente pregunta que debe hacerse es: ¿cómo podría un atacante robar una cookie de sesión y cómo los límites de duración de la sesión afectan ese riesgo?

Una forma en que un atacante puede robar una cookie de sesión es si el usuario inicia sesión desde una computadora compartida (por ejemplo, en un cibercafé o biblioteca; o simplemente en una computadora compartida con compañeros de habitación). En ese caso, si el usuario no cierra sesión en su sitio y deja el navegador en funcionamiento, el atacante simplemente necesita sentarse frente a la computadora y comenzar a usar el navegador. La duración de la sesión afecta el alcance del riesgo y la ventana de tiempo de vulnerabilidad. Si caduca una sesión 1 hora después de la última actividad, entonces un atacante tendría que sentarse frente a la máquina del usuario dentro de 1 hora después de que el usuario deje de usar el sitio. Si caduca una sesión 24 horas después de la última actividad, el atacante tiene 24 horas. En general, creo que este riesgo es relativamente modesto: con suerte, los usuarios de un cibercafé cerrarán el navegador y, con suerte, las personas que viven en viviendas compartidas pueden confiar en sus compañeros de habitación al menos hasta cierto punto (de lo contrario, tienen más problemas).

Otra forma en la que un atacante puede robar una cookie de sesión es escuchando a escondidas una cookie cuando se transmite de forma clara, por ejemplo, a través de HTTP mientras el usuario está conectado a través de una red inalámbrica. Aquí los tiempos de expiración de la sesión no afectan el riesgo en absoluto. La mejor manera de defenderse contra esta amenaza es usar HTTPS en todo el sitio y establecer el indicador secure en todas las cookies.

Una tercera forma en que un atacante puede robar una cookie de sesión es mediante la instalación de malware o spyware en la máquina del usuario pobre. Pero si un atacante se las arregla para hacerlo, estás totalmente relajado y los límites de inactividad de la sesión no te salvarán de que ocurran cosas malas. Así que este tampoco debería influir en tus límites de inactividad.

Conclusión: para la mayoría de los sitios web, una sesión de duración de 24 horas (o al menos unas pocas horas) debería estar bien. Para los sitios web en los que espera que los usuarios permanezcan conectados, como Facebook, puede permitir una duración de sesión mucho más larga. Para sitios críticos para la seguridad o la privacidad, como la banca en línea o el acceso a registros médicos confidenciales, sugeriría un temporizador de inactividad: tal vez 15 minutos.

P.S. Es posible realizar un seguimiento cuando un usuario cierra una pestaña, usando Javascript, pero no estoy seguro de si esto supondrá una diferencia de seguridad lo suficientemente grande como para que valga la pena implementarla. El riesgo de seguridad no es muy diferente en el caso de que el usuario haya dejado su sitio abierto en alguna otra pestaña y se haya olvidado de él en comparación con el lugar donde el usuario cerró su sitio pero dejó el navegador abierto. Una forma más sencilla de manejar esto es simplemente que el servidor realiza un seguimiento de la última vez que recibió una solicitud HTTP en esta sesión, y una vez que transcurre un tiempo de caducidad (por ejemplo, 24 horas) sin actividad (es decir, sin solicitudes HTTP), el servidor borra la sesión.

Es una compensación entre usabilidad y seguridad. La banca por Internet cerrará la conexión luego de un tiempo muy breve de inactividad, y los sitios que mencionó (gmail, facebook, etc.) no se desconectarán porque sus usuarios se molestarán cada vez que inicien sesión.

Su decisión se basará mucho más en esta seguridad y hará que los usuarios no estén contentos.

Tecnología al respecto: no estoy seguro de que un javascript capture todos los movimientos que el usuario haga en su computadora, incluso si están fuera de su página web.

Puedes hacer lo que hacen Google, Facebook, etc. (y la razón por la que la gente mantiene la página abierta): agrega algún tipo de widget de actualización mediante AJAX.

Si la página se ha dejado abierta, entonces el widget AJAX se ejecutará y realizará una solicitud en intervalos, manteniendo la sesión actual.

Si el usuario ha cerrado sesión, la sesión comienza a caducar y se puede eliminar después de un tiempo. En teoría, después de que el intervalo del widget haya expirado dos veces, el navegador debería estar muerto de forma certificable: si estuviera vivo, el widget se habría recuperado (pero el usuario podría querer volver a abrir el navegador, o tal vez lo haya reiniciado para actualizaciones, o podría haber sufrido una pérdida temporal de conectividad (especialmente si es móvil); por lo tanto, reduzca el tiempo de recolección de basura a su propio riesgo).

Por supuesto, esto no puede resolver el escenario donde el usuario olvida la página abierta . En este escenario, el widget es realmente contraproducente porque mantendrá la sesión viva y cálida para que cualquier transeúnte la use a voluntad. Necesitará algún tipo de política de inactividad además del envejecimiento de la sesión, y tendrá que comunicárselo a sus usuarios.

Hay formas de detectar la actividad del usuario, pero ninguna es completamente confiable. Mantendría las cosas simples: si la seguridad es primordial, entonces no hay tiempo de espera de widget e inactividad. Si la facilidad de uso es primordial, siga el método del widget y, posiblemente, agregue un "cierre de sesión inactivo" para cerrar la sesión si no se ha detectado ninguna otra actividad excepto la del widget en un razonable tiempo.