HTTPS urging for Chrome Extensions

[Jonathan Garbee]

Currently there is a strong urge of using HTTPS for web sites which reveal to users that their data is being sent insecurely. For example, the insecure prompt when a password input is detected on HTTP. However, Chrome Extensions themselves are in an uncanny valley that doesn't seem to be getting looked at with the same eyes.

For example, Infinity New Tab is a Chrome Extension that is sending all user data over regular HTTP. Even worse, via GET requests. One example from looking at the Network Panel when logging in: `http://api.infinitynewtab.com/login.php?name=te...@example.com&password=5f4dcc3b5aa765d61d8327deb882cf99&version=2`. The password here is hashed with a simple MD5. No salt. So unraveling it is trivial. Salt also would not help here since it is client-side and all clients would need to share the same salt. So attacking it would still be trivial.

There should be an investigation into a UX to show to end-users for different heuristics on private content transfer in this regard. Users shouldn't be fooled into thinking they are safe because something is a Chrome Extension when these extensions aren't considering their users security in how they handle and transfer their content.

[Adrienne Porter Felt]

Thanks for raising this. I'll investigate that extension specifically, but also more generally... you have a good point.

I don't think that UI changes would be feasible here (where would we put the attribution?), but we should be doing a better job detecting issues and pulling these extensions from the store.

[Nathan Buuck]

I searched unsuccessfully on this list and elsewhere to find existing guidance or an indication that Chromium might eventually mandate transport security for connections initiated by an extension. I derived some guidance from previous quarterly summaries from the Chromium security team and from talks like this one at Google I/O '17 that ubiquitous HTTPS is a common goal in the browser ecosystem. Given this, is it unreasonable to envision a future when browser extensions are only allowed to make web requests using transport security? 

I think there are a few justifications for this:

• Connections by extensions are opaque to end users and UI challenges alluded to in this thread make it impractical to alert a user to plain-text web calls from an extension.
• The LetsEncrypt service has greatly reduced the cost of entry for endpoints to be configured for HTTPS, making it practical and accessible for extension developers to comply with the proposed requirement.
• A requirement enforced by the browser seems more reliable than trying to observe and flag these in the Web Store.
• There is already a policy requirement for publishing an extension to the Web Store when transmitting PII or authentication data.

While this problem will eventually be mitigated when HTTP/2 reaches ubiquity, my feeling is that this risk can and should be mitigated sooner than that eventuality.

On Friday, June 9, 2017 at 10:28:41 AM UTC-4, Adrienne Porter Felt wrote:

Thanks for raising this. I'll investigate that extension specifically, but also more generally... you have a good point.

I don't think that UI changes would be feasible here (where would we put the attribution?), but we should be doing a better job detecting issues and pulling these extensions from the store.

On Fri, Jun 9, 2017 at 4:35 AM Jonathan Garbee <jonatha...@gmail.com> wrote:

Currently there is a strong urge of using HTTPS for web sites which reveal to users that their data is being sent insecurely. For example, the insecure prompt when a password input is detected on HTTP. However, Chrome Extensions themselves are in an uncanny valley that doesn't seem to be getting looked at with the same eyes.

For example, Infinity New Tab is a Chrome Extension that is sending all user data over regular HTTP. Even worse, via GET requests. One example from looking at the Network Panel when logging in: `http://api.infinitynewtab.com/login.php?name=test@example.com&password=5f4dcc3b5aa765d61d8327deb882cf99&version=2`. The password here is hashed with a simple MD5. No salt. So unraveling it is trivial. Salt also would not help here since it is client-side and all clients would need to share the same salt. So attacking it would still be trivial.

[Jonathan Garbee]

A UI I was thinking was, on detecting an HTTP Request with sensitive details detected coming from an extension request a bubble/infobar could be raised, "{Extension name} is attempting to send your data in an insecure way. Allow this to continue?" with a Yes/No trigger and No being the default. Even if this kind of thing were done only in Canary and Dev channels where we expect more sophisticated users, this would help find extensions that could open end-users data up to anyone on the network.

I only caught this one by sheer dumb luck of needing to recover my password the day after making the account. So when I reset the password I noticed it was an HTTP page and not HTTPS. Upon trying HTTPS, it failed. Which led me to dig into the extension and see it really was just using HTTP for all their API communication.

I have emailed the extension author to let them know of the issue and the steps to take to address it. I think at least some analysis on submitted extensions to look for requests including CC info and passwords, and if the endpoint URLs are http:// then an auto-rejection through the play store could be done. With manual review request to bypass in case the heuristic is off by chance. While this can be difficult to detect without executing the code depending on how it is written and what libraries are used, the investment to protect end-user's information certainly seems worth it given how important this is to the web ecosystem.

On Fri, Jun 9, 2017 at 10:28 AM, Adrienne Porter Felt <fe...@chromium.org> wrote:

Thanks for raising this. I'll investigate that extension specifically, but also more generally... you have a good point.

I don't think that UI changes would be feasible here (where would we put the attribution?), but we should be doing a better job detecting issues and pulling these extensions from the store.

On Fri, Jun 9, 2017 at 4:35 AM Jonathan Garbee <jonatha...@gmail.com> wrote:

