New issue
Advanced search Search tips

Issue 770511 link

Starred by 1 user

Issue metadata

Status: Duplicate
Merged: issue 626951
Owner: ----
Closed: Oct 2017
EstimatedDays: ----
NextAction: ----
OS: ----
Pri: ----
Type: Bug-Security



Sign in to add a comment

Open Redirect due to improper Basic Auth implementaiton in URI

Reported by avinlitt...@gmail.com, Sep 30 2017

Issue description

Chrome Version 61.0.3163.91 (Official Build) (64-bit) does not properly implement Basic Authorization details in the URL.

The URI syntax is:
Scheme:[//[user[:password]@]host[:port]][/path][?query][#fragment]

The [user[:password] can be used to login to a website via a URI path, example: https://foo:foopassword@mywebsite.com:80

In a case that a URI is entered such as the one above, the browser typically sends a HEAD request first to see if the website requires Auth, and if it doesn't then the user is warned.

Chrome does not do this for example, https://google.com@attackersite.com will send the user straight to the attacker site. I have attached a picture using https://google.com@yahoo.com, where the user is sent to yahoo. 

Please let me know if you have any questions, Thank you.
 
chrome.png
45.7 KB View Download
This is what Mozilla Firefox ESR does if I try the same URL.

 
firefox.png
97.7 KB View Download
Mergedinto: 626951
Status: Duplicate (was: Unconfirmed)
This isn't a "redirect" of any type; it's the rare "UserInfo" syntax of HTTP URIs. At present, this is working as expected although  Issue 626951  ponders whether this feature should be removed.

https://chromium.googlesource.com/chromium/src/+/master/docs/security/faq.md#Is-Chrome_s-support-for-userinfo-in-HTTP-URLs-e_g_http_user_password_example_com_considered-a-vulnerability
(Correction, it's actually Issue 661005 that proposes a policy switch that would disable the UserInfo syntax)
Cool glad its been mentioned before. I don't think the feature should be removed, instead an HTTP request should be sent to the URL prior checking if Basic Auth is required as some companies may require employees to sign in with the protocol. This is what Mozilla does and if it is indeed an attacker sending a phishing link, the user is warned. However thanks for letting me know and please do let me know what the team's decision is regarding the issue and if I can disclose this on my blog.
Project Member

Comment 5 by sheriffbot@chromium.org, Jan 7 2018

Labels: -Restrict-View-SecurityTeam allpublic
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

Sign in to add a comment