Bug 62054

Summary: Disconnect DOMWindow from Frame on navigation
Product: WebKit Reporter: WebKit Review Bot <webkit.review.bot>
Component: New BugsAssignee: Adam Barth <abarth>
Status: RESOLVED DUPLICATE    
Severity: Normal CC: abarth, ap, deshnawysameh, eric, sam
Priority: P2    
Version: 528+ (Nightly build)   
Hardware: Unspecified   
OS: Unspecified   
Attachments:
Description Flags
Hacks, lies, and work-in-progress none

WebKit Review Bot
Reported 2011-06-03 14:33:38 PDT
Disconnect DOMWindow from Frame on navigation Requested by abarth on #webkit.
Attachments
Hacks, lies, and work-in-progress (4.95 KB, patch)
2011-06-06 11:46 PDT, Adam Barth 		no flags
DetailsFormatted DiffDiff
View All Add attachment proposed patch, testcase, etc.
Adam Barth
Comment 1 2011-06-04 23:41:03 PDT
I looked at this a bit. It's somewhat subtle.
Sam Weinig
Comment 2 2011-06-05 17:23:03 PDT
Adam, can you explain more about this, for instance the motivation and observable effects.
Adam Barth
Comment 3 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.
Sam Weinig
Comment 4 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)?
Adam Barth
Comment 5 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.
Sam Weinig
Comment 6 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.
Adam Barth
Comment 7 2011-06-06 11:46:04 PDT
Created attachment 96104 [details] Hacks, lies, and work-in-progress
Adam Barth
Comment 8 2011-10-12 12:15:51 PDT
*** This bug has been marked as a duplicate of bug 69949 ***
Note You need to log in before you can comment on or make changes to this bug.