3 ms·
Cross Origin Madness
- lightyrs 14y agoThis is way over my head but seems very problematic.
- homakov 14y agoyes, explanation is a bit short. i can explain if any part is unclear
- eranation 14y agoyes, please, if you could explain for non security experts what we can do to protect our pages from this vulnerability, and also please clarify if it's relevant to web pages that don't use frames / iframes (I guess some of us just shrug and say, "hm.. clever post, I wish I had the time to dive into this, but I don't plan to try to use this to attack other sites, and it's probably not relevant for me since I don't have any frames" so a simplified clarification will be highly appreciated)
- homakov 14y ago1) SAMEORIGIN/DENY is good protection, as said above 2) If you don't interact with frames(window.length==1) and don't have Like buttons - you are not vulnerable
- KwanEsq 14y agoUnless I'm misunderstanding scenario is this: 1) Fancy app website uses iframes to send messages to itself/its server 2) attack website embeds app in an iframe 3) attack website changes the URLs of the apps iframes to point to attacker-controlled pages 4) app sends sensitive info to its iframes, which of course ends up going to the attacker
- homakov 14y agoyes, thats right
- deleted 14y ago[deleted]
- homakov 14y agounrelated. I create iframe with victim website and i don't set sandbox attribute. And, obviously, victim cannot set sandbox for itself
- moonboots 14y agoSorry, I misinterpreted your attack, and it's more worrying than I initially thought. I would add some information about the fix, namely adding the header "X-Frame-Options: SAMEORIGIN" [1]. [1] https://developer.mozilla.org/en-US/docs/HTTP/X-Frame-Options https://developer.mozilla.org/en-US/docs/HTTP/X-Frame-Option...
- homakov 14y agoyes SAMEORIGIN/DENY is perfect solution. but, damn it, insecure-by-default and any site is frameable by default so far.
- ricardobeat 14y agoI can't see how any of those 'vectors' lead to real-world exploits. 1) You can submit a form, ok, but where does CSRF comes in if you can't manipulate or send any data? 2) possible phishing target, but it still doesn't have access to the parent, and you have to be already visiting an iframed website (wrong URL displayed), and it has be using iframes to send sensitive data. 3) window.name was never safe. 4) postMessage without an origin check is not safe either, period.
- homakov 14y ago> lead to real-world exploits not looking for real world exploits for free anymore 1) can be exploit for some flash callback things, isciurus will publish PoC later 2) yes 3) why it wasn't? i mean yes it's shitty but how it was broken? 4) I agree, but I demonstrated that even if you trust iframe you must specify receiver origin, just to be sure
- mmahemoff 14y agowindow.name was never safe because it was shared by all domains. (You could use it for cross-origin communicate, in a very lame way.)
- homakov 14y agoshared by all origin1 domains. I'm origin2 and now i can also read it. this is the hack :)
- ricardobeat 14y agowindow.name can be read by any domain, that's why it was used for cross-domain messaging before postMessage came along.
- deleted 14y ago[deleted]