These are such an incredible opportunity for learning. I've been reading Egor's blog for a while now, and it just gets better and better, and I think the writing is getting much easier to follow as well.
But I do wish someone would start writing a "super-verbose-homakov.blogspot.com". I can see the magic, but I'd love just a bit more hand-holding, and discussion about detecting your own versions of these types of bugs, and proper layers of mitigation.
0) The 'name=...' payload...
- is the 'SID' literal, or is that replaced by a real session id? (see below)
- the https:// url, assume that came from MtGox when creating the payment button?
- 'payment[cancel]=cancel' : assume egor had to figure out to put that there? how did he figure that out? what is happening by putting that there?
1) Setting cancel URL to javascript:eval(name)
- so do you fix this exploit by blacklisting this kind of cancel URL?
- would a blacklist even work reliably?
- can you protect window.name anyhow?
- just like innerText prevents XSS for display strings, is there an equivalent we can use for URLs to know they are inert?
2) Put your payload in window.name and redirect to..
- if I google "window.name xss payload" there are plenty of links
- like this gem from 2008: https://bugzilla.mozilla.org/show_bug.cgi?id=444222
- I can understand this technique could work in an iframe, how does this work across a redirect?
- does it matter how exactly the redirect is triggered?
3) User is supposed to wait 5 seconds..
- I have no idea what this is telling me, is this some MtGox implementation quirk?
- Maybe user is checking out from attacker's site using the payment button and this is a timeout during checkout?
4a) Get some guest SID with server side...
- server side, as in server hosting the page with the checkout button?
- the point here is you need a valid SID to insert into the payload in place of 'SID'?
- assume you have to keep it valid, fixating to an expired session is useless, right?
- if mtgox doesn't allow a session to float between ip/user-agent, it's not perfect (e.g. Wi-fi hotspot, spoof agent of victim) so is it worth storing that data with your session IDs and expiring if it ever doesn't match?
4b) our cookie shadows original SESSION_ID because more specific Path-s are sent first
- "shadows" is a great way to describe this, like that term!
- does fixation always use shadowing? can you fixate with other techniques?
- does shadowing always mean multiple copies of the same cookie are sent?
- should servers be looking for unexpected duplicate cookies sent from the client in each request?
- if the cookie also had a signature (server-side HMAC, secret key), would that definitely prevent shadowing?
5) Close the window.
- Huh?
6a) Someday user logs in
- Logs into what, Gox?
- They have to come from your malicious page, right, for window.name payload to be there?
- So should this say, someday user tries to buy your alpaca socks?
6b) Your server script should run cron task every 5 minutes, checking if SID is still "guest"
- in other words, checking with the fixated SID if mtGox thinks you are logged in?
- also probably updating your window.name payload as session times out and such?
7) Describe how mt.gox fixed it and how you would have fixed it?
Another thought, if the victim was already logged into Gox when they click your checkout button, their cookie is changing to your guest SID, so they get logged out. Probably only 1 in 1000 would even raise an eyebrow though.
Oh, signing doesn't matter because of course attacker is grabbing a perfectly valid and signed cookie from you in the first place.
They don't have to login from your malicious page, your malicious page plants your fake cookie only. The important part is that your browser sends your cookie, instead of the proper one, because it has a more specific path. When the user logs in, they login on your session.
A fix would probably be checking cookies more carefully, ensuring the value and path components are what they should be. You could also assign a new session id when a user logs in, so there is no chance of a polluted session.
But I do wish someone would start writing a "super-verbose-homakov.blogspot.com". I can see the magic, but I'd love just a bit more hand-holding, and discussion about detecting your own versions of these types of bugs, and proper layers of mitigation.
0) The 'name=...' payload...
- is the 'SID' literal, or is that replaced by a real session id? (see below) - the https:// url, assume that came from MtGox when creating the payment button? - 'payment[cancel]=cancel' : assume egor had to figure out to put that there? how did he figure that out? what is happening by putting that there?
1) Setting cancel URL to javascript:eval(name)
- so do you fix this exploit by blacklisting this kind of cancel URL? - would a blacklist even work reliably? - can you protect window.name anyhow? - just like innerText prevents XSS for display strings, is there an equivalent we can use for URLs to know they are inert?
2) Put your payload in window.name and redirect to..
- if I google "window.name xss payload" there are plenty of links - like this gem from 2008: https://bugzilla.mozilla.org/show_bug.cgi?id=444222 - I can understand this technique could work in an iframe, how does this work across a redirect? - does it matter how exactly the redirect is triggered?
3) User is supposed to wait 5 seconds..
- I have no idea what this is telling me, is this some MtGox implementation quirk? - Maybe user is checking out from attacker's site using the payment button and this is a timeout during checkout?
4a) Get some guest SID with server side...
- server side, as in server hosting the page with the checkout button? - the point here is you need a valid SID to insert into the payload in place of 'SID'? - assume you have to keep it valid, fixating to an expired session is useless, right? - if mtgox doesn't allow a session to float between ip/user-agent, it's not perfect (e.g. Wi-fi hotspot, spoof agent of victim) so is it worth storing that data with your session IDs and expiring if it ever doesn't match?
4b) our cookie shadows original SESSION_ID because more specific Path-s are sent first
- "shadows" is a great way to describe this, like that term! - does fixation always use shadowing? can you fixate with other techniques? - does shadowing always mean multiple copies of the same cookie are sent? - should servers be looking for unexpected duplicate cookies sent from the client in each request? - if the cookie also had a signature (server-side HMAC, secret key), would that definitely prevent shadowing?
5) Close the window.
- Huh?
6a) Someday user logs in
- Logs into what, Gox? - They have to come from your malicious page, right, for window.name payload to be there? - So should this say, someday user tries to buy your alpaca socks?
6b) Your server script should run cron task every 5 minutes, checking if SID is still "guest"
- in other words, checking with the fixated SID if mtGox thinks you are logged in? - also probably updating your window.name payload as session times out and such?
7) Describe how mt.gox fixed it and how you would have fixed it?
Another thought, if the victim was already logged into Gox when they click your checkout button, their cookie is changing to your guest SID, so they get logged out. Probably only 1 in 1000 would even raise an eyebrow though.
Oh, signing doesn't matter because of course attacker is grabbing a perfectly valid and signed cookie from you in the first place.