Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Capturing basic auth credentials in URLs, part 2 #368

Open
nicjansma opened this issue Jan 20, 2023 · 1 comment
Open

Capturing basic auth credentials in URLs, part 2 #368

nicjansma opened this issue Jan 20, 2023 · 1 comment
Assignees

Comments

@nicjansma
Copy link
Contributor

nicjansma commented Jan 20, 2023

I'd like to re-open for discussion this issue we discussed in ~2015: #7

In it, we decided that ResourceTiming entries that contain HTTP Basic Auth in the URL (e.g. https://username:[email protected]) should be kept in the .name (URL) field.

While I think we all agree that this is not best-practice to hard-code credentials into URLs, in the real world we are still seeing this happen in a few scenarios across the web:

  • On test sites, XHR and fetch() querying test data with credentials hard-coded in the URL
  • Some <a hrerf="https://username:[email protected]"> links with credentials hard-coded to e.g. Apache Basic-Auth protected domains or paths

In the DOM/JavaScript, URLs that contain credentials may be read by scripts in a few ways.

Let's say you navigate via a <a href="https://username:[email protected]">click</a> link:

  • window.location.href will not show the credentials for the page's URL
  • document.URL will show the credentials for the page's URL
  • ResourceTiming entries in the .name will show the credentials for any same-domain sub resources fetched (imgs, css, script, etc) and for any programmatic fetches (XHR/fetch) if on the same domain and for any programmatic fetches with credentials hard-coded
  • JavaScript error stacks will show the credentials for any scripts on the same domain

From a compat POV, Chrome and Firefox report the credentials in ResourceTiming, but Safari does not.

Unfortunately this makes it relatively easily to unintentionally capture and potentially exfiltrate credentials, either by the sites themselves, or for a third-party RUM provider.

We discussed this on the 2023/01/19 W3C WebPerf call: https://docs.google.com/document/d/1PNqm7eHbtHjb8d4VQNiti3wuPk3WKLzRs7tUCXXISrA/edit#

My summary of that discussion:

  • I did not hear any objections to removing credentials from ResourceTiming entries
  • Three options for removing credentials:
    • Remove the ResourceTiming entry entirely
    • Remove just the username or username:password from the URL <--- this seemed to be generally prefered
    • Replace username:password with a token e.g. *:* to indicate that credentials were used, but redacted
  • We couldn't come up with any significant scenarios where you'd want to retain credentials in the ResourceTiming URLs
@clelland clelland self-assigned this Jan 30, 2023
@yoavweiss
Copy link
Contributor

@clelland - Any progress on the spec work here? Are there open implementation bugs? WPTs?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants