Bug 62054 - Disconnect DOMWindow from Frame on navigation
: Disconnect DOMWindow from Frame on navigation
Status: RESOLVED DUPLICATE of bug 69949
Product: WebKit
Classification: Unclassified
Component: New Bugs
: 528+ (Nightly build)
: Unspecified Unspecified
: P2 Normal
Assigned To: Adam Barth
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2011-06-03 14:33 PDT by WebKit Review Bot
Modified: 2011-10-12 12:15 PDT (History)
4 users (show)

See Also:


Attachments
Hacks, lies, and work-in-progress (4.95 KB, patch)
2011-06-06 11:46 PDT, Adam Barth
no flags Details | Formatted Diff | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description WebKit Review Bot 2011-06-03 14:33:38 PDT
Disconnect DOMWindow from Frame on navigation
Requested by abarth on #webkit.
Comment 1 Adam Barth 2011-06-04 23:41:03 PDT
I looked at this a bit.  It's somewhat subtle.
Comment 2 Sam Weinig 2011-06-05 17:23:03 PDT
Adam, can you explain more about this, for instance the motivation and observable effects.
Comment 3 Adam Barth 2011-06-05 17:27:24 PDT
> 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.
Comment 4 Sam Weinig 2011-06-05 17:30:21 PDT
(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)?
Comment 5 Adam Barth 2011-06-05 17:54:13 PDT
> 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.
Comment 6 Sam Weinig 2011-06-05 20:29:50 PDT
(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.
Comment 7 Adam Barth 2011-06-06 11:46:04 PDT
Created attachment 96104 [details]
Hacks, lies, and work-in-progress
Comment 8 Adam Barth 2011-10-12 12:15:51 PDT

*** This bug has been marked as a duplicate of bug 69949 ***