Lockdown postMessage Parent<-Child #1
Description
While it's possible to scope a postMessage request to a specific iFrame, the parent cannot scope it's listener to the iFrame. It can't even compare the origin of the message to the iFrame because the iframe.contentWindow.location property is blocked. There are three possible solutions: init protocol, window.name, or using channels.
An init setup requires the child sending a request to the parent for a new ID: {type:"init", nonce:"4827e25d7186"}. The parent listens to all postMessages to the domain and (when it receives a request for a new ID) it sends a response to its child with a new ID. Once the child responds, the parent then updates its copy of the child's ID. This leaves the parent wide-open to abuse.
One potential work-around for such abuse is window.name is a seldom-used and pretty quirky property that is copied from the parent's iframe to the child's window property. After the page load, changes by the child or the parent to the .name property does not appear to propagate. The window.name value is consistent across page loads, even when the iFrame navigates to a new origin! We don't even need a handshake, just set the name to a nonce before loading the frame!
Finally, we have channels, which are complicated and would require a new channel for each page load.