Intent to Remove: Support for embedded credentials in subresource requests.

3 994 vues
Accéder directement au premier message non lu

Mike West

non lue,
23 janv. 2017, 06:13:5523/01/2017
à blink-dev,tse...@chromium.org

Primary eng (and PM) emails

mk...@chromium.org


Link to “Intent to Deprecate” thread

https://groups.google.com/a/chromium.org/d/msg/blink-dev/bAMVnc1Zyvs/M3VnxbYPBC0J (which I neglected to follow up on for over 2 years... *sigh*)


Summary

I'd like to block requests for subresources that contain embedded credentials (e.g. "http://ima_user:hunter2@example.com/yay.tiff"). Such resources would be handled as network errors.


We've taken steps in this direction in the past (see the discussion in https://bugs.chromium.org/p/chromium/issues/detail?id=174179 and https://bugs.chromium.org/p/chromium/issues/detail?id=303046). My hope is that usage has decreased in the last ~2 years to the point where it makes sense to try again.


Motivation

Hard-coding credentials into subresource requests is a) crazypants, b) problematic from a security perspective, as it's allowed folks to brute-force credentials in the past. These dangers are exacerbated for credentialed subresource requests that reach into internal IP ranges (your routers, etc). Given the low usage, closing this (small) security hole seems quite reasonable.


Compatibility And Interoperability Risk

Other browsers generally support embedded credentials in subresources. Based on offhand conversations with folks in WebAppSec meetings, my subjective impression is that this isn't a very popular feature, and that we'd be able to get other browser vendors on board if we're successful this time around.


Alternative implementation suggestion for web developers

Developers can embed resources that do not require basic/digest auth, relying instead on cookies and other session management mechanisms.


Usage information from UseCounter

Generally, we've been on a downward slide since we added metrics at the end of 2014: https://www.chromestatus.com/metrics/feature/timeline/popularity/532. Over the 28 days, usage was 0.0012% of page views. That's not huge, but it's not nothing.


The number also includes image requests, even though we've been ignoring the embedded username/password for those requests since ~2013.


The spike between the end of September and the beginning of December is super-weird, but also seems to have subsided.


OWP launch tracking bug

https://crbug.com/435547


Entry on the feature dashboard

https://www.chromestatus.com/feature/5669008342777856


-mike

Jochen Eisinger

non lue,
23 janv. 2017, 06:43:0723/01/2017
à Mike West,blink-dev,tse...@chromium.org
is it possible to factor out the image loads? what sites are using this for non-image loads?

On Mon, Jan 23, 2017 at 12:13 PM Mike West <mk...@chromium.org> wrote:

Primary eng (and PM) emails

mk...@chromium.org


Link to “Intent to Deprecate” thread

https://groups.google.com/a/chromium.org/d/msg/blink-dev/bAMVnc1Zyvs/M3VnxbYPBC0J (which I neglected to follow up on for over 2 years... *sigh*)


Summary

I'd like to block requests for subresources that contain embedded credentials (e.g. "http://ima_user:hun...@example.com/yay.tiff"). Such resources would be handled as network errors.


We've taken steps in this direction in the past (see the discussion in https://bugs.chromium.org/p/chromium/issues/detail?id=174179 and https://bugs.chromium.org/p/chromium/issues/detail?id=303046). My hope is that usage has decreased in the last ~2 years to the point where it makes sense to try again.


Motivation

Hard-coding credentials into subresource requests is a) crazypants, b) problematic from a security perspective, as it's allowed folks to brute-force credentials in the past. These dangers are exacerbated for credentialed subresource requests that reach into internal IP ranges (your routers, etc). Given the low usage, closing this (small) security hole seems quite reasonable.


Compatibility And Interoperability Risk

Other browsers generally support embedded credentials in subresources. Based on offhand conversations with folks in WebAppSec meetings, my subjective impression is that this isn't a very popular feature, and that we'd be able to get other browser vendors on board if we're successful this time around.


Alternative implementation suggestion for web developers

Developers can embed resources that do not require basic/digest auth, relying instead on cookies and other session management mechanisms.


Usage information from UseCounter

Generally, we've been on a downward slide since we added metrics at the end of 2014: https://www.chromestatus.com/metrics/feature/timeline/popularity/532. Over the 28 days, usage was 0.0012% of page views. That's not huge, but it's not nothing.


The number also includes image requests, even though we've been ignoring the embedded username/password for those requests since ~2013.


The spike between the end of September and the beginning of December is super-weird, but also seems to have subsided.


OWP launch tracking bug

https://crbug.com/435547


Entry on the feature dashboard

https://www.chromestatus.com/feature/5669008342777856


-mike

Mike West

non lue,
23 janv. 2017, 07:34:4723/01/2017
à Jochen Eisinger,blink-dev,tse...@chromium.org
On Mon, Jan 23, 2017 at 12:42 PM, Jochen Eisinger <joc...@chromium.org> wrote:
is it possible to factor out the image loads?

I can certainly add a metric that tracks this if it's helpful.

what sites are using this for non-image loads?

An excellent question. HTTPArchive isn't much help. Two pages in the archive (http://www.ljrate.ru/, and http://www.mamium.ru/have `src` attributes containing usernames/passwords. Both point to a script file on `db-stage.maxtarget.ru`[1].

Extending the query to subresources as well[2] yielded 137 hits after excluding some obvious patterns:

* 23 of those aren't HTTP/HTTPS URLs.
* 17 reference `localhost` URLs
* 18 reference things like `example.com`, `test.com`, or otherwise unlikely addresses.
* 20 look like they're from an analytics package at https://sentry.io/

And now there's a fire alarm, so... I'll look at the results a little more once the building is no longer burning down around me. :)

-mike

[1]: I used the following; I'm 80% sure the regex is reasonable:

```
SELECT
  *
FROM (
  SELECT
    page,
    url,
    REGEXP_EXTRACT(body, r'(\w+\s*=\s*(?:"\s*\w+://[^"\s\.]+:[^"\s]+@[^"\s]+\s*"|\'\s*\w+://[^\'\s\.]+:[^\'\s]+@[^\'\s]+\s*\'))') as match
  FROM 
    [httparchive:har.2017_01_01_chrome_requests_bodies]
) WHERE
  page == url AND
  match != "null"
```

