New issue
Advanced search Search tips

Issue 658160 link

Starred by 1 user

Issue metadata

Status: WontFix
Owner:
Closed: Oct 2016
Components:
EstimatedDays: ----
NextAction: ----
OS: Linux , Windows , Chrome , Mac
Pri: 2
Type: Bug-Security



Sign in to add a comment

Credentials embedded in URLs are exposed via extension APIs

Project Member Reported by mnissler@chromium.org, Oct 21 2016

Issue description

I noticed surprising extension API behavior today:

1. Install an extension that uses chrome.tabs to inspect URLs. Example extension is attached.
2. Navigate to a URL with embedded credentials, such as http://username:password@localhost, or ftp://anonymous:anonymous@ftp.gnu.org
3. Observe that the extension receives username and password components of the URL in the tab update events (attached sample extension logs them to the console on its background page). I'd have expected that we don't expose embedded credentials to extensions.

Note that the omnibox hides username and password URL components (which is expected). I haven't tested other extension APIs, but suspect that there we might leak credentials elsewhere too.

This is arguably low risk as few users are using URLs with embedded credentials these days.

I'd be surprised if this hasn't been discussed before, but I couldn't find a bug. So filing one just in case :)


 
Project Member

Comment 1 by sheriffbot@chromium.org, Oct 21 2016

Labels: -Pri-3 Pri-2
Project Member

Comment 2 by sheriffbot@chromium.org, Oct 21 2016

Status: Assigned (was: Untriaged)
As far as I know, the hiding of credentials in the Omnibox is primarily intended to mitigate spoofing attacks (e.g. https://goodsite.com:a@evil.com) not as any sort of more elaborate security measure. 

URLs often contain private data (e.g. OAuth tokens and the like) and that data is inherently available to extensions that have the appropriate level of permission to observe tab URLs. Similarly, extensions with network-related permissions see credentials in the course of their normal operation.
Eric, thanks for providing background. I'll leave it to Devlin to make a final decision on whether we want to take action here (feel free to close if this is WAI).
Status: WontFix (was: Assigned)
I think this largely is WAI.  URLs can always contain private information (another, more common, example is capability urls), and we acknowledge that this information can be leaked to the extension (which is why we require a permission for it).  If users expect their urls to contain credentials they don't want leaked, they should not be using an extension that monitors those urls that they don't trust. :)

(Additionally, stealing passwords with extensions is pretty trivial - you can install a keydown listener on a site with a password field via a content script.  Again, we really rely on "if you don't trust it, don't install it" + our abuse detection.)

Sign in to add a comment