document.cookie y su alcance

  

Entonces, en este caso, cuando el script del atacante dice document.cookie ahora,   ¿Podrá el atacante leer la cookie de sesión de la víctima?

No, la solicitud AJAX puede enviarse y leerse debido a la falla XSS, sin embargo, las cookies de la solicitud AJAX no pueden. document.cookie solo revelará las cookies disponibles para la página explotada inicial ( some_page.html ).

  

debido a que la cookie está orientada a /home.html, cualquier solicitud hecha a   /home.html llevará esta cookie a lo largo. Pero porque la respuesta a   /home.html no hace un set-cookie en absoluto, cuando ajax del atacante dice   document.cookie ¿qué será leído exactamente?

Nuevamente, document.cookie estará en el contexto de some_page.html en vulnerablesite.com , por lo tanto, no podrá leer el ámbito de la cookie para /home.html en vulnerable.com .

Incluso si home.html configuraba cookies, la recuperación del encabezado set-cookie estaría prohibida por la mayoría de los navegadores .

  

no tiene idea de cuál sería el atributo de dominio de la cookie en   este caso y cómo afectará la lectura de la cookie de cualquier manera   si es que lo hará.

El dominio se configurará en vulnerable.com como cookie solo para el host . Por lo tanto, no se puede leer por ej. foo.vulnerable.com .

Nota sobre CORS

No olvide que un origen debe tener un protocolo . Por lo tanto

Access-Control-Allow-Origin: vulnerablesite.com

Debería ser, por ejemplo,

Access-Control-Allow-Origin: https://vulnerablesite.com

Si los dominios eran los mismos, las cookies se configuraron en http://example.com/home/ y no tenían solo HTTP, pero había una vulnerabilidad XSS en http://example.com/vulnerable/ , entonces el atacante puede acceder a las cookies. pueden inyectar un iframe en la página y usar un script similar a document.getElementsByTagName("iframe")[0].contentDocument.cookie para acceder a las cookies.

Si los dominios son diferentes, como parecen estar en su pregunta, entonces no, no es posible acceder a las cookies. Todo lo que Access-Control-Allow-Credentials: true hace es decirle al navegador que está bien incluir credenciales (cookies y HTTP Basic Auth) en la solicitud, no expone esas credenciales al solicitante (a menos que el sitio web sea por alguna razón, incluidos los detalles del cookies en la respuesta, que hay muy pocas buenas razones para hacer).

Sin embargo, no es necesario poder acceder al valor real de la cookie para poder explotarla. El atacante realiza solicitudes autenticadas como usuario, y puede omitir cualquier protección CSRF (falsificación de solicitud entre sitios) leyendo el token CSRF del documento HTML que se devolvió desde la primera solicitud. Esto significa que, siempre que todos los puntos finales devuelvan los encabezados CORS relevantes (incluido Access-Control-Allow-Methods si algunos puntos finales requieren POST en lugar de GET), el atacante puede realizar las mismas solicitudes a través de AJAX como hubieran podido en su propia computadora con acceso a la cookie de sesión.