[2]: 
```
SELECT
  *
FROM (
  SELECT
    page,
    url,
    REGEXP_EXTRACT(body, r'((?:"\s*\w+://[^"\s\.]+:[^"\s]+@[^"\s]+\s*"|\'\s*\w+://[^\'\s\.]+:[^\'\s]+@[^\'\s]+\s*\'))') as match
  FROM 
    [httparchive:har.2017_01_01_chrome_requests_bodies]
) WHERE
  match != "null" AND
  NOT match CONTAINS "http://mailto:" AND
  NOT match CONTAINS "http://username:password@hostname" AND
  NOT match CONTAINS "http://user:pa...@example.com"
```


On Mon, Jan 23, 2017 at 12:13 PM Mike West <mk...@chromium.org> wrote:

Primary eng (and PM) emails

mk...@chromium.org


Link to “Intent to Deprecate” thread

https://groups.google.com/a/chromium.org/d/msg/blink-dev/bAMVnc1Zyvs/M3VnxbYPBC0J (which I neglected to follow up on for over 2 years... *sigh*)


Summary

I'd like to block requests for subresources that contain embedded credentials (e.g. "http://ima_user:hunter2@example.com/yay.tiff"). Such resources would be handled as network errors.


We've taken steps in this direction in the past (see the discussion in https://bugs.chromium.org/p/chromium/issues/detail?id=174179 and https://bugs.chromium.org/p/chromium/issues/detail?id=303046). My hope is that usage has decreased in the last ~2 years to the point where it makes sense to try again.


Motivation

Hard-coding credentials into subresource requests is a) crazypants, b) problematic from a security perspective, as it's allowed folks to brute-force credentials in the past. These dangers are exacerbated for credentialed subresource requests that reach into internal IP ranges (your routers, etc). Given the low usage, closing this (small) security hole seems quite reasonable.


Compatibility And Interoperability Risk

Other browsers generally support embedded credentials in subresources. Based on offhand conversations with folks in WebAppSec meetings, my subjective impression is that this isn't a very popular feature, and that we'd be able to get other browser vendors on board if we're successful this time around.


Alternative implementation suggestion for web developers

Developers can embed resources that do not require basic/digest auth, relying instead on cookies and other session management mechanisms.


Usage information from UseCounter

Generally, we've been on a downward slide since we added metrics at the end of 2014: https://www.chromestatus.com/metrics/feature/timeline/popularity/532. Over the 28 days, usage was 0.0012% of page views. That's not huge, but it's not nothing.


The number also includes image requests, even though we've been ignoring the embedded username/password for those requests since ~2013.


The spike between the end of September and the beginning of December is super-weird, but also seems to have subsided.


OWP launch tracking bug

https://crbug.com/435547


Entry on the feature dashboard

https://www.chromestatus.com/feature/5669008342777856



-mike

Jochen Eisinger

non lue,
23 janv. 2017, 07:44:2223/01/2017
à Mike West,blink-dev,tse...@chromium.org

I'll totally lgtm1 this while freezing outside of the office...


I'd like to block requests for subresources that contain embedded credentials (e.g. "http://ima_user:hun...@example.com/yay.tiff"). Such resources would be handled as network errors.


We've taken steps in this direction in the past (see the discussion in https://bugs.chromium.org/p/chromium/issues/detail?id=174179 and https://bugs.chromium.org/p/chromium/issues/detail?id=303046). My hope is that usage has decreased in the last ~2 years to the point where it makes sense to try again.


Motivation

Hard-coding credentials into subresource requests is a) crazypants, b) problematic from a security perspective, as it's allowed folks to brute-force credentials in the past. These dangers are exacerbated for credentialed subresource requests that reach into internal IP ranges (your routers, etc). Given the low usage, closing this (small) security hole seems quite reasonable.


Compatibility And Interoperability Risk

Other browsers generally support embedded credentials in subresources. Based on offhand conversations with folks in WebAppSec meetings, my subjective impression is that this isn't a very popular feature, and that we'd be able to get other browser vendors on board if we're successful this time around.


Alternative implementation suggestion for web developers

Developers can embed resources that do not require basic/digest auth, relying instead on cookies and other session management mechanisms.


Usage information from UseCounter

Generally, we've been on a downward slide since we added metrics at the end of 2014: https://www.chromestatus.com/metrics/feature/timeline/popularity/532. Over the 28 days, usage was 0.0012% of page views. That's not huge, but it's not nothing.


The number also includes image requests, even though we've been ignoring the embedded username/password for those requests since ~2013.


The spike between the end of September and the beginning of December is super-weird, but also seems to have subsided.


OWP launch tracking bug

https://crbug.com/435547


Entry on the feature dashboard

https://www.chromestatus.com/feature/5669008342777856



-mike

Christian Biesinger

non lue,
23 janv. 2017, 10:45:5123/01/2017
à Mike West,blink-dev,tse...@chromium.org
This seems a little ambiguous with respect to images -- will images continue to ignore the credentials in the URL and thus behave differently from other subresources? Or will it change the image behaviour and potentially break them?

Christian

On Jan 23, 2017 6:13 AM, "Mike West" <mk...@chromium.org> wrote:

Primary eng (and PM) emails

mk...@chromium.org


Link to “Intent to Deprecate” thread

https://groups.google.com/a/chromium.org/d/msg/blink-dev/bAMVnc1Zyvs/M3VnxbYPBC0J (which I neglected to follow up on for over 2 years... *sigh*)


Summary

I'd like to block requests for subresources that contain embedded credentials (e.g. "http://ima_user:hun...@example.com/yay.tiff"). Such resources would be handled as network errors.

Mike West

non lue,
23 janv. 2017, 11:26:3223/01/2017
à Christian Biesinger,blink-dev,tse...@chromium.org
On Mon, Jan 23, 2017 at 4:45 PM, Christian Biesinger <cbies...@chromium.org> wrote:
This seems a little ambiguous with respect to images -- will images continue to ignore the credentials in the URL and thus behave differently from other subresources? Or will it change the image behaviour and potentially break them?

