|Summary:||Overly permissive frame navigation allows password theft|
|Product:||WebKit||Reporter:||Adam Barth <abarth>|
|Severity:||Normal||CC:||bdakin, collinj, sam, yuzhu.shen|
|Version:||528+ (Nightly build)|
Description Adam Barth 2007-11-10 16:45:31 PST
WebKit's frame navigation policy is overly permissive, allowing a web attacker to steal passwords from many sites including Google and several banks. WebKit allows any page to navigate subframes of any other page. If a site embeds a password field in an frame, a malicious web site operator can navigate that frame to his site and steal user passwords. The steps below can be used to reproduce the issue: 1) Navigate to http://crypto.stanford.edu/~abarth/research/webkit/adsense.html 2) Click "Open AdSense in a new window." 3) Click "Navigate the AdSense login frame." 4) Notice the password field in the AdSense window has been replaced by content of the attackers choice. The address bar reads "www.google.com" and the lock icon is intact. The frame navigation policy in Firefox 2 was developed in 1999 in response to a similar attack against CitiBank . Their policy is as follows: * Allow the navigation if the source and target frames contained in the same window. * Allow if the source frame can script the target frame or one of its ancestors in the frame hierarchy. Internet Explorer 7 is more strict than Firefox 2. For example, IE7 forbids the navigation from the lower frame in  whereas Firefox 2 permits it. From what we can tell, IE7 is enforcing the following policy: * Allow if the source frame can script the target frame or one of its ancestors in the frame hierarchy. The HTML5 spec  is the most strict. From our reading, it forbids both of the navigations in , whereas all the browsers we've tested allow both. We recommend WebKit implement the same frame navigation policy as Internet Explorer 7: * Allow if the source frame can script the target frame or one of its ancestors in the frame hierarchy. References:  https://bugzilla.mozilla.org/show_bug.cgi?id=13871  http://crypto.stanford.edu/~abarth/research/nav/frame1.html  http://www.whatwg.org/specs/web-apps/current-work/#the-rules  http://xenon.stanford.edu/~abarth/research/nav/frame1.html
Comment 1 Mark Rowe (bdash) 2007-11-10 17:24:39 PST
Comment 2 Sam Weinig 2007-11-26 16:16:29 PST
Fixed in r28056.
Comment 3 Adam Barth 2007-11-27 00:11:59 PST
Thanks for addressing this quickly. According to the comments in your patch, you implemented the following frame navigation policy: The navigation change is safe if the active frame is: - in the same security domain (satisfies same-origin policy) - the opener frame - an ancestor or a descendant in frame tree hierarchy I'm curious why you decided on this policy. It doesn't match Firefox or Internet Explorer 7. For example, the "Navigate middle frame" link at <http://xenon.stanford.edu/~abarth/research/nav/frame1.html> is forbidden by IE7 but allowed by this policy. If we can reach a consensus frame navigation policy among the major browsers, then we can standardize the behavior as part of HTML5 and the web at large will benefit.
Comment 4 Sam Weinig 2007-11-27 09:31:21 PST
I allowed navigating the ancestor frame because when I tested IE I noticed it allowed the parent frame (in another domain) to be navigated. It seems my testing and analysis was too limited and the behavior of IE is actually that only the frame at the top of the hierarchy is allowed to be navigated. Does this match your findings?
Comment 5 Adam Barth 2007-11-27 13:22:18 PST
> the behavior of IE is actually that only the frame at the top of the > hierarchy is allowed to be navigated. Does this match your findings? Yes, that's my current understanding as well. I'll do some more systematic testing of IE7 and report back by the end of the week.
Comment 6 Collin Jackson 2007-11-28 17:26:43 PST
Created attachment 17584 [details] Updates the frame navigation policy to match Internet Explorer 7 (single window) We did some more exhaustive testing of frame navigation in Internet Explorer 7 and wrote a patch to update WebKit to match IE7. Here is a test framework that we created: http://w3sim.com/frames/ Here are the results on IE7: http://w3sim.com/frames/screenshots/ie7-single.png Here are the results on the nightly WebKit: http://w3sim.com/frames/screenshots/webkit-2007-11-27-single.png Here are the results after the attached patch: http://w3sim.com/frames/screenshots/webkit-patched-single.png Our current understanding of the IE7 policy is that a active frame can navigate a target frame (in the same window) if: * The target frame is the top-level frame * The active frame is in the same origin of the target frame or any of its ancestors So far we have only tried navigating frames within a single window. We're going to work on the multi-window case next.
Comment 7 Mark Rowe (bdash) 2007-11-28 21:34:43 PST
Reopening to mark change for review.
Comment 8 Sam Weinig 2007-11-29 10:43:17 PST
Adam/Collin, Have you tested any special handling of the prenamed targets _top and _parent?
Comment 9 Adam Barth 2007-11-29 10:54:46 PST
> Have you tested any special handling of the prenamed targets _top and _parent? Not yet, but that's a good idea. We also learned last night that a frame's opener can change after it is created, which complicates the multi-window tests.
Comment 10 Sam Weinig 2007-11-29 15:56:21 PST
After some testing of the opener frame behavior I have come to the conclusion that a simpler policy may be possible. The policy is: The navigation change is safe if the active frame is: - in the same security origin as the target or one of the target's ancestors Or the target frame is: - a top-level frame frame in the frame hierarchy Thoughts?
Comment 11 Sam Weinig 2007-11-29 17:12:31 PST
Comment on attachment 17584 [details] Updates the frame navigation policy to match Internet Explorer 7 (single window) I have an updated version of this that I will post soon. r- for now
Comment 12 Sam Weinig 2007-11-29 21:21:32 PST
Additional fix landed in r28225. If you think the policy is still incorrect please let me know.
Comment 13 Adam Barth 2007-11-30 11:09:40 PST
r28225 looks good to us, and performs the same as IE7 on our test case.
Comment 14 Yuzhu Shen 2008-01-03 05:06:22 PST
Comment 15 David Kilzer (:ddkilzer) 2008-01-03 09:07:05 PST
(In reply to comment #14) > According to the policy implemented in current WebKit, I've created a scenario > in which various browsers act differently. Please open a new bug for this issue. Thanks!