3

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.
  • domains don't matter within the same site. one could use iframes instead of ajax to get new/old cookies. – dandavis Sep 9 '16 at 12:39
4

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
  • the origins were different in this case right ? vulnerable.com and vulnerablesite.com. Yes, I forgot to mention the entire scheme, protocol etc. in the domain name. – qre0ct Sep 9 '16 at 12:51
  • 1
    Ah - didn't notice that. I'll review my answer to ensure it is still accurate. – SilverlightFox Sep 9 '16 at 12:53
  • OK - answer updated (only slight changes were needed, however the overall meaning is the same). – SilverlightFox Sep 9 '16 at 12:57
  • And I was going through ajaxref.com/ch7/cookie.html and it appears that I can read the cookies from the response object. Please correct me if my understanding is wrong. – qre0ct Sep 9 '16 at 12:57
  • 1
    The Check Cookies through Server option? This is because the server outputs the cookie value within the HTML in the AJAX response: <strong>Cookies accessed via server call: </strong>HttpOnlyCookie=myUserName; . If home.html did this (similar to the XST vulnerability), then of course cookies could be read. However, they cannot be read by any other means in a well behaved browser during an AJAX request. – SilverlightFox Sep 9 '16 at 13:11
5

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.

  • yes. I agree to your answer around pages on the same domain and also your arguments about Access-Control-Allow-Credentials and CSRF bypass and Those were exactly my thoughts as well. Also, I would agree it would be a bad idea to include session cookies for any reasons on the response page. I created up this scenario just to clear my confusion. Thanks. – qre0ct Sep 9 '16 at 18:12

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.