I'd like to treat all subresource requests the same to the extent possible. To that end, we can either treat every request with a username/password embedded in the URL as a network error, or we can strip the username/password from each before sending the request out.

My intuition is that the former is less likely to cause developer pain, as a network error is both visible and explicable. The latter is strange, and likely to be harder to debug in failure cases, as the request will go through, but won't look like it's supposed to when it hits the server (or, even worse, it will reuse the basic auth information cached for the user's connection, and work just fine for the developer, but fail for users).

I'm not a huge fan of our current behavior. For the purposes of this intent, I'd like to just block all subresources that contain embedded credentials.

-mike

Rick Byers

non lue,
23 janv. 2017, 14:35:2423/01/2017
à Mike West,Christian Biesinger,blink-dev,tse...@chromium.org
Can you open a spec issue somewhere (just Fetch again?) so we can get some standards discussion (and an appropriate PR) going on this?

It seems reasonable to me, but in general I think it's best if we break long-standing behavior like this as a step in a consensus process including updating specs, web-platform-tests and aligning with other implementations.

Mike West

non lue,
24 janv. 2017, 07:51:2624/01/2017
à Rick Byers,Eric Lawrence,Christian Biesinger,blink-dev,tse...@chromium.org
On Mon, Jan 23, 2017 at 8:34 PM, Rick Byers <rby...@chromium.org> wrote:
Can you open a spec issue somewhere (just Fetch again?) so we can get some standards discussion (and an appropriate PR) going on this?

It seems reasonable to me, but in general I think it's best if we break long-standing behavior like this as a step in a consensus process including updating specs, web-platform-tests and aligning with other implementations.

Indeed. I put up a PR at https://github.com/whatwg/fetch/pull/465 and pinged a few folks.

Regarding "long standing", https://support.microsoft.com/en-us/help/834489/internet-explorer-does-not-support-user-names-and-passwords-in-web-site-addresses-http-or-https-urls suggests that MS hasn't supported the embedded credentials syntax since at least 2011. +elawrence, who probably has historical context.

-mike

Rick Byers

non lue,
24 janv. 2017, 13:35:3424/01/2017
à Mike West,Eric Lawrence,Christian Biesinger,blink-dev,tse...@chromium.org
Thanks.  OK if we give the discussion on that PR a few days to shake out before making a decision?  If there's no major objection from other implementors on the big-picture change, then I'm personally OK landing the removal and continuing the spec work in parallel.

We should probably do a deprecation warning for one milestone before removal.  Would you want to try to get that merged back to 57, or best case just deprecation in 58 and remove in 59?


-mike


Mike West

non lue,
25 janv. 2017, 03:38:5425/01/2017
à Rick Byers,Eric Lawrence,Christian Biesinger,blink-dev,tse...@chromium.org
On Tue, Jan 24, 2017 at 7:35 PM, Rick Byers <rby...@chromium.org> wrote:
On Tue, Jan 24, 2017 at 7:51 AM, Mike West <mk...@google.com> wrote:
On Mon, Jan 23, 2017 at 8:34 PM, Rick Byers <rby...@chromium.org> wrote:
Can you open a spec issue somewhere (just Fetch again?) so we can get some standards discussion (and an appropriate PR) going on this?

It seems reasonable to me, but in general I think it's best if we break long-standing behavior like this as a step in a consensus process including updating specs, web-platform-tests and aligning with other implementations.

Indeed. I put up a PR at https://github.com/whatwg/fetch/pull/465 and pinged a few folks.

Regarding "long standing", https://support.microsoft.com/en-us/help/834489/internet-explorer-does-not-support-user-names-and-passwords-in-web-site-addresses-http-or-https-urls suggests that MS hasn't supported the embedded credentials syntax since at least 2011. +elawrence, who probably has historical context.

Thanks.  OK if we give the discussion on that PR a few days to shake out before making a decision?  If there's no major objection from other implementors on the big-picture change, then I'm personally OK landing the removal and continuing the spec work in parallel.

Certainly. Given the ~2 year gap between the original intent and now, I don't think there's any rush on this. :)
 
We should probably do a deprecation warning for one milestone before removal.  Would you want to try to get that merged back to 57, or best case just deprecation in 58 and remove in 59?

 I'm happy to add a deprecation warning in 58 targeting 59. Depending on the timing, I'd be equally happy to merge that back to 57 (still targeting 59) to give developers more warning.

-mike

Philip Jägenstedt

non lue,
7 févr. 2017, 01:03:3607/02/2017
à Mike West,Rick Byers,Eric Lawrence,Christian Biesinger,blink-dev,tse...@chromium.org
Is there anything in particular that needs to happen to make progress on https://github.com/whatwg/fetch/pull/465?

The usage here isn't entirely negligible. In https://bigquery.cloud.google.com:443/savedquery/762219082167:efe9306ff8b14209a7d9eb2111a9c71b I queried for sites that are hitting this use counter:
Mike, could you try the change locally and check how these are affected? This is probably a somewhat representative sample of the problem. (1 NSFW redacted.)

Mike West

non lue,
7 févr. 2017, 05:16:3807/02/2017
à Philip Jägenstedt,Rick Byers,Eric Lawrence,Christian Biesinger,blink-dev,tse...@chromium.org
On Tue, Feb 7, 2017 at 7:03 AM, Philip Jägenstedt <foo...@chromium.org> wrote:
Is there anything in particular that needs to happen to make progress on https://github.com/whatwg/fetch/pull/465?

People need to pay attention to it? I've poked folks. I'll do so again.

The usage here isn't entirely negligible. In https://bigquery.cloud.google.com:443/savedquery/762219082167:efe9306ff8b14209a7d9eb2111a9c71b I queried for sites that are hitting this use counter:
A request is indeed broken on this page, though I can't tell what on the page it actually effects.

