469939 - it is possible to trick a user to give away access credentials by forcing a foreign tab/window to redirect to a malicious site after a successful authentication

Status: RESOLVED WONTFIX

(Firefox :: Security, defect)

Description

[Petko D. (pdp) Petkov]

User-Agent:       Mozilla/5.0 (X11; U; Linux x86_64; en-GB; rv:1.9.0.4) Gecko/2008111318 Ubuntu/8.04 (hardy) Firefox/3.0.4
Build Identifier: Mozilla/5.0 (X11; U; Linux x86_64; en-GB; rv:1.9.0.4) Gecko/2008111318 Ubuntu/8.04 (hardy) Firefox/3.0.4

Here is a simple example:

var w = window.open('url1');
setTimeout(function () {
  w.location = 'http://url2';
}, 5000);

Although this code does not look too malicious, consider the following situation: The user clicks on a link which spawns a new tab (mimicking target="_blank"). The new tab presents the user with a login form. Since this is the legitimate site, the SSL information will be correct and therefore the user will most likely type their credentials in. In the background, the page which opened the tab waits until it detects that the user has logged on successfully. There are several techniques to do that. The check is performed as often as required. Once a true condition is reached, a w.location = 'http://evil stealing website' is fired which will force the newly authenticated/trusted tab to redirect to another site which is controlled by the attacker. This site contains similarly looking login page but with some error messages which inform the user that the authenticate was not successful. The user will most likely fill their access credentials one more time. The credentials will travel back to the attacker's controlled site where they will be recorded. The attacker can than redirect the user to the original site with a simple 302 redirect.

The bad thing about this attack is that it feels like the typical authentication process many sites currently offer and therefore a lot of users will be fooled to give away their credentials with realizing what actually happens.

The solution is very simple although I am not sure if it will break some parts of the Web. We should simply disallow parent windows to control the location parameter unless they are from the same origin.

Reproducible: Always

Steps to Reproduce:
1.
2.
3.

Comment 1

[Jesse Ruderman]

A TOCTOU attack against humans!  Clever use of psychology and misdirection to minimize the chance the user will notice the URL change.

> The solution is very simple although I am not sure if it will break some
> parts of the Web. We should simply disallow parent windows to control the
> location parameter unless they are from the same origin.

Not sure how feasible this fix is.  Maybe Giorgio can help us find out ;)

To fix this completely, we would probably have to disallow window.close() across domains too, breaking additional sites :(  Otherwise, the attacker could close the legitimate site's tab, exposing a tab containing the fake login-failed form.

For now, users can protect themselves by opening a new tab manually before navigating to bank/email sites.  It would be nice if we could at least say the same about loading a bookmark in an existing window.  Severing "opener" control upon loading a bookmark shouldn't break much, and would give users a more natural way to avoid this attack until we can fix it for real.

Comment 2

[Giorgio Maone [:ma1]]

I'm afraid it's worse than that. 
Even if we forbid location write access, the attacker could simply work around with

open("https://protected.com", "victimTarget");
setTimeout(function() { open("http://phishy.net", "victimTarget") })

Maybe we should mark any window as an invalid target for external cross-site requests as soon as it loads a HTTPS resource, but it doesn't seem a very simple thing to do :(

Comment 3

[Jesse Ruderman]

Maybe we need to revisit the "opener restriction" described by http://crypto.stanford.edu/websec/frames/navigation/.

Comment 4

[Adam Barth]

Regarding Comment 2: Opera has a different frame navigation policy for HTTPS pages than for HTTP pages, but I don't think we should introduce these kinds of compat differences between HTTP and HTTPS.

One option is to treat "tab-size" windows different than "popup-size" windows.  We could let a popup window be navigated by its opener but block navigation of tabs.

TestPilot would be a big help in evaluating the compatibility of these proposals.

Comment 5

[:Gavin Sharp [email: [e-mail]]]

The core issue here is that baseline web capabilities (opening/closing windows, navigating windows, etc.) can lead to user confusion. We could investigate ways to mitigate these problems, but we're not going to be able to invest a lot of time doing that given the relatively low risk and low occurrence of this happening in the wild. That may change in the future, but this bug is not serving a useful purpose in the mean time.