1

A website exposes this function: https://test.com/getSessionCookie When an authenticated user clicks on it he gets an html page with his cookie. Could be this exploited in some ways?

1

An interesting kind of attack that might work in this case would involve iframes (if allowed), social engineering, and a confused deputy issue (where the confused deputy is the user).

You might create a malicious website that contains a fake CAPTCHA request, where the CAPTCHA code comes from the user's cookie and is displayed with an iframe. So, for example, you could place the page that displays the cookie inside an iframe and position it carefully so that it looks good enough. Then show the user a page that says: "Our system needs to make sure you are a human, please copy the following code and paste it in the field below".

That was the first example that crossed my mind, but maybe you could come up with better tricks to convince the user to copy the code and send it to you. You might try to convince the user that the code is a temporary password to access a private area, or an error code they have to communicate to you, or a URL they need to visit. I'm not sure if the user would be able to copy-paste a text string (the fake URL) when part of the string comes from an iframe (the cookie), but you could try.

0

If this specific page is vulnerable to XSS then the cookie could be extracted by an attacker from the DOM on this page. If this cookie itself contains sensitive information or if this cookie could be used from within another browser to hijack the existing connection then this would be a security problem.

If these problems (XSS, sensitive data, hijacking from within another browser) actually exist is not known though based on the provided information. Thus maybe an exploit could be crafted or maybe not.

0

If the page works correctly (with correct response headers), then it is not exploitable. If you can provide response headers of this endpoint, it will be very helpful.

For now, i will list some of potential exploits for this case.

  • If anywhere in the website is vulnerable to XSS, then you can use XSS to get victim's session cookie on /getSessionCookie endpoint. It turns your XSS into an account takeover.
  • If /getSessionCookie is vulnerable to web cache poisoning, then you can still victim's session cookie by exploiting it.
  • If you can somehow inject a cookie into victim browser, you may get XSS by injecting XSS payload into cookie value, and when victim visits /getSessionCookie, XSS will trigger, account takeover again.
  • Check all JS files in /getSessionCookie endpoint, maybe one of these JS files contains victim's cookie too. Then you can steal JS file content with cross-origin request.

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.