I'd note, however, that the credentials included in the request _appear_ to be functional Sharepoint credentials (base64-encoded for security). This is more or less exactly the kind of footgun we'd like to discourage.
An iframe on this page is including a stylesheet from what looks like a staging server. The functionality is unaffected, but the form's styling is a little off. Poking at the relevant studio in https://twitter.com/mikewest/status/828902340593852416.
This page is using cached HTTP session info to fingerprint users, as part of a sales pitch for their privacy-protecting Firefox extension. I think they're unlikely to be upset that the browser is making this more difficult.
This page contains JavaScript loaded from `db-stage.maxtarget.ru`. I'm sure it causes breakage on the page, but I'm equally sure that the developers didn't actually intend to ship code from a staging server. :(
Same file as the previous page (with same username and password). Same developer, perhaps?
 This doesn't load anything with embedded credentials today. 
This loads an image with a username, but doesn't actually require the username to load. In this case, a weaker variant of the deprecation that simply ignored the username/password would be effective. I'm a little worried about doing that because I think it's more likely to be confusing to developers than simply blocking the load, but it's worth considering.
This page tries to load `http://www.palmatin.comhttp@importurl%28http//fonts.googleapis.com/css?fami…ans%3A400%2C600%2C700%2C400italic%2C300%7CLato%3A400%2C300%29%3B&ver=3.5.2`, which really looks like a typo that doesn't work today.
This doesn't load anything with embedded credentials today.
This doesn't load anything with embedded credentials today. 
It looks like there's a live-ticker on this page that uses basic auth for some reason. These requests would be broken.
This page has real breakage, as they're using a username of `true` for resources that don't need basic auth. This looks like a simple typo in their JavaScript... I'll see if I can find someone to poke at (their "contact" form requires a user account, and my Korean is... well... bad.)
This doesn't load anything with embedded credentials today. 
 
Mike, could you try the change locally and check how these are affected? This is probably a somewhat representative sample of the problem. (1 NSFW redacted.)

The NSFW page is just as NSFW with this change as without it.

Turns out, the credentialed request generated on this page is actually (very poorly) trying to hijack your router's DNS settings. Making this kind of attack more difficult is one of the explicit goals of this deprecation). I've reported it to safebrowsing.
-mike

Philip Jägenstedt

non lue,
8 févr. 2017, 00:01:1008/02/2017
à Mike West,Rick Byers,Eric Lawrence,Christian Biesinger,blink-dev,tse...@chromium.org
Thanks for digging through all of those sites, Mike.

On Tue, Feb 7, 2017 at 5:16 AM Mike West <mk...@chromium.org> wrote:
On Tue, Feb 7, 2017 at 7:03 AM, Philip Jägenstedt <foo...@chromium.org> wrote:
This loads an image with a username, but doesn't actually require the username to load. In this case, a weaker variant of the deprecation that simply ignored the username/password would be effective. I'm a little worried about doing that because I think it's more likely to be confusing to developers than simply blocking the load, but it's worth considering.

If it comes up again and again I suppose that might be OK, but try your preferred route first.

It looks like there's a live-ticker on this page that uses basic auth for some reason. These requests would be broken.
This page has real breakage, as they're using a username of `true` for resources that don't need basic auth. This looks like a simple typo in their JavaScript... I'll see if I can find someone to poke at (their "contact" form requires a user account, and my Korean is... well... bad.)

Samsung, halp? :)

Anyway, giving everyone a heads up would be good, but then there are almost certainly many more cases in the long tail outside httparchive, or that happen after the initial page load.

Deprecation, even over many milestones, is pretty unlikely to reach most of the long tail sites, so some things will break, no way around that. On the upside, seems like it's mostly images and not breaking the site entirely.

We have no formula for making these trade-offs, so I guess let's try and reconsider if some reported breakage is non-trivial. LGTM2.

Eric Lawrence

non lue,
8 févr. 2017, 17:37:5908/02/2017
à Mike West,Rick Byers,Christian Biesinger,blink-dev,tse...@chromium.org
Sorry I missed this question. Support for credentials embedded in HTTP and HTTPS URLs was dropped in IE6, circa 2004, as such credentials were used almost exclusively for phishing. Credentials in HTTP/HTTPS URLs were deemed non-standard (by omission in RFC2616). 

There's a "feature control key" (registry) that can turn support back on: FEATURE_HTTP_USERNAME_PASSWORD_DISABLE, but we received relatively few requests for this.

There's no prohibition for other protocol schemes (e.g. FTP).

-Eric

Mike West

non lue,
17 févr. 2017, 03:31:1417/02/2017
à Eric Lawrence,Rick Byers,Christian Biesinger,blink-dev,tse...@chromium.org
A brief update: I added a deprecation message targeting M59, and I merged that back to M57. It should be hitting stable shortly.

Mozilla seems tentatively on board with the idea, and Anne's willing to merge it to Fetch: https://github.com/whatwg/fetch/pull/465

Given that, would one of you fine folks be willing to add a third-LGTY for removal in M59?


-mike

Rick Byers

non lue,
17 févr. 2017, 17:55:0217/02/2017
à Mike West,Eric Lawrence,Christian Biesinger,blink-dev,tse...@chromium.org
Thanks Mike, LGTM3

Joe Medley

non lue,
21 févr. 2017, 13:02:2421/02/2017
à Rick Byers,Mike West,Eric Lawrence,Christian Biesinger,blink-dev,tse...@chromium.org
Mike,

Did any part of this go out in M52 as reported in the status entry? Also, to which platforms does this new deprecation apply?

Joe

Joe Medley | Technical Writer, Chrome DevRel | jme...@google.com | 816-678-7195
If an API's not documented it doesn't exist.

Thanks Mike, LGTM3
--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.

Mike West

non lue,
22 févr. 2017, 08:31:3622/02/2017
à Joe Medley,Rick Byers,Eric Lawrence,Christian Biesinger,blink-dev,tse...@chromium.org
Updated the entry to note that we're now sending visible deprecation warnings in M57. The deprecation message did not ship in 42, as the entry previously indicated.

The deprecation applies to all Blink platforms (e.g. everything but iOS).


-mike

Joe Medley

