Nerd-puzzle: how might I allow sibling same-origin iframes to communicate, given…
- parent is cross-origin
- can’t execute JS on parent
- no sessionStorage, localStorage, cookies, or IDB access
- with enough security to share auth tokens?
Conversation
The best I can come up with is to have each iframe open a WebSocket to a server which can coordinate, but I don’t see how to guard again an attacker posing as a sibling iframe and receiving secure data.
Replying to
A concrete instantiation of the problem: imagine a page has three YouTube embeds and these security constraints. The user signs into YouTube via UI in one embed. You’d like the other embeds to also become signed in.
2
This question brought to you by: why do Chrome and Firefox disable access to *session* storage when third-party cookies are disabled? It’s not even persistent! What’s the threat model? Bluh.
2
4
Kevin wins! 👏 This approach works in both Chrome and Firefox with third-party cookies blocked.
Safari doesn’t implement BroadcastChannel, but it *does* allow session storage, so I can communicate that way in Safari.
Quote Tweet
Replying to @andy_matuschak
Would BroadcastChannel work?
2
12
This Github issue implies that the Powers are thinking about removing access to BroadcastChannel in this context, unfortunately. Hm hm…
1
4
Replying to
You can use webrtc p2p, check peerjs.com - the sever doesn’t relay anything, you can define a secret by using a common property in the iFrame to help the peers.
2
1
1
Nice approach! Alas, defining a secret via a common property is very not ideal—it would be like asking YouTube users to add a custom parameter every time they embed, rather than just copying-and-pasting—but it’s better than nothing!
Replying to
Best I can think of... make the login process a popup-based OAuth flow. Upon successful login, use the WebSocket trick to make all the frames _look_ logged in, but don't display any PII — just public profile information. This can be attacked, but it doesn't matter.
1
When another iframe wants to perform an authenticated action, it also does a one-time OAuth popup which closes immediately and passes the access token back to the iframe. Terrible UX on a mobile browser but I think it would work.
Replying to
Sounds like you found a better solution, but I believe you can enable CORS / enforce origin on WebSockets?
1
Hm, I don’t think that’s good enough: I could build a hostile client which spoofed the origin.
1