I am trying to understand this session fixation attack that was described in theory against mtgox (a well known bitcoin exchange):
I discovered session fixation leading to account takeover. Long story short, here's exploit:
name='document.cookie="SESSION_ID=SID; Domain=.mtgox.com; Path=/code"'; location='https://payment.mtgox.com/38131846-a564-487c-abfb-6c5be47bce27/e6325160-7d49-4a69-b40f-42bb3d2f7b91?payment[cancel]=cancel';
Create Checkout button https://www.mtgox.com/merchant/checkout and set Cancel URL to javascript:eval(name);
Put your payload in window.name and redirect to "https://payment.mtgox.com/38131846-a564-487c-abfb-6c5be47bce27/e6325160-7d49-4a69-b40f-42bb3d2f7b91?payment[cancel]=cancel" (GET-accessible action). MtGox has X-Frame-Options so it won't work in iframe.
User is supposed to wait 5 seconds until setTimeout in JS assigns location to our javascript: URL.
Get some guest SID with server side and fixate it using this XSS. It's called Cookie tossing, and our cookie shadows original SESSION_ID because more specific Path-s are sent first.
document.cookie="SESSION_ID=SID; Domain=.mtgox.com; Path=/code"Close the window.
Someday user logs in, and his session will stay the same SID. Your server script should run cron task every 5 minutes, checking if SID is still "guest". As soon as user signs in you can use fixated SID to perform any actions on behalf of his account - "Session riding".
I would have thought if mtgox set their cookies to be http only then that would stop this from occurring?
What is the answer?
They should be validating that
Cancel URL
is a valid HTTP absolute URL.i.e. check that it begins with
http://
orhttps://
Anything that does not match should be rejected and an alert flagged to them.
This should stop JavaScript code from being entered as the protocol will be
http
/https
and notjavascript
in the cancel link:Cancel URL
will also have to be correctly HTML encoded to prevent break-out of thehref
attribute value context.Setting HttpOnly cookies would prevent cookies being stolen but if the XSS vulnerability exists it means that other vulnerabilities are likely such as the one described in your scenario. As your cookie is set in JavaScript, this would override the HttpOnly flag because of the more specific path. There is no way for the server to check in the HTTP request that this cookie is HttpOnly (or the path) so this flag won't stop this attack occurring.