non lue,
22 févr. 2017, 18:24:0722/02/2017
à Mike West,Rick Byers,Eric Lawrence,Christian Biesinger,blink-dev,tse...@chromium.org
Mike,

I'm adding this to the deprecations and removals post. I need to know something. In the intent what do you mean by, 'it's allowed folks to brute-force credentials'? It's the 'brute-force' part I'm having trouble with.

Joe

Joe Medley | Technical Writer, Chrome DevRel | jme...@google.com | 816-678-7195
If an API's not documented it doesn't exist.

PhistucK

non lue,
23 févr. 2017, 01:59:5723/02/2017
à Joe Medley,Mike West,Rick Byers,Eric Lawrence,Christian Biesinger,blink-dev,tse...@chromium.org
(Basically, having many images on a page with various credential combinations and listening to the onload event. Once fired, if at all, the right credentials have been found)


PhistucK

jayman...@gmail.com

non lue,
20 avr. 2017, 14:06:1620/04/2017
à blink-dev,tse...@chromium.org
I see some developers have utilized embedded credentials to attempt to invalidate an existing set of windows authentication credentials with IIS / NTLM by passing a dummy username and password - essentially to make a logout function, versus instructing the user to try and close all browser windows. Probably much more common in corporate environments.

IE has document.execCommand("ClearAuthenticationCache").  Could something similar be introduced?

The problem with the IE ClearAuthenticationCache is that it clears ALL entries. If something was restricted to the existing domain, then it would make more sense and fulfill the mantra of improved web application security.

samuel...@gmail.com

non lue,
9 juin 2017, 15:42:0609/06/2017
à blink-dev,tse...@chromium.org
This update is causing us issues with sites protected by basic auth that have relative subresource requests.  It happens when we include the username and password in the url (typically for automated testing).  In this case, the initial request is fine, but since the subsequent resources end up including the username/password, they are rejected.  Is it possible to treat relative subresources differently?

For example, this would fail to load the css file when protected

index.html
<link href="/theme.css" rel="stylesheet">


On Monday, January 23, 2017 at 3:13:55 AM UTC-8, Mike West wrote:

Primary eng (and PM) emails

mk...@chromium.org


Link to “Intent to Deprecate” thread

https://groups.google.com/a/chromium.org/d/msg/blink-dev/bAMVnc1Zyvs/M3VnxbYPBC0J (which I neglected to follow up on for over 2 years... *sigh*)


Summary

I'd like to block requests for subresources that contain embedded credentials (e.g. "http://ima_user:hun...@example.com/yay.tiff"). Such resources would be handled as network errors.

PhistucK

non lue,
9 juin 2017, 16:01:2009/06/2017
à samuel...@gmail.com,blink-dev,Tom Sepez
I do not think that was supposed to happen. This intent blocks request that originated from src or href with embedded credentials. It is not about blocking subresource requests to which the browser added the credentials automatically.

So, a page at http://a:a...@b.com that has a stylesheet reference, <link rel=stylesheet href=http://a:a...@b.com/style.css> should fail, but a page at http://a:a...@b.com that has a stylesheet reference, <link rel=stylesheet href=style.css> should succeed (it might trigger an error 403, but I think the browser would automatically use the credentials of the page for the same origin), unless I am misunderstanding the intent.

You can search crbug.com for an existing issue and star it. If you cannot find one, file a new issue using the "New issue" link on the same page.
Please, do not add a "+1" or "Me too" or "Confirmed" (or similar) comment. It just wastes the time of Chrome engineers and sends unnecessary e-mails to all of the people who starred the issue.

You can reply with a link to the found or created issue and might get triaged (and fixed) faster.

Thank you.



PhistucK

On Fri, Jun 9, 2017 at 10:42 PM, <samuel...@gmail.com> wrote:
This update is causing us issues with sites protected by basic auth that have relative subresource requests.  It happens when we include the username and password in the url (typically for automated testing).  In this case, the initial request is fine, but since the subsequent resources end up including the username/password, they are rejected.  Is it possible to treat relative subresources differently?

For example, this would fail to load the css file when protected
<link href="/theme.css" rel="stylesheet">


On Monday, January 23, 2017 at 3:13:55 AM UTC-8, Mike West wrote:

Primary eng (and PM) emails

mk...@chromium.org


Link to “Intent to Deprecate” thread

https://groups.google.com/a/chromium.org/d/msg/blink-dev/bAMVnc1Zyvs/M3VnxbYPBC0J (which I neglected to follow up on for over 2 years... *sigh*)


Summary

I'd like to block requests for subresources that contain embedded credentials (e.g. "http://ima_user:hunter2@example.com/yay.tiff"). Such resources would be handled as network errors.


We've taken steps in this direction in the past (see the discussion in https://bugs.chromium.org/p/chromium/issues/detail?id=174179 and https://bugs.chromium.org/p/chromium/issues/detail?id=303046). My hope is that usage has decreased in the last ~2 years to the point where it makes sense to try again.


Motivation

Hard-coding credentials into subresource requests is a) crazypants, b) problematic from a security perspective, as it's allowed folks to brute-force credentials in the past. These dangers are exacerbated for credentialed subresource requests that reach into internal IP ranges (your routers, etc). Given the low usage, closing this (small) security hole seems quite reasonable.


Compatibility And Interoperability Risk

Other browsers generally support embedded credentials in subresources. Based on offhand conversations with folks in WebAppSec meetings, my subjective impression is that this isn't a very popular feature, and that we'd be able to get other browser vendors on board if we're successful this time around.


Alternative implementation suggestion for web developers

Developers can embed resources that do not require basic/digest auth, relying instead on cookies and other session management mechanisms.


Usage information from UseCounter

Generally, we've been on a downward slide since we added metrics at the end of 2014: https://www.chromestatus.com/metrics/feature/timeline/popularity/532. Over the 28 days, usage was 0.0012% of page views. That's not huge, but it's not nothing.


The number also includes image requests, even though we've been ignoring the embedded username/password for those requests since ~2013.


The spike between the end of September and the beginning of December is super-weird, but also seems to have subsided.


