[Webkit-unassigned] [Bug 73083] Fix the Frame Leak Attack

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=73083





--- Comment #26 from Thomas Sepez <tsepez at chromium.org>  2012-04-02 10:33:27 PST ---
(In reply to comment #22)
> (From update of attachment 133116 [details])
> View in context: https://bugs.webkit.org/attachment.cgi?id=133116&action=review
> 
> > Source/WebCore/loader/FrameLoader.cpp:2795
> > +        Frame* parent = m_frame->tree()->parent();
> > +        if (parent && !m_frame->document()->securityOrigin()->canAccess(parent->document()->securityOrigin()))
> > +            return;
> 
> What happens if there is a nested iframe?  For example
> A
>  - B
>     - C
> 
> where B and C are the same origin?  Won't scroll operations on C leak information to A even through B and C are the same origin?

We don't care about scroll operations apart from those resulting from navigation to anchors, and the attack is possible in general because A can initiate a navigation on B.  I don't think A can initiate a navigation on C -- that would be the iframe hijacking issue again, no?

> 
> Also, isn't information being leaked from the child to the parent?  In that case, it would seems like we should ask whether the parent can access the child.
> 
Ok, I guess this is not symmetric.  I'll cobble together such a change.

> Does this disable fragment scrolling entirely for iframes embedded in cross-origin pages?  Even if the navigation is initiated by the frame itself?  Is that what Firefox does too?

Yes, Yes, and Yes.

Here's a couple of live examples from the FF bug.

cross-origin iframe which does not navigate:
http://knoxrooms.sirsi.net/rooms/portal/page/21728_Reference

same-origin iframe which does not navigate:
http://firedictionary.com/test/parent.html

The second one should be functional even after our change.

-- 
Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.