Estos son los dos métodos que me gustaría agregar con los que ya tenías:

• Insertando ID de sesión en la URL:

  1. Primero, usted (el atacante) debe conectarse al servidor web y se le emitirá un ID de sesión válido.
  2. Luego, debe crear un vínculo con el ID de sesión y enviarlo a la víctima. URL se ve como: enlace
  3. Luego, la víctima hace clic en la URL y se realiza una solicitud al servidor web con el id. de sesión proporcionado por el atacante.
  4. El servidor cree que la víctima ya tiene el ID de sesión y comienza a usar el ID de sesión sin proporcionar una nueva sesión.
  5. Ahora la víctima inicia sesión en la aplicación y el atacante podrá secuestrar su sesión.

Nota: este método solo funciona si el ID de sesión es el mismo antes y después del inicio de sesión.

• Uso de la división de respuesta HTTP:

Si el sitio es vulnerable a la división de respuestas HTTP, un atacante puede insertar un encabezado Establecer cookie en respuesta con el id de sesión generado por el atacante.

Además de tu lista:

Subdominio no controlado

Su sitio se ejecuta en example.com , aunque el atacante controla bob-usercontent.example.com . Esto podría ser a través de un diseño deficiente o un administrador del servidor ha creado un subdominio para un usuario que desconoce las vulnerabilidades que esto abre con las cookies.

El atacante configura su sitio web para generar el encabezado:

Set-Cookie: sessID=1234; Domain=example.com

y luego incita a su víctima a visitar bob-usercontent.example.com . Esto podría ser cualquier recurso, incluida una imagen incrustada en otro sitio.

Cuando el usuario ingresa a example.com e inicia sesión, la cookie iniciará sesión en el atacante.

Subdominio inseguro

Similar a lo anterior, pero esta vez no hay ningún defecto de diseño.

static.example.com contiene una vulnerabilidad XSS basada en DOM (por ejemplo).

El atacante incita al usuario a visitar

http://static.example.com/page.html?name=<script>document.cookie = "sessID=1234; Domain=example.com";</script>

(Por supuesto, el parámetro name estaría codificado en porcentaje, pero se deja como está aquí para facilitar la lectura).

Cuando el usuario ingresa a example.com e inicia sesión, la cookie iniciará sesión en el atacante.

Falta de política de seguridad de transporte estricta de HTTP

El usuario visita sitios web arbitrarios a través de HTTP.

El atacante Man-In-The-Middle intercepta una de estas solicitudes y la redirige a http://example.com . El atacante también intercepta esta solicitud y responde con su propia página que establece el siguiente encabezado:

Set-Cookie: sessID=1234

Cuando el usuario visita https://example.com , la cookie ya está establecida y, al iniciar sesión, el atacante inició sesión. Más información en HSTS aquí.