Disconnect DOMWindow from Frame on navigation Requested by abarth on #webkit.
I looked at this a bit. It's somewhat subtle.
Adam, can you explain more about this, for instance the motivation and observable effects.
> Adam, can you explain more about this, for instance the motivation and observable effects. The effects shouldn't be observable. It's a mitigation for UXSS vulnerabilities. Today the DOMWindow keeps a pointer to the Frame after navigation, which means folks can get confused when they're doing security checks related to DOMWindow because they might check domWindow->securityOrigin() or domWindow->document() and then operate on domWindow->frame(). In that scenario, they'll operate on a document whose security origin they haven't checked. We've seen at least on example of this recently.
(In reply to comment #3) > > Adam, can you explain more about this, for instance the motivation and observable effects. > > The effects shouldn't be observable. It's a mitigation for UXSS vulnerabilities. Today the DOMWindow keeps a pointer to the Frame after navigation, which means folks can get confused when they're doing security checks related to DOMWindow because they might check domWindow->securityOrigin() or domWindow->document() and then operate on domWindow->frame(). In that scenario, they'll operate on a document whose security origin they haven't checked. We've seen at least on example of this recently. I see. What would the plan for reconnecting it be (for the case of the back/forward cache I guess)?
> I see. What would the plan for reconnecting it be (for the case of the back/forward cache I guess)? I haven't studied that aspect of the problem yet, but it's just a pointer. We can set it to be non-null again.
(In reply to comment #5) > > I see. What would the plan for reconnecting it be (for the case of the back/forward cache I guess)? > > I haven't studied that aspect of the problem yet, but it's just a pointer. We can set it to be non-null again. Such witchcraft would never be permitted.
Created attachment 96104 [details] Hacks, lies, and work-in-progress
*** This bug has been marked as a duplicate of bug 69949 ***