Bug 62054 - Disconnect DOMWindow from Frame on navigation
: Disconnect DOMWindow from Frame on navigation
Status: RESOLVED DUPLICATE of bug 69949
: WebKit
New Bugs
: 528+ (Nightly build)
: Unspecified Unspecified
: P2 Normal
Assigned To:
:
:
:
:
  Show dependency treegraph
 
Reported: 2011-06-03 14:33 PST by
Modified: 2011-10-12 12:15 PST (History)


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


Note

You need to log in before you can comment on or make changes to this bug.


Description From 2011-06-03 14:33:38 PST
Disconnect DOMWindow from Frame on navigation
Requested by abarth on #webkit.
------- Comment #1 From 2011-06-04 23:41:03 PST -------
I looked at this a bit.  It's somewhat subtle.
------- Comment #2 From 2011-06-05 17:23:03 PST -------
Adam, can you explain more about this, for instance the motivation and observable effects.
------- Comment #3 From 2011-06-05 17:27:24 PST -------
> 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 From 2011-06-05 17:30:21 PST -------
(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 From 2011-06-05 17:54:13 PST -------
> 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 From 2011-06-05 20:29:50 PST -------
(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 From 2011-06-06 11:46:04 PST -------
Created an attachment (id=96104) [details]
Hacks, lies, and work-in-progress
------- Comment #8 From 2011-10-12 12:15:51 PST -------

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