OWP launch tracking bug

https://crbug.com/435547


Entry on the feature dashboard

https://www.chromestatus.com/feature/5669008342777856


-mike

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.

samuel...@gmail.com

non lue,
9 juin 2017, 19:27:2509/06/2017
à blink-dev,tse...@chromium.org


On Monday, January 23, 2017 at 3:13:55 AM UTC-8, Mike West wrote:

Primary eng (and PM) emails

mk...@chromium.org


Link to “Intent to Deprecate” thread

https://groups.google.com/a/chromium.org/d/msg/blink-dev/bAMVnc1Zyvs/M3VnxbYPBC0J (which I neglected to follow up on for over 2 years... *sigh*)


Summary

I'd like to block requests for subresources that contain embedded credentials (e.g. "http://ima_user:hun...@example.com/yay.tiff"). Such resources would be handled as network errors.

fai...@gmail.com

non lue,
9 juin 2017, 20:55:0409/06/2017
à blink-dev,samuel...@gmail.com,tse...@chromium.org


I'm in favor of the rationale behind this change, but I would like to know if there's a way around it if we're willing to take the risk of sending an embedded auth?  It would be nice to turn it on and off either on a site specific or global basis rather than to not have it at all.

Thanks.  -Andy.



On Friday, June 9, 2017 at 1:01:20 PM UTC-7, PhistucK wrote:
I do not think that was supposed to happen. This intent blocks request that originated from src or href with embedded credentials. It is not about blocking subresource requests to which the browser added the credentials automatically.

So, a page at http://a:a...@b.com that has a stylesheet reference, <link rel=stylesheet href=http://a:a...@b.com/style.css> should fail, but a page at http://a:a...@b.com that has a stylesheet reference, <link rel=stylesheet href=style.css> should succeed (it might trigger an error 403, but I think the browser would automatically use the credentials of the page for the same origin), unless I am misunderstanding the intent.

You can search crbug.com for an existing issue and star it. If you cannot find one, file a new issue using the "New issue" link on the same page.
Please, do not add a "+1" or "Me too" or "Confirmed" (or similar) comment. It just wastes the time of Chrome engineers and sends unnecessary e-mails to all of the people who starred the issue.

You can reply with a link to the found or created issue and might get triaged (and fixed) faster.

Thank you.



PhistucK

On Fri, Jun 9, 2017 at 10:42 PM, <samuel...@gmail.com> wrote:
This update is causing us issues with sites protected by basic auth that have relative subresource requests.  It happens when we include the username and password in the url (typically for automated testing).  In this case, the initial request is fine, but since the subsequent resources end up including the username/password, they are rejected.  Is it possible to treat relative subresources differently?

For example, this would fail to load the css file when protected

index.html
<link href="/theme.css" rel="stylesheet">


On Monday, January 23, 2017 at 3:13:55 AM UTC-8, Mike West wrote:

Primary eng (and PM) emails

mk...@chromium.org


Link to “Intent to Deprecate” thread

https://groups.google.com/a/chromium.org/d/msg/blink-dev/bAMVnc1Zyvs/M3VnxbYPBC0J (which I neglected to follow up on for over 2 years... *sigh*)


Summary

I'd like to block requests for subresources that contain embedded credentials (e.g. "http://ima_user:hun...@example.com/yay.tiff"). Such resources would be handled as network errors.


We've taken steps in this direction in the past (see the discussion in https://bugs.chromium.org/p/chromium/issues/detail?id=174179 and https://bugs.chromium.org/p/chromium/issues/detail?id=303046). My hope is that usage has decreased in the last ~2 years to the point where it makes sense to try again.


Motivation

Hard-coding credentials into subresource requests is a) crazypants, b) problematic from a security perspective, as it's allowed folks to brute-force credentials in the past. These dangers are exacerbated for credentialed subresource requests that reach into internal IP ranges (your routers, etc). Given the low usage, closing this (small) security hole seems quite reasonable.


Compatibility And Interoperability Risk

Other browsers generally support embedded credentials in subresources. Based on offhand conversations with folks in WebAppSec meetings, my subjective impression is that this isn't a very popular feature, and that we'd be able to get other browser vendors on board if we're successful this time around.


Alternative implementation suggestion for web developers

Developers can embed resources that do not require basic/digest auth, relying instead on cookies and other session management mechanisms.


Usage information from UseCounter

Generally, we've been on a downward slide since we added metrics at the end of 2014: https://www.chromestatus.com/metrics/feature/timeline/popularity/532. Over the 28 days, usage was 0.0012% of page views. That's not huge, but it's not nothing.


The number also includes image requests, even though we've been ignoring the embedded username/password for those requests since ~2013.


The spike between the end of September and the beginning of December is super-weird, but also seems to have subsided.


OWP launch tracking bug

https://crbug.com/435547


Entry on the feature dashboard

https://www.chromestatus.com/feature/5669008342777856


-mike

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

uscen...@gmail.com

non lue,
10 juin 2017, 02:25:1710/06/2017
à blink-dev,tse...@chromium.org,samuel...@gmail.com
This is also breaking all our tests with chrome. 

Since we have no control over the use of basic auth is there a suggested solution to use as a workaround?


On Friday, June 9, 2017 at 12:42:06 PM UTC-7, samuel...@gmail.com wrote:
This update is causing us issues with sites protected by basic auth that have relative subresource requests.  It happens when we include the username and password in the url (typically for automated testing).  In this case, the initial request is fine, but since the subsequent resources end up including the username/password, they are rejected.  Is it possible to treat relative subresources differently?

For example, this would fail to load the css file when protected

Mike West

non lue,
12 juin 2017, 06:33:1012/06/2017
à uscen...@gmail.com,blink-dev,tse...@chromium.org,samuel...@gmail.com
1. Thanks for the reports! I have a patch out to address https://bugs.chromium.org/p/chromium/issues/detail?id=731618, and I'll see how likely it is we can get it merged back.

2. Given the absolute usage of embedded credentials in top-level navigations (0.00097% of top-level navigations over the last ~month of stable usage), this is a use case we've been considering removing entirely. It sounds like that would have some negative impact on the developer case you're working with; we'll have to take that into account when considering the overall impact.

