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

Issue 783941 link

Starred by 1 user

Issue metadata

Status: Assigned
Owner:
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Linux , Android , Windows , Chrome , Mac , Fuchsia
Pri: 2
Type: Feature



Sign in to add a comment

Provide opt-out option to disable HTTP basic-auth on a webpage

Reported by rb...@oath.com, Nov 10 2017

Issue description

Chrome Version       : 62.0.3202.89
OS Version: OS X 10.12.6
URLs (if applicable) :
Other browsers tested:
  Add OK or FAIL after other browsers where you have tested this issue:
     Safari 5:
  Firefox 4.x:
     IE 7/8/9:

What steps will reproduce the problem?
The issue is that when mail.example.com allows contents with embedded resources (eg img tags) loaded from 3rd party servers, those endpoints can force basic-auth to the mail.example.com user by setting basic auth HTTP headers. This can potentially steal user credentials.

What is the expected result?
Feature request: 
A way to disable basic-auth on the top-level web page, that also get applied to all embedded iframes in the page.


What happens instead of that?
Many websites do not require basic-auth, ye they are vulnerable to these types of attacks.


Please provide any additional information below. Attach a screenshot if
possible.

UserAgentString: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_12_6) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/62.0.3202.89 Safari/537.36



 
Components: Security
Labels: -Type-Bug Type-Feature
Cc: susanjuniab@chromium.org
Labels: Needs-Triage-M62
Status: Untriaged (was: Unconfirmed)
As this is marked as Feature request, Untriaging this issue for further updates for Dev.

Thanks..
Labels: -Pri-3 M-64 Pri-2

Comment 5 by mkwst@chromium.org, Nov 17 2017

Components: -Security Blink>FeaturePolicy
Owner: iclell...@chromium.org
This is probably something that y'all should file as a feature request against Feature Policy (https://wicg.github.io/feature-policy/), as that seems like the right place to control this kind of thing at the level of granularity you're asking for.

Ian, is this something you could triage into the feature policy request backlog in one way or another?
Labels: -M-64 -Needs-Triage-M62 M-65 OS-Android OS-Chrome OS-Fuchsia OS-Linux OS-Windows
Status: Available (was: Untriaged)
That's a really interesting idea -- I'll definitely put that on the list of features to look into. (Moving this to M-65, as I don't think we'd get any consensus on how exactly it should work in time for M-64)

Would this stop the loader from attaching credentials to http://user:pass@host/ requests, or just to refuse to send the Authorization header, or retry when a 401 response insists on Basic auth?

I'll add this to my feature backlog, but if you want to file an issue at https://github.com/wicg/feature-policy/issues/, that would be great!

Comment 7 by rb...@oath.com, Nov 28 2017

Thank you for considering this request.
I have created an issue ticket in GitHub: https://github.com/WICG/feature-policy/issues/96

Status: Assigned (was: Available)

Sign in to add a comment