Currently there is a strong urge of using HTTPS for web sites which reveal to users that their data is being sent insecurely. For example, the insecure prompt when a password input is detected on HTTP. However, Chrome Extensions themselves are in an uncanny valley that doesn't seem to be getting looked at with the same eyes.

For example, Infinity New Tab is a Chrome Extension that is sending all user data over regular HTTP. Even worse, via GET requests. One example from looking at the Network Panel when logging in: `http://api.infinitynewtab.com/login.php?name=test@example.com&password=5f4dcc3b5aa765d61d8327deb882cf99&version=2`. The password here is hashed with a simple MD5. No salt. So unraveling it is trivial. Salt also would not help here since it is client-side and all clients would need to share the same salt. So attacking it would still be trivial.

[Chris Palmer]

I'd like to consider something like Apple's App Transport Security policy: disallowing the use of non-secure transport from extensions, or treating the use of non-secure transport as a permission that the extension must request. (Perhaps we could use the latter as a way of phasing in the former.)

[Bil Corry]

As a user, I'd love an option to disable all HTTP traffic originating from extensions.

- Bil

On Mon, Jun 12, 2017 at 11:12 AM, 'Chris Palmer' via Security-dev <securi...@chromium.org> wrote:

I'd like to consider something like Apple's App Transport Security policy: disallowing the use of non-secure transport from extensions, or treating the use of non-secure transport as a permission that the extension must request. (Perhaps we could use the latter as a way of phasing in the former.)

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

[Jonathan Garbee]

I don't feel this kind of thing qualifies as some option in the settings. It isn't something that feels needs to be handled that way. I'd much prefer Chris's recommendation of Non-Secure transport being a permission a user must grant on a per-extension basis.

I think a combo attack to protect users is best. First, HTTP transport must be granted for extensions. Second, once the former is launched, any extensions in the store asking for this permission, get sent through a check looking for if passwords or other sensitive information may be transmitted over the old protocols. If detected either block those extensions pending an update or manual review.

[Ojan Vafai]

I like this idea and think we should pursue it. I like the former more than the latter.

One caveat to keep in mind is that if the extension can inject a content script, then we won't really be able to enforce this unless we heavily lock down what content scripts can do aside from just network requests (which we should probably also consider).

But even without locking down content scripts, we should be able to do this for all the non-content script code.

[Adrienne Porter Felt]

FYI, extensions already have to declare what URLs they're going to talk to, including the scheme. So we already know whether extensions are going to send HTTP requests.

[John Mellor]

There are a bunch of use cases like feed readers, reader mode, buildbot status checks, image slideshows, etc where extensions must fetch data from HTTP websites (using GETs or POSTs).

Requiring extension developers to host an HTTPS-to-HTTP proxy for such cases would both be too expensive (since most extensions are unpaid and server-less), and wouldn't actually improve security, merely hide the problem.

So whilst I encourage stricter review of data being sent over HTTP, and clearer warnings to users, I think a blanket ban would severely decrease the utility of extensions.

[Jonathan Garbee]

I don't feel like a blanket ban was even on the table to discuss. For the foreseeable future HTTP is something that is going to exist and be necessary. However, we can help make users aware when an extension may be requesting data insecurely. And further if an app is asking to get data insecurely and we can analyze sensitive information being sent over those connections, a block and manual review of the extension be necessary to verify the security.

Take the Infinity New Tab page as an example. I as a user may safely assume HTTP for it is fine given the breath of features it has. Perhaps some of those services are HTTP only and they refuse to go secure for any number of reasons. Fine, I can accept that. However, a static analysis of the code could reveal, "Hey, you're transmitting a password key over an insecure connection. This isn't OK." That would then trigger a rejection to publish. Now, it won't catch everything. If people want to dupe the analysis they can. But, the majority of cases could be caught and controlled to prevent users secure information from leaking.

It isn't about any kind of outright block or ban on insecurity. It's about letting users understand which extensions are using it to any extent. Then on the ones that do use insecure transport, try to apply an extra level of scrutiny to what exactly is being done in those requests to protect users.

[Torne (Richard Coles)]

If extensions already have to declare which origins they can contact, then it might solve a lot of those cases to just handle extensions that have "*" in the list of origins they use differently: if they're already loading content from arbitrary origins then loading content from HTTP is still probably inevitable at this point, whereas if there's a specific whitelist of origins then it's much more plausible that they should be using HTTPS only.

[Learner]

This is a good point, though extensions can still communicate with non-declared origins using CORS, JSONP, iframes, and hacks such as images so I don't think it can be relied on completely.

Also, there is no way to distinguish between an extension requesting permissions on a http origin to make requests to it and an extension requesting permission on a http origin in order to dynamically inject a content script which should still be a legitimate use. E.g. if I want to request permissions on http://tvtropes.org/* because I have a page action that puts it in a readable mode, but am not using the content_scripts manifest directive because I'm not doing that on every page, that doesn't mean my extension is insecure.

--

  Learner

--

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

To unsubscribe from this group and stop receiving emails from it, send an email to security-dev...@chromium.org.