-mike

On Sat, Jun 10, 2017 at 8:25 AM, <uscen...@gmail.com> wrote:
This is also breaking all our tests with chrome. 

Since we have no control over the use of basic auth is there a suggested solution to use as a workaround?

On Friday, June 9, 2017 at 12:42:06 PM UTC-7, samuel...@gmail.com wrote:
This update is causing us issues with sites protected by basic auth that have relative subresource requests.  It happens when we include the username and password in the url (typically for automated testing).  In this case, the initial request is fine, but since the subsequent resources end up including the username/password, they are rejected.  Is it possible to treat relative subresources differently?

For example, this would fail to load the css file when protected

index.html
<link href="/theme.css" rel="stylesheet">

On Monday, January 23, 2017 at 3:13:55 AM UTC-8, Mike West wrote:

Primary eng (and PM) emails

mk...@chromium.org


Link to “Intent to Deprecate” thread

https://groups.google.com/a/chromium.org/d/msg/blink-dev/bAMVnc1Zyvs/M3VnxbYPBC0J (which I neglected to follow up on for over 2 years... *sigh*)


Summary

I'd like to block requests for subresources that contain embedded credentials (e.g. "http://ima_user:hunter2@example.com/yay.tiff"). Such resources would be handled as network errors.


We've taken steps in this direction in the past (see the discussion in https://bugs.chromium.org/p/chromium/issues/detail?id=174179 and https://bugs.chromium.org/p/chromium/issues/detail?id=303046). My hope is that usage has decreased in the last ~2 years to the point where it makes sense to try again.


Motivation

Hard-coding credentials into subresource requests is a) crazypants, b) problematic from a security perspective, as it's allowed folks to brute-force credentials in the past. These dangers are exacerbated for credentialed subresource requests that reach into internal IP ranges (your routers, etc). Given the low usage, closing this (small) security hole seems quite reasonable.


Compatibility And Interoperability Risk

Other browsers generally support embedded credentials in subresources. Based on offhand conversations with folks in WebAppSec meetings, my subjective impression is that this isn't a very popular feature, and that we'd be able to get other browser vendors on board if we're successful this time around.


Alternative implementation suggestion for web developers

Developers can embed resources that do not require basic/digest auth, relying instead on cookies and other session management mechanisms.


Usage information from UseCounter

Generally, we've been on a downward slide since we added metrics at the end of 2014: https://www.chromestatus.com/metrics/feature/timeline/popularity/532. Over the 28 days, usage was 0.0012% of page views. That's not huge, but it's not nothing.


The number also includes image requests, even though we've been ignoring the embedded username/password for those requests since ~2013.


The spike between the end of September and the beginning of December is super-weird, but also seems to have subsided.


OWP launch tracking bug

https://crbug.com/435547


Entry on the feature dashboard

https://www.chromestatus.com/feature/5669008342777856


-mike

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.

tobl...@gmail.com

non lue,
28 juin 2017, 17:02:5628/06/2017
à blink-dev,tse...@chromium.org,samuel...@gmail.com

It happens when we include the username and password in the url (typically for automated testing).  

I came here via Google because the above thing just happened to my automated testing script. If this change makes sense or not is above my comprehension but what I am missing is the supposed practice to replace this functionality. I am using basic auth to disable access to my test server and I would guess I am not the only one. I can't come up with a solution to cope with this change without introducing a difference to the production system or unneglictable additional code. Both would be a bigger problem imho then the original small problem this change try to solve.

Kind regards

ohnh...@gmail.com

non lue,
29 juin 2017, 09:57:4229/06/2017
à blink-dev,tse...@chromium.org,samuel...@gmail.com,tobl...@gmail.com
We've the same Problem now, our Codeception Test are not running anymore. Could someone please undo this Change ? 

PhistucK

