Bug 15936 – Overly permissive frame navigation allows password theft

• Component: Frames
• Status: RESOLVED FIXED

[Adam Barth]

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

[Mark Rowe (bdash)]

<rdar://problem/5592988>

[Sam Weinig]

Fixed in r28056.

[Adam Barth]

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.

[Sam Weinig]

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?

[Adam Barth]

> 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.

[Collin Jackson]

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.

[Mark Rowe (bdash)]

Reopening to mark change for review.

[Sam Weinig]

Adam/Collin,
Have you tested any special handling of the prenamed targets _top and _parent?

[Adam Barth]

> 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.

[Sam Weinig]

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?

[Sam Weinig]

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

[Sam Weinig]

Additional fix landed in r28225.  If you think the policy is still incorrect please let me know.

[Adam Barth]

r28225 looks good to us, and performs the same as IE7 on our test case.

[Yuzhu Shen]

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.)

[David Kilzer (:ddkilzer)]

(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!

[Yuzhu Shen]

bug 16727 has been created to track this problem.