15936 2007-11-10 16:45:31 -0800 Overly permissive frame navigation allows password theft 2008-01-03 22:28:05 -0800 1 1 1 Unclassified WebKit Frames 528+ (Nightly build) All All RESOLVED FIXED http://crypto.stanford.edu/~abarth/research/webkit/adsense.html InRadar P2 Normal --- 0 abarth webkit-unassigned bdakin collinj sam yuzhu.shen oldest_to_newest 60864 0 abarth 2007-11-10 16:45:31 -0800 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 [1]. 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 [2] 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 [3] is the most strict. From our reading, it forbids both of the navigations in [4], 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: [1] https://bugzilla.mozilla.org/show_bug.cgi?id=13871 [2] http://crypto.stanford.edu/~abarth/research/nav/frame1.html [3] http://www.whatwg.org/specs/web-apps/current-work/#the-rules [4] http://xenon.stanford.edu/~abarth/research/nav/frame1.html 60868 1 mrowe 2007-11-10 17:24:39 -0800 <rdar://problem/5592988> 62406 2 sam 2007-11-26 16:16:29 -0800 Fixed in r28056. 62434 3 abarth 2007-11-27 00:11:59 -0800 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. 62474 4 sam 2007-11-27 09:31:21 -0800 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? 62508 5 abarth 2007-11-27 13:22:18 -0800 > 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. 62620 6 17584 collinj 2007-11-28 17:26:43 -0800 Created attachment 17584 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. 62636 7 mrowe 2007-11-28 21:34:43 -0800 Reopening to mark change for review. 62705 8 sam 2007-11-29 10:43:17 -0800 Adam/Collin, Have you tested any special handling of the prenamed targets _top and _parent? 62706 9 abarth 2007-11-29 10:54:46 -0800 > 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. 62728 10 sam 2007-11-29 15:56:21 -0800 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? 62735 11 17584 sam 2007-11-29 17:12:31 -0800 Comment on attachment 17584 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 62757 12 sam 2007-11-29 21:21:32 -0800 Additional fix landed in r28225. If you think the policy is still incorrect please let me know. 62801 13 abarth 2007-11-30 11:09:40 -0800 r28225 looks good to us, and performs the same as IE7 on our test case. 66123 14 yuzhu.shen 2008-01-03 05:06:22 -0800 According to the policy implemented in current WebKit, I've created a scenario in which various browsers act differently. Assume that the following files are located at http://aaa.bbb.com/ Note: If you want to try out this example, change the value of document.domain accordingly in these files! It should be a suffix of the real domain in which these files reside. ==================================== <!-- navigation.htm --> <html> <head> <title></title> <script language="javascript">document.domain='bbb.com';</script> </head> <frameset name="main" cols="503,*"> <frame name="left" src="left.htm" /> <frame name="right" src="right.htm" /> </frameset> </html> ================================ <!-- left.htm --> <html> <head> <title></title> <base target='right'> </head> <body> <a href='helloWorld.htm'>HelloWorld</a> </body> </html> ================================= <!-- right.htm --> <html> <head> <title></title> </head> <body> <script language="javascript">document.domain='bbb.com';</script> </body> </html> ================================= <!-- helloWorld.htm --> <html> <body> <h1>Hello World!</h1> </body> </html> ================================= If you click the "HelloWorld" link: IE7: will open the link in a new tab instead of the target frame. IE6, Firefox2/3, Safari 3.0.3: will open the link in the target frame. Current WebKit: will do nothing. This problem affects a popular forum in China: http://dzh.mop.com In this forum, if you click a link in the left panel, current WebKit will not open the link. (Due to some other reasons, IE7 works fine with this site.) 66131 15 ddkilzer 2008-01-03 09:07:05 -0800 (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! 66174 16 yuzhu.shen 2008-01-03 22:28:05 -0800 bug 16727 has been created to track this problem. 17584 2007-11-28 17:26:43 -0800 2007-11-29 17:12:31 -0800 Updates the frame navigation policy to match Internet Explorer 7 (single window) navigation.patch text/plain 2703 collinj SW5kZXg6IFdlYkNvcmUvbG9hZGVyL0ZyYW1lTG9hZGVyLmNwcAo9PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09Ci0tLSBXZWJD b3JlL2xvYWRlci9GcmFtZUxvYWRlci5jcHAJKHJldmlzaW9uIDI4MTEyKQorKysgV2ViQ29yZS9s b2FkZXIvRnJhbWVMb2FkZXIuY3BwCSh3b3JraW5nIGNvcHkpCkBAIC0yMzE5LDMwICsyMzE5LDM4 IEBACiAgICAgICAgIHJldHVybiB0cnVlOwogCiAgICAgLy8gVGhlIG5hdmlnYXRpb24gY2hhbmdl IGlzIHNhZmUgaWYgdGhlIGFjdGl2ZSBmcmFtZSBpczoKLSAgICAvLyAgIC0gaW4gdGhlIHNhbWUg c2VjdXJpdHkgZG9tYWluIChzYXRpc2ZpZXMgc2FtZS1vcmlnaW4gcG9saWN5KQogICAgIC8vICAg LSB0aGUgb3BlbmVyIGZyYW1lCi0gICAgLy8gICAtIGFuIGFuY2VzdG9yIG9yIGEgZGVzY2VuZGFu dCBpbiBmcmFtZSB0cmVlIGhpZXJhcmNoeQorICAgIC8vICAgLSBhIGRlc2NlbmRhbnQgKGluIHRo ZSB0cmVlIGhpZXJhcmNoeSkgb2YgYSB0b3AtbGV2ZWwgdGFyZ2V0IGZyYW1lCisgICAgLy8gICAt IGluIHRoZSBzYW1lIHNlY3VyaXR5IG9yaWdpbiBhcyBvbmUgb2YgdGhlIHRhcmdldCdzIGFuY2Vz dG9ycwogCi0gICAgLy8gU2FtZSBzZWN1cml0eSBkb21haW4gY2FzZS4KLSAgICBEb2N1bWVudCog YWN0aXZlRG9jdW1lbnQgPSBtX2ZyYW1lLT5kb2N1bWVudCgpOwotICAgIEFTU0VSVChhY3RpdmVE b2N1bWVudCk7Ci0gICAgRG9jdW1lbnQqIHRhcmdldERvY3VtZW50ID0gdGFyZ2V0RnJhbWUtPmRv Y3VtZW50KCk7Ci0gICAgaWYgKCF0YXJnZXREb2N1bWVudCkKLSAgICAgICAgcmV0dXJuIHRydWU7 Ci0gICAgY29uc3QgU2VjdXJpdHlPcmlnaW4mIGFjdGl2ZVNlY3VyaXR5T3JpZ2luID0gYWN0aXZl RG9jdW1lbnQtPnNlY3VyaXR5T3JpZ2luKCk7Ci0gICAgY29uc3QgU2VjdXJpdHlPcmlnaW4mIHRh cmdldFNlY3VyaXR5T3JpZ2luID0gdGFyZ2V0RG9jdW1lbnQtPnNlY3VyaXR5T3JpZ2luKCk7Ci0g ICAgaWYgKGFjdGl2ZVNlY3VyaXR5T3JpZ2luLmNhbkFjY2Vzcyh0YXJnZXRTZWN1cml0eU9yaWdp bikpCi0gICAgICAgIHJldHVybiB0cnVlOwotCiAgICAgLy8gT3BlbmVyIGNhc2UuCiAgICAgaWYg KG1fZnJhbWUgPT0gdGFyZ2V0RnJhbWUtPmxvYWRlcigpLT5vcGVuZXIoKSkKICAgICAgICAgcmV0 dXJuIHRydWU7CiAKLSAgICAvLyBBbmNlc3RvciBvciBkZXNjZW5kYW50IGNhc2UuCi0gICAgaWYg KHRhcmdldEZyYW1lLT50cmVlKCktPmlzRGVzY2VuZGFudE9mKG1fZnJhbWUpIHx8IG1fZnJhbWUt PnRyZWUoKS0+aXNEZXNjZW5kYW50T2YodGFyZ2V0RnJhbWUpKQorICAgIC8vIEEgZnJhbWUgY2Fu IG5hdmlnYXRlIGl0cyB0b3AtbGV2ZWwgZnJhbWUuCisgICAgaWYgKCF0YXJnZXRGcmFtZS0+dHJl ZSgpLT5wYXJlbnQoKSAmJiBtX2ZyYW1lLT50cmVlKCktPmlzRGVzY2VuZGFudE9mKHRhcmdldEZy YW1lKSkKICAgICAgICAgcmV0dXJuIHRydWU7CiAKKyAgICBEb2N1bWVudCogYWN0aXZlRG9jdW1l bnQgPSBtX2ZyYW1lLT5kb2N1bWVudCgpOworICAgIEFTU0VSVChhY3RpdmVEb2N1bWVudCk7Cisg ICAgY29uc3QgU2VjdXJpdHlPcmlnaW4mIGFjdGl2ZVNlY3VyaXR5T3JpZ2luID0gYWN0aXZlRG9j dW1lbnQtPnNlY3VyaXR5T3JpZ2luKCk7CisKKyAgICAvLyBDaGVjayBpZiB0YXJnZXQgaGFzIGFu IGFuY2VzdG9yIGluIHRoZSBzYW1lIHNlY3VyaXR5IG9yaWdpbi4KKyAgICBGcmFtZSogYW5jZXN0 b3JGcmFtZSA9IHRhcmdldEZyYW1lOworICAgIHdoaWxlIChhbmNlc3RvckZyYW1lKSB7CisgICAg ICAgIERvY3VtZW50KiBhbmNlc3RvckRvY3VtZW50ID0gYW5jZXN0b3JGcmFtZS0+ZG9jdW1lbnQo KTsKKyAgICAgICAgaWYgKCFhbmNlc3RvckRvY3VtZW50KQorICAgICAgICAgICAgcmV0dXJuIHRy dWU7CisKKyAgICAgICAgY29uc3QgU2VjdXJpdHlPcmlnaW4mIGFuY2VzdG9yU2VjdXJpdHlPcmln aW4gPSBhbmNlc3RvckRvY3VtZW50LT5zZWN1cml0eU9yaWdpbigpOworICAgICAgICBpZiAoYWN0 aXZlU2VjdXJpdHlPcmlnaW4uY2FuQWNjZXNzKGFuY2VzdG9yU2VjdXJpdHlPcmlnaW4pKQorICAg ICAgICAgICAgcmV0dXJuIHRydWU7CisKKyAgICAgICAgYW5jZXN0b3JGcmFtZSA9IGFuY2VzdG9y RnJhbWUtPnRyZWUoKS0+cGFyZW50KCk7CisgICAgfQorCiAgICAgaWYgKCF0YXJnZXRGcmFtZS0+ c2V0dGluZ3MoKS0+cHJpdmF0ZUJyb3dzaW5nRW5hYmxlZCgpKSB7CisgICAgICAgIERvY3VtZW50 KiB0YXJnZXREb2N1bWVudCA9IHRhcmdldEZyYW1lLT5kb2N1bWVudCgpOwogICAgICAgICAvLyBG SVhNRTogdGhpcyBlcnJvciBtZXNzYWdlIHNob3VsZCBjb250YWluIG1vcmUgc3BlY2lmaWNzIG9m IHdoeSB0aGUgbmF2aWdhdGlvbiBjaGFuZ2UgaXMgbm90IGFsbG93ZWQuCiAgICAgICAgIFN0cmlu ZyBtZXNzYWdlID0gU3RyaW5nOjpmb3JtYXQoIlVuc2FmZSBKYXZhU2NyaXB0IGF0dGVtcHQgdG8g aW5pdGlhdGUgYSBuYXZpZ2F0aW9uIGNoYW5nZSBmb3IgZnJhbWUgd2l0aCBVUkwgJXMgZnJvbSBm cmFtZSB3aXRoIFVSTCAlcy5cbiIsCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgdGFyZ2V0RG9jdW1lbnQtPlVSTCgpLnV0ZjgoKS5kYXRhKCksIGFjdGl2ZURvY3VtZW50 LT5VUkwoKS51dGY4KCkuZGF0YSgpKTsK