document.cookie and its scope

Question

There is some basic confusion that I have.

A non-suspecting victim visits a vulnerable website, vulnerable.com and logs in there. vulnerable.com, post login, sends back a response that has the following HTTP header set,

Access-Control-Allow-Credentials: True
Access-Control-Allow-Origin: vulnerablesite.com

Let us say that the session cookie is scoped to /home.html path alone (which may not make much sense, but let's just assume so for the sake of this discussion) and does not have HTTPOnly flag set.

Now in the same browser he opens a new tab and visits vulnerablesite.com/some_page.html An attacker identifies a stored XSS in vulnerablesite.com/some_page.html and decides to exploit it to gain access to the session cookie of the user on vulnerable.com.

To do so, the attacker injects an AJAX script in vulnerablesite.com/some_page.html, so when the victim visits the page, it will make an AJAX request to vulnerable.com/home.html. Now this request will definitely succeed (no reason for it to not to and also because Access-Control-Allow-Credentials was true) and the response that's received will also be readable by the attacker's AJAX script (because of Access-Control-Allow-Origin was set to vulnerablesite.com, so no same origin policy violation)

When the attacker's AJAX script says xhr.response, this response object will definitely hold the /home.html page.

The main confusion is around the path and domain attributes of the cookie. Questions

1. So in this case when the attacker's script says document.cookie now, will the attacker be able to read the session cookie of the victim?
2. because the cookie is scoped to /home.html, any request made to /home.html will carry this cookie along. But because the response to /home.html is not doing a set-cookie at all, when attacker's ajax say document.cookie what will exactly be read?
3. have no idea about what the domain attribute would be of the cookie in this case and how will it impact the reading of the cookie in anyway if at all it will.

Answer 1

So in this case when the attacker's script says document.cookie now, will the attacker be able to read the session cookie of the victim?

No, the AJAX request can be sent and read due to the XSS flaw, however cookies from the AJAX request cannot. document.cookie will only reveal the cookies available to the initial exploited page (some_page.html).

because the cookie is scoped to /home.html, any request made to /home.html will carry this cookie along. But because the response to /home.html is not doing a set-cookie at all, when attacker's ajax say document.cookie what will exactly be read?

Again, document.cookie will be in the context of some_page.html on vulnerablesite.com, therefore will not be able to read the cookie scoped for /home.html on vulnerable.com.

Even if home.html was setting cookies, retrieval of the set-cookie header would be forbidden by most browsers.

have no idea about what the domain attribute would be of the cookie in this case and how will it impact the reading of the cookie in anyway if at all it will.

The domain will be set to vulnerable.com as a host-only cookie. Therefore it cannot be read by e.g. foo.vulnerable.com.

Note on CORS

Don't forget that an Origin has to have a protocol. Therefore

Access-Control-Allow-Origin: vulnerablesite.com

Should be e.g.

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

Answer 2

If the domains were the same, so the cookies were set on http://example.com/home/, and didn't have HTTP Only set, but there was an XSS vulnerability in http://example.com/vulnerable/, then the cookies can be accessed by the attacker - they can inject an iframe into the page, and use a script resembling document.getElementsByTagName("iframe")[0].contentDocument.cookie to access the cookies.

If the domains are different, as they appear to be in your question, then no, accessing the cookies isn't possible. All Access-Control-Allow-Credentials: true does is tells the browser that it's OK to include credentials (cookies & HTTP Basic Auth) in the request - it doesn't expose those credentials to the requester (unless the website is for some reason including the details of the cookies in the response, which there are very few good reasons to do).

However, being able to access the actual value of the cookie is not necessary to be able to exploit it. The attacker is make authenticated requests as the user, and they are able to bypass any CSRF (Cross Site Request Forgery) protections by reading the CSRF token from the HTML document that was returned from the first request. This means that, provided that all endpoints return the relevant CORS headers (including Access-Control-Allow-Methods if some endpoints require POST rather than GET), the attacker can make the same requests via AJAX as they would have been able to on their own computer with access to the session cookie.