

Cross Origin Madness - homakov
http://homakov.blogspot.com/2013/02/cross-origin-madness-or-your-frames-are.html

======
ricardobeat
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.

~~~
homakov
> 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
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.)

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

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

------
lightyrs
This is way over my head but seems very problematic.

~~~
KwanEsq
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

~~~
homakov
yes, thats right

