| Summary: | Disconnect DOMWindow from Frame on navigation | ||||||
|---|---|---|---|---|---|---|---|
| Product: | WebKit | Reporter: | WebKit Review Bot <webkit.review.bot> | ||||
| Component: | New Bugs | Assignee: | 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
WebKit Review Bot
2011-06-03 14:33:38 PDT
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
|