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

[Mike West]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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:

• http://www.benisuef.gov.eg/
• http://www.delmonte.com/
  
• http://www.ip-check.info/
  
• http://www.ljrate.ru/
  
• http://www.mamium.ru/
  
• http://www.montagnes-magazine.com/
  
• http://www.mzalendo.net/
  
• http://www.palmatin.com/
  
• http://www.qirina.com/
  
• http://www.skieur.com/
  
• http://www.staderochelais.com/
  
• http://www.tbogo.com/
• http://www.vrsa.lt/

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]

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:

• http://www.benisuef.gov.eg/

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.

• http://www.delmonte.com/

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.

• http://www.ip-check.info/

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.

• http://www.ljrate.ru/

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. :(

• http://www.mamium.ru/

Same file as the previous page (with same username and password). Same developer, perhaps?

• http://www.montagnes-magazine.com/

 This doesn't load anything with embedded credentials today. 

• http://www.mzalendo.net/

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.

• http://www.palmatin.com/

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.

• http://www.qirina.com/

This doesn't load anything with embedded credentials today.

• http://www.skieur.com/

This doesn't load anything with embedded credentials today. 

• http://www.staderochelais.com/

It looks like there's a live-ticker on this page that uses basic auth for some reason. These requests would be broken.

• http://www.tbogo.com/

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.)

• http://www.vrsa.lt/

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]

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:

• http://www.mzalendo.net/

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.

• http://www.staderochelais.com/

It looks like there's a live-ticker on this page that uses basic auth for some reason. These requests would be broken.

• http://www.tbogo.com/

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]

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]

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]

Thanks Mike, LGTM3

[Joe Medley]

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]

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]

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]

Wikipedia explains - https://en.wikipedia.org/wiki/Brute-force_attack.

(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]

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]

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

https://username:pass...@test.com

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]

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

https://username:password@test.com

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.
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/99203600-1f45-4461-89ad-da02bd21643a%40chromium.org.

[samuel...@gmail.com]

https://bugs.chromium.org/p/chromium/issues/detail?id=731618

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]

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

https://username:password@test.com

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]

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

https://username:password@test.com