¿Es correcto usar el campo de formulario (oculto) para almacenar el token de sesión?

Para estar protegido contra CSRF y al mismo tiempo endurecerse contra XSS, almacene sus ID de sesión en cookies (con el distintivo httpOnly) y use tokens de formularios separados vinculados a la sesión que valide en POST. Al combinar estos métodos, evita que un atacante que haya descubierto que XSS robe los ID de sesión, mientras que todavía protege contra CSRF de una manera significativa. El uso de la ID de sesión como token de formulario permite a un atacante robar la ID de sesión a través de XSS.

En mi humilde opinión, la mayor desventaja es que necesita agregar explícitamente el código para volver a llenar el identificador de la sesión en todas y cada una de las páginas, posiblemente en varios lugares. El uso de un campo de formulario solo funcionará cuando tenga un formulario y esa es la única forma de navegar fuera de la página.

Por lo tanto, también debe agregar código para analizar cada href en la página y agregar el ID de sesión (ya que no desea enviar su ID de sesión a otros sitios).

¿Qué pasa con las solicitudes de ajax? Javascript impulsado por la navegación?

También debes cambiar el ID de sesión en la autenticación, por lo que también has roto el comportamiento del botón Atrás.

Sí, puedes resolver todos estos problemas lanzando código y esfuerzo, pero más código = más errores = menos seguridad.

Otra consideración es que algunas aplicaciones usan identificadores de sesión múltiples; administrar esto fuera de las cookies sería un PITA aún más grande.

No, no debe usar los parámetros GET o POST para los identificadores de sesión. La ID de sesión debe solo ser transmitida a través de las cookies de HttpOnly.

Hay al menos tres razones para hacerlo:

• ataques de Fijación de sesión . El atacante puede tentar al usuario víctima a visitar una página con un formulario que contiene su ID de sesión en un campo oculto. El envío del formulario hará que la víctima se autentique como atacante (y cualquier acción que realice posteriormente en el sitio web de destino se realizará con las credenciales de los atacantes)

• cualquier defecto XSS en su sitio web permitirá directamente al atacante secuestrar la sesión, mientras que el almacenamiento de la identificación de la sesión en las cookies de HttpOnly evita que esto suceda

• ataques de extracción de contenido: existen algunas corrección de la interfaz de usuario para extraer el contenido HTML de un sitio web de destino. , lo que lleva a secuestrar la sesión del usuario. Un ejemplo de tal ataque que requiere la interacción del usuario es extracción de acceso a token de Facebook , que implica mostrar la fuente HTML de un sitio web de la víctima en un IFRAME invisible y atraer al usuario para que lo seleccione y lo arrastre hacia el área de texto del atacante; Si el ID de sesión está incluido en el documento HTML, esto revela el ID de sesión al atacante. Además, cuando el sitio web permite la comunicación entre dominios (por ejemplo, con el uso de crossdomain.xml permisivo), el contenido también se puede recuperar a través de Flash sin la interacción del usuario. Por lo tanto, la ID de sesión nunca debe mostrarse dentro del origen de la página HTML.

Para detener CSRF, es importante incluir también un token CSRF en un campo de formulario oculto o en la URL de cada solicitud POST. Sin embargo, el token CSRF no necesita contener el ID de sesión, y es más seguro si no contiene o revela el ID de sesión. Una opción más segura es utilizar un nonce aleatorio o un hash unidireccional del ID de sesión como el token CSRF.

Tres enfoques comunes para la transferencia del Identificador de sesión entre el navegador y el servidor

1. Cookie
2. Campos ocultos
3. URL

Todos tienen sus ventajas y desventajas, pero como ha preguntado sobre Hiddel Fields solo aquí hay algunas ventajas y desventajas

• Adv: Menos propenso a CSRF ya que el Identificador de sesión no viajará en la Cookie y no será enviado implícitamente por el navegador
• DisAdv: si el desarrollador utiliza un método GET o agrega un parámetro para URL, su identificador de sesión se expondrá en el historial del navegador, los registros de proxy, los registros del servidor web, etc.
• DisAdv: los identificadores de sesión se almacenan en caché junto con la página si el almacenamiento en caché no está deshabilitado
• Adv: No debe preocuparse por marcar las cookies como seguras o HTTPOnly, etc. o preocuparse por la caducidad de las cookies.
  • DisAdv: debe devolverlo en todas las respuestas, aumentando el tamaño de su respuesta
  • Adv: No debe preocuparse por la desactivación de las cookies en los navegadores de los usuarios

Eso es lo que puedo pensar de inmediato, otros pueden indicar más ventajas y desventajas

Y sí, estoy asumiendo que usted ha escrito correctamente el código de administración y seguimiento de sesión del lado del servidor y la lógica de cierre de sesión