New issue
Advanced search Search tips
Note: Color blocks (like █ or █) mean that a user may not be available. Tooltip shows the reason.

Issue 605452 link

Starred by 1 user
Status: Duplicate
Merged: issue 599198
Owner: ----
Closed: Apr 2016
Cc:
palmer@chromium.org
█ brettw@chromium.org
Components:
EstimatedDays: ----
NextAction: ----
OS: Mac
Pri: 2
Type: Bug-Security



Sign in to add a comment

Inconsistent parsing of URL leading to open redirect issues

Reported by christ...@peakon.com, Apr 21 2016 
UserAgent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_11_4) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/49.0.2623.112 Safari/537.36

Steps to reproduce the problem:
Handling of a URL of the form "http://attacker.com\@google.com" is handled differently in the browser navigation bar and the URL parsing in Javascript. This lead to an unchecked open redirect in our web application.

Steps to reproduce:
If you enter "http://attacker.com\@google.com" in the navigation bar of Chrome 49 Stable, you will end up on attacker.com.

If you parse the URL using JS in various ways, the hostname will however be reported as google.com. This can lead to open redirects to fail.

new URL('http://attacker.com\@google.com')
URL {
  protocol: 'http:',
  slashes: true,
  hash: '',
  query: '',
  pathname: '',
  auth: 'attacker.com',
  host: 'google.com',
  port: '',
  hostname: 'google.com',
  password: '',
  username: 'attacker.com',
  href: 'http://attacker.com@google.com'
}

a = document.createElement('a');
a.href = 'http://attacker.com\@google.com';
'protocol,hash,auth,host,hostname,username,href'.split(',').forEach(function(prop) { 
  console.log(prop +':', a[prop]); 
});

// protocol: http:
// hash: 
// auth: undefined
// host: google.com
// hostname: google.com
// username: attacker.com
// href: http://attacker.com@google.com/

The later parsing is consistent with f.ex. Python:

>>> from urlparse import urlparse
>>> o = urlparse('http://attacker.com\@google.com')
>>> o.hostname
'google.com'
>>> o.username
'attacker.com\\'

What is the expected behavior?
To be quite frank I am not sure which of the parses are correct, as I am not well-versed in the spec. However the expected behaviour would be for the methods to be consistent.

What went wrong?
We had a check to see if a redirect query parameter matched the hostname of our app. We used the above parsing, and determined it matched, but in reality Chrome redirected to the attacker domain. This can be used for f.ex. phishing attacks.

Did this work before? N/A 

Chrome version: 49.0.2623.112  Channel: stable
OS Version: OS X 10.11.4
Flash Version: Shockwave Flash 21.0 r0

Comment 1 by vakh@chromium.org, Apr 21 2016

Components: UI>Browser>Navigation
Labels: -Restrict-View-SecurityTeam
Status: WontFix (was: Unconfirmed)
Thanks for reporting this issue.

Not sure what your exact use case was, but what matters is the final page that the user lands on and what origin they see when they get there.

In this case, the user finally lands on attacker[.]com and Chrome makes that very clear to the user.

Comment 2 by christ...@peakon.com, Apr 21 2016 

The use case is a check of a redirectTo query parameter after authentication. If an unauthenticated user visits a page requiring authentication, we redirect to the login page, setting a query parameter to hold the page to redirect the user to after authentication. 

When the authentication is done, we parse the query parameter and check that the host is ours. If it is ours, we redirect to the url, otherwise we discard it.

Now with this inconsistency between the parsing of the URL in JS and the parsing of the url in the navbar (and location.href = ...), the check succeeds, but we end up redirecting to another host.

I think this is a quite common way to validate redirects, as per https://www.owasp.org/index.php/Open_redirect.

Comment 3 by christ...@peakon.com, Apr 21 2016 

I should have clarified in the original description that the issue is really that location.href = 'http://attacker.com\@google.com' sends to attacker.com, while new URL('http://attacker.com\@google.com') parses the URL to having google.com as host.

This inconsistency leads to an open redirect as described in the previous comment.

Comment 4 by creis@chromium.org, Apr 21 2016

Cc: palmer@chromium.org brettw@chromium.org
Mergedinto: 599198
Status: Duplicate (was: WontFix)
We've seen this in  issue 599198  as well, where it was also marked WontFix.

Comment 5 by christ...@peakon.com, Apr 21 2016 

I don't have access to read the justification given in  issue 599198 . However I can't see how we can reasonably protect against open redirects and phishing attacks, if we cannot trust Chromium to navigate to the correct host. 

There are ways to work around this naturally, but I would be very surprised if many other sites were not impacted by this same problem.

In any case you made it clear you do not intend to fix this, even if I would have hoped for a bit more justification.

Comment 6 by creis@chromium.org, Apr 21 2016 

Lifted view restrictions on  issue 599198 , if that helps.
Project Member

Comment 7 by sheriffbot@chromium.org, Oct 1 2016 

This bug has been closed for more than 14 weeks. Removing security view restrictions.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
Project Member

Comment 8 by sheriffbot@chromium.org, Oct 2 2016 

This bug has been closed for more than 14 weeks. Removing security view restrictions.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

Comment 9 by mbarbe...@chromium.org, Oct 2 2016

Labels: allpublic
►

Sign in to add a comment