¿Rails 4 Security: Can session Fix using Encryption cookies?

He tenido muchos problemas.

after studying Rails guide and Some other resources, I want to know how session fixed attacks occur on User sessions. Al menos sospecho que su papel en la Guía es simple as depicted here.
1)... Crear una sesión válida iniciando sesión
2)... Mantener la sesión activa
3)... Luego obliga al usuario a usar el ID de su sesión, por ejemplo, mediante el uso de ciertas vulnerabilidades xss
Muy bien, pero... ¿Cómo recopila un atacante el valor de su propio ID de sesión? Por defecto, las cookies están encriptadas en Rails 4 +. ¿Entonces, supongamos que no puedo acceder a secret_key_base o cualquier cosa que se utiliza para generar claves de cifrado y firma, qué debo hacer como atacante? Por lo que sé, no puedo alterar una Cookie sin invalidarla, por lo que de alguna manera pasar una Cookie auto - creada a una posible víctima no es una opción.
¿La Guía SECU no está actualizada, o me he perdido un poco? Si esto es lo último...
(como atacante) Cómo puedo leer la información de la Cookie encriptada
¿Cómo debe ser una vulnerabilidad que me permita inyectar el ID de sesión en una Cookie igualmente encriptada en otro cliente? ¿Podría ser un ataque xss? La Guía señala que si un atacante utiliza el siguiente código:
<script>document.cookie="_session_id=16d5b78abb28e3d6206b60f22a03c8d9";</script>
Puede resolver el problema. ¿Pero una vez más, por qué Rails revela su sesión normal al cliente para acceder a ella a través de JavaScript manejado por el cliente? ¿No lo es, por eso todos mis valores de Cookie son simples tonterías, y JavaScript no es accesible (se puede probar a través de la consola), verdad?
¡Gracias por el Consejo!

Soluciones encontradas en otras comunidades de tecnología de red

This is not related to Cookie Encryption (or signature). En ausencia de firma y/o cifrado, el atacante no necesita fijar la sesión con la ayuda de un sitio que almacena los datos de la sesión en una Cookie; Pueden hacer sus propias galletas.
Supongamos que un atacante tiene una manera de inyectar la configuración de la Cookie JavaScript en la página a la que la víctima accederá, es decir an XSS vulnerability. Los siguientes son los resultados del ataque:
  • the attacker visited the web site and obtained a session Cookie.
  • attackers make malicious javascript, exploit the xss Vulnerability, and wait for users to access (or Attract users to access) pages containing malicious javascript Loads.
    <script>document.cookie="_appname_session=(...attacker's session cookie...)";</script>
    
  • a victim appeared and used malicious javascript to Access the page, setting or overwriting its session Cookie with the session Cookie provided by the attacker.
  • if they have been logged on, the website will not identify them as authenticated Users, and may redirect them to the login location.
  • if they are not logged on, they will be redirected to the login page.
  • they used user name and password to authenticate.
  • at this time, both the victim and the attacker have a Cookie containing a session ID that belongs to a authenticated user.
  • Cookie Store, Rails default session Store


    Normalmente, establece algunos valores en la sesión para indicar que el usuario ha sido autenticado. Incluso si es tan simple como session[:logged_in] = true, cambia el valor de la Cookie, e incluso si el ID de sesión es el mismo, el atacante no puede acceder al sitio porque la Cookie del atacante no contiene datos adicionales que indiquen una sesión autenticada.

    Otras políticas de almacenamiento de sesiones


    Aquí es donde este ataque es más factible. Otras tiendas de sesiones todavía usan cookies para guardar el ID de sesión, pero almacenan los datos de la sesión en otros lugares, cache, database, memcached, etc. en este caso, cuando un atacante visita el sitio después de la autenticación de la víctima, la Cookie del atacante (con el mismo ID de sesión) resulta en la carga de la sesión.

    Httponly


    Sin embargo, hay otro obstáculo importante para este ataque HttpOnly cookies.
    Set-Cookie: _appname_session=v%2Ba...; path=/; HttpOnly
    
    Cuando la Cookie se especifica como httponly, al igual que la Cookie de sesión rack/Rails, el navegador no la expone a través de un documento. Galletas. JavaScript no puede leerlo ni sobrescribirlo. Traté de establecer una Cookie de sesión conocida a través del documento. Cookies, pero esto no es posible a menos que primero limpie las cookies existentes. Esto significa que un atacante necesita que un usuario que no tiene una Cookie de sesión acceda a una página con una vulnerabilidad xss antes de iniciar sesión (la vulnerabilidad debe estar en una página sin una Cookie de sesión).