New issue
Advanced search Search tips

Issue 661005 link

Starred by 1 user

Issue metadata

Status: Assigned
Owner:
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Linux
Pri: 2
Type: Feature



Sign in to add a comment

Please provide policy setting to disable Basic Auth URL encoding

Reported by josephpk...@gmail.com, Nov 1 2016

Issue description

UserAgent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/54.0.2840.71 Safari/537.36

Steps to reproduce the problem:
1. navigate to https://www.google.com:443+q=elon@tesla.com
2. the resulting page should be https://www.tesla.com

What is the expected behavior?
Warn the user that they are about to post credentials
      - username : "www.google.com"
      - password : "443+q=elon"

to the site www.tesla.com

With the option to block, or do-not-show this warning in future (if in the odd case it is legitimate)

I would also expect some policy option to control the warning or blocking for this
https://www.chromium.org/administrators/policy-list-3

What went wrong?
In Firefox and Safari by default they warn that you are about to post credentials to the site using HTTP Basic Auth. I would have expected chrome/chromium to do the same. 

I searched all options in the policy settings list, including trying this in my policy.json

{
      "AuthSchemes" : "digest,ntlm,negotiate"
}

it did not warn or restrict URL encoded basic auth.

Did this work before? N/A 

Chrome version: 54.0.2840.71  Channel: dev
OS Version: ARCH 4.8.4-1
Flash Version: (Disabled)

https://en.wikipedia.org/wiki/Basic_access_authentication#URL_encoding
 

Comment 1 by ta...@google.com, Nov 1 2016

Components: UI>Browser>Navigation
Labels: Team-Security-UX
Owner: mea...@chromium.org
Status: Assigned (was: Unconfirmed)
meacer@, is this something you can decide whether or not we should fix? Thanks.
I don't think this issue needs to be view restricted.

Similar to https://bugs.chromium.org/p/chromium/issues/detail?id=626951, but this variant is "Basic authentication is unsafe over clear channels". That's true whether the credentials are in the userinfo component of the URL or in response to a basic authentication prompt. 

Offering a Policy mechanism to block support of BASIC auth (either entirely or only via non-secure channels) seems like a reasonable feature request. Today we only provide a subtle warning in the credential prompt.

Compare: http://httpbin.org/basic-auth/user/passwd vs. the HTTPS version.

There's also been some discussion of blocking the use of userinfo in HTTP-scheme URLs, but some worries about compatibility. https://www.chromium.org/Home/chromium-security/security-faq#TOC-Is-Chrome-s-support-for-userinfo-in-HTTP-URLs-e.g.-http:-user:password-example.com-considered-a-vulnerability-


Labels: -Type-Bug-Security -Restrict-View-SecurityTeam Type-Feature
Removing restrict-view since this is a feature-request.
I think you were unfair to the person submitting this issue: https://bugs.chromium.org/p/chromium/issues/detail?id=626951 
They detailed exactly this issue in a variety of ways.

Please ask yourselves the question, Why do all other browsers warn when a user inputs a URL-Encoded http-basic request to a site that isn't returning a WWW-Authenticate from a probe?

>> either entirely or only via non-secure channels
   It's really not about secure vs insecure channels though. It's about a URL looking like it should go somewhere that it will not and chromium has the ability to warn a user of this ahead of them potentially being phished/cookies stolen/etc. 

I note that you grey the username:password part in the navigation bar. But how many user's are going to inspect that before navigating there, especially if this comes from an email where they just click it.

Components: Internals>Network>Auth Enterprise
Adding Enterprise label for the new policy request.
Owner: ----
Status: Available (was: Assigned)
Making the bug available.
Labels: Enterprise-Triaged
Owner: dskaram@chromium.org
> I note that you grey the username:password part in the navigation bar. 
> But how many user's are going to inspect that before navigating there,
> especially if this comes from an email where they just click it.

Userinfo isn't shown in the URL bar at all when you navigate to a URL containing userinfo. It's only shown in gray as the user edits, and it's removed as soon as they hit enter.

Comment 9 by est...@chromium.org, Nov 10 2017

Labels: Hotlist-EnamelAndFriendsFixIt
Labels: -Hotlist-EnamelAndFriendsFixIt
Status: Assigned (was: Available)
Owner: marcuskoehler@chromium.org

Sign in to add a comment