non lue,
29 juin 2017, 12:23:5929/06/2017
à ohnh...@gmail.com,blink-dev,Tom Sepez,samuel...@gmail.com,tobl...@gmail.com
It was already undone, but in Chrome 61.
Mike is trying to merge it to Chrome 60, but do not expect a fix earlier than that. :(


PhistucK

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/a2d39451-b710-49a1-813b-2f2b20e6fb1a%40chromium.org.

davi...@gmail.com

non lue,
3 juil. 2017, 21:02:3203/07/2017
à blink-dev,uscen...@gmail.com,tse...@chromium.org,samuel...@gmail.com
"Given the absolute usage of embedded credentials in top-level navigations […] this is a use case we've been considering removing entirely"

I think you'll frustrate the developer community if you do. In my experience, it is common to swap standard authentication (e.g. OAuth) for Basic authentication during testing to quickly verify that pages behave correctly for logged-in vs. logged-out users, or different roles, etc. during black-box testing. Automated tests have no way to specify these credentials other than in the URL (the authentication popup is currently inaccessible via automation, and even if it were accessible it would be slower to wait for it to appear, populate credentials, dismiss, and wait for a second page load)

Another (less justifiable and with possible workarounds, but quite convenient) use case I've seen is crudely-protected content used in wallboards & similar. A url such as https://foo:b...@example.com/stats is easy to set up even through the simplest HTTP servers and considered secure enough for some types of data. The main benefit for wallboard situations is that it is easy to auto-load such URLs on opening the browser (which in turn can auto-load on login, etc.) and doesn't need bespoke logic on the server-side (e.g. parsing other types of authentication tokens from the URL). It even removes the credentials from the URL automatically once the page begins loading, all with no code written.

Links between internal corporate services are also a possible use-case which come to mind, though I don't recall encountering anything along those lines myself.

My suspicion is that your stats collection is biased against the situations where this feature is used, since developers and secure corporate environments are more likely to block usage statistics collection.

At a minimum, if you must remove this, make it possible to communicate with the authentication request popup via selenium & similar tooling. But I still think you'll annoy business users.


On Monday, 12 June 2017 11:33:10 UTC+1, Mike West wrote:
1. Thanks for the reports! I have a patch out to address https://bugs.chromium.org/p/chromium/issues/detail?id=731618, and I'll see how likely it is we can get it merged back.

2. Given the absolute usage of embedded credentials in top-level navigations (0.00097% of top-level navigations over the last ~month of stable usage), this is a use case we've been considering removing entirely. It sounds like that would have some negative impact on the developer case you're working with; we'll have to take that into account when considering the overall impact.

-mike

On Sat, Jun 10, 2017 at 8:25 AM, <uscen...@gmail.com> wrote:
This is also breaking all our tests with chrome. 

Since we have no control over the use of basic auth is there a suggested solution to use as a workaround?

On Friday, June 9, 2017 at 12:42:06 PM UTC-7, samuel...@gmail.com wrote:
This update is causing us issues with sites protected by basic auth that have relative subresource requests.  It happens when we include the username and password in the url (typically for automated testing).  In this case, the initial request is fine, but since the subsequent resources end up including the username/password, they are rejected.  Is it possible to treat relative subresources differently?

For example, this would fail to load the css file when protected

index.html
<link href="/theme.css" rel="stylesheet">

On Monday, January 23, 2017 at 3:13:55 AM UTC-8, Mike West wrote:

Primary eng (and PM) emails

mk...@chromium.org


Link to “Intent to Deprecate” thread

https://groups.google.com/a/chromium.org/d/msg/blink-dev/bAMVnc1Zyvs/M3VnxbYPBC0J (which I neglected to follow up on for over 2 years... *sigh*)


Summary

I'd like to block requests for subresources that contain embedded credentials (e.g. "http://ima_user:hun...@example.com/yay.tiff"). Such resources would be handled as network errors.


We've taken steps in this direction in the past (see the discussion in https://bugs.chromium.org/p/chromium/issues/detail?id=174179 and https://bugs.chromium.org/p/chromium/issues/detail?id=303046). My hope is that usage has decreased in the last ~2 years to the point where it makes sense to try again.


Motivation

Hard-coding credentials into subresource requests is a) crazypants, b) problematic from a security perspective, as it's allowed folks to brute-force credentials in the past. These dangers are exacerbated for credentialed subresource requests that reach into internal IP ranges (your routers, etc). Given the low usage, closing this (small) security hole seems quite reasonable.


Compatibility And Interoperability Risk

Other browsers generally support embedded credentials in subresources. Based on offhand conversations with folks in WebAppSec meetings, my subjective impression is that this isn't a very popular feature, and that we'd be able to get other browser vendors on board if we're successful this time around.


Alternative implementation suggestion for web developers

Developers can embed resources that do not require basic/digest auth, relying instead on cookies and other session management mechanisms.


Usage information from UseCounter

Generally, we've been on a downward slide since we added metrics at the end of 2014: https://www.chromestatus.com/metrics/feature/timeline/popularity/532. Over the 28 days, usage was 0.0012% of page views. That's not huge, but it's not nothing.


The number also includes image requests, even though we've been ignoring the embedded username/password for those requests since ~2013.


The spike between the end of September and the beginning of December is super-weird, but also seems to have subsided.


OWP launch tracking bug

https://crbug.com/435547


Entry on the feature dashboard

https://www.chromestatus.com/feature/5669008342777856


-mike

myleaf...@gmail.com

non lue,
7 sept. 2017, 11:23:5407/09/2017
à blink-dev,uscen...@gmail.com,tse...@chromium.org,samuel...@gmail.com,davi...@gmail.com
Here is a workaround I found useful, seems setting the base tag helps with this. Include this snippet in the <head> section before any url references if you don't want a static <base> tag:

<base id="pageBase">
<script language="JavaScript"><!--
try {
    document.getElementById("pageBase").href = document.location.href;
} catch (e) {
}
//--></script>

Although URL passwords are unsafe I do have uses and would rather just have this workaround rather than have
that functionality removed. I think Chrome should do this automatically for a permanent fix but I have not
looked at the Chrome internals to know if that is viable.

vasanth...@gmail.com

non lue,
10 juin 2018, 17:50:1010/06/2018
à blink-dev,uscen...@gmail.com,tse...@chromium.org,samuel...@gmail.com,davi...@gmail.com,myleaf...@gmail.com
Thanks for the solution

Sem VC

non lue,
18 févr. 2021, 11:28:0418/02/2021
à blink-dev,myleaf...@gmail.com,uscen...@gmail.com,tse...@chromium.org,samuel...@gmail.com,davi...@gmail.com
Hi there,

I came accross this page after looking for days to find a solution.

I'm trying to embed an ip camera into an iframe in Google Chrome.

It used to work this way:
https://user:pw@IP/cgi-bin/mjpg/video.cgi?channel=0&amp;subtype=1 

Can you please tell me if there is a workaround?

I'm desperate to find a solution for this.

Thanks in advance,
Sem



Op donderdag 7 september 2017 om 17:23:54 UTC+2 schreef myleaf...@gmail.com:

-mike

Arthur Sonzogni

non lue,
18 févr. 2021, 12:10:3818/02/2021
à Sem VC,blink-dev,myleaf...@gmail.com,uscen...@gmail.com,tse...@chromium.org,samuel...@gmail.com,davi...@gmail.com
Hi Sem,

I am sorry, you have trouble with this.
<iframe> is about navigation. I remember I moved the implementation into:
```
// It only applies to subframes.
// URLs with no embedded credentials should load correctly.
// Relative URLs on top-level pages that were loaded with embedded credentials
// should load correctly.
if (url::Origin::Create(parent_url)
}
// Warn the user about the request being blocked.
const char* console_message =
"Subresource requests whose URLs contain embedded credentials (e.g. "
"`https://user:pass@host/`) are blocked. See "
"details.";
}
```

Maybe you can replace the <iframe> by a new window via ```window.open()```. Or use the same credentials for both the main document and the iframe. Needless to say, I would recommend not to use URLs with credentials.

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/bb6631be-83a8-4911-bc2b-045d3f87b22fn%40chromium.org.
Répondre à tous
Répondre à l'auteur
Transférer
0 nouveau message