Cross Origin Madness | Hacker News Reader

Cross Origin Madness

homakov.blogspot.com

54 pointshomakov15 comments

I 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.

> 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

window.name was never safe because it was shared by all domains. (You could use it for cross-origin communicate, in a very lame way.)

shared by all origin1 domains. I'm origin2 and now i can also read it. this is the hack :)

window.name can be read by any domain, that's why it was used for cross-domain messaging before postMessage came along.

Deleted comment

unrelated. I create iframe with victim website and i don't set sandbox attribute.

And, obviously, victim cannot set sandbox for itself

Sorry, 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-Option...

yes SAMEORIGIN/DENY is perfect solution. but, damn it, insecure-by-default and any site is frameable by default so far.

This is way over my head but seems very problematic.

Unless 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

yes, thats right

yes, explanation is a bit short. i can explain if any part is unclear

yes, 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)

1) 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

Reply on news.ycombinator.com