navigating to unsafe schemes

[Ojan Vafai]

One of the things we're trying to limit that malicious content does is to navigate you to the Play store (e.g. an ad navigates it's frame to a play store URL). One obvious solution here is to require a user-gesture for the iframe to navigate to an external protocol scheme. I think we'll probably just do that unless someone finds a problem with it.

I wonder if we also should only allow navigating to external protocol schemes if you're on an SSL page. We'd probably need to whitelist some long-standing ones like "mailto." It seems to me that a man-in-the-middle shouldn't be able to drive you do a play store app page.

What do you think?

[Brett Wilson]

We need to be careful when considering whether to restrict something to SSL whether that restriction is for a security reason (NSA can track you via location API or hacker can phish you via fullscreen API) or just because undesirable actors tend not to use SSL. This seems to fall squarely in the latter case, and restricting to SSL seems arbitrary and weird.

Also, for this specific case, we definitely don't want to do this. Lots of sites like http://audulus.com/ (iOS app only) are a company link to an app/play store app that the company makes. And people buy ads for apps all the time. They should be allowed to open in the store if I click on somebody's legitimate app ad.

I think a user gesture is a good idea for external protocols.

Brett

[Ryan Sleevi]

On Tue, Apr 19, 2016 at 8:49 PM, Brett Wilson <bre...@chromium.org> wrote:

We need to be careful when considering whether to restrict something to SSL whether that restriction is for a security reason (NSA can track you via location API or hacker can phish you via fullscreen API) or just because undesirable actors tend not to use SSL. This seems to fall squarely in the latter case, and restricting to SSL seems arbitrary and weird.

I don't think this is true. You're at http://good.example.com, a truly good and benign and trusted site (from the user) with no evil intent. It attempts to direct you to the "GOOD App", on the store. An attacker on the wire, however, replaces the link to "GO0D App" (note a zero), an entirely different, evil app. Because users are (incorrectly) assuming that their trust in http://good.example.com means they can trust "GO0D App", they install potentially harmful software.

At least SSL would guarantee that any user trust is properly preserved - that is, it defends against a threat of an attacker on the wire, which is an entirely reasonable threat (especially considering the NSA has, allegedly, used such attacks in the past)

 

Also, for this specific case, we definitely don't want to do this. Lots of sites like http://audulus.com/ (iOS app only) are a company link to an app/play store app that the company makes.

And an attacker can easily rewrite it to the attacker's app. How is the user to know whether it's trusted? Assuming the app stores are curated and brand protected? They aren't.

 

And people buy ads for apps all the time. They should be allowed to open in the store if I click on somebody's legitimate app ad.

And the legitimate app ads can be trivially replaced with illegitimate app ads. 

[Brett Wilson]

It's always the case that somebody MITM's a site you trust and makes links on that site you trust go to somewhere misleading. The Play/App store is no different than any other link on the web. In all cases we rely on security indicators on the banking site or app store or whatever to tell you whether you're in the place you think you are before you do something potentially dangerous. While it might be nice to say insecure linking shouldn't be possible, that's not the web we have.

Brett

[Eric Lawrence]

> that's not the web we have

It's true that this isn't the web we have. 

However, it is the web that Chrome is driving toward, as we deprecate powerful features on non-secure origins. 

I think a solid argument can be made that invoking other applications is a "powerful capability"-- so much so that on Desktop platforms, we throw a pretty scary modal dialog before invoking the protocol:

 

It is true that some protocols are fairly innocuous (e.g. mailto: is generally safe, modulo the occasional buffer-overflow or command injection in command line parsing, etc). However, other protocol invocations can be annoying (launching an app store, invoking Cortana or any of the other trillion protocols now exposed on Windows 10) and some are downright dangerous (abusing protocol handlers to take unconfirmed/silent/irreversible actions has been the subject of plenty of security researcher scrutiny over the last two decades).

Requiring HTTPS for protocol invocation does not significantly mitigate the "Annoyance" problem (since HTTPS is free and cheap) but it does help mitigate the threat of MITM shenanigans. 

Beyond limiting attack surface, Chrome would benefit from other UX improvements around protocol handlers (e.g. this, and this).

--

Eric Lawrence
Chrome Security

[Brett Wilson]

On Wed, Apr 20, 2016 at 10:40 AM, Eric Lawrence <elaw...@google.com> wrote:

> that's not the web we have

It's true that this isn't the web we have. 

However, it is the web that Chrome is driving toward, as we deprecate powerful features on non-secure origins. 

I think a solid argument can be made that invoking other applications is a "powerful capability"-- so much so that on Desktop platforms, we throw a pretty scary modal dialog before invoking the protocol:

 

It is true that some protocols are fairly innocuous (e.g. mailto: is generally safe, modulo the occasional buffer-overflow or command injection in command line parsing, etc). However, other protocol invocations can be annoying (launching an app store, invoking Cortana or any of the other trillion protocols now exposed on Windows 10) and some are downright dangerous (abusing protocol handlers to take unconfirmed/silent/irreversible actions has been the subject of plenty of security researcher scrutiny over the last two decades).

Requiring HTTPS for protocol invocation does not significantly mitigate the "Annoyance" problem (since HTTPS is free and cheap) but it does help mitigate the threat of MITM shenanigans. 

Beyond limiting attack surface, Chrome would benefit from other UX improvements around protocol handlers (e.g. this, and this).

Be aware that these play store links on Android and iOS aren't actually protocol handlers either. Apps register for URL patterns and Chrome launches the corresponding intent for matches. A lot of things are hooked up this way on Android and changing this is a huge platform decision. The MITM case here for such an invasive change seems weak to me.

Brett

[Bin Lu]

+Ted, who starts to work on the reported issue.

@Ted, what's your plan to fix it? 

The proposal in this thread is to require a user-gesture for the iframe to navigate to an external protocol scheme.

[Ted Choc]

On Thu, Apr 21, 2016 at 11:42 AM, Bin Lu <bi...@google.com> wrote:

+Ted, who starts to work on the reported issue.

@Ted, what's your plan to fix it? 

The proposal in this thread is to require a user-gesture for the iframe to navigate to an external protocol scheme.

My fix is only targeted towards Android, but it will require user gesture for iframe external navigations.

Change:

https://codereview.chromium.org/1908063003/

We already require user gesture for main frame external navigations, so this just carries it forward to iframes.  With the caveat that for main frame navigations, we track and grant user gesture privileges across redirects and do a bit more logic about giving some timing slope for actions.  For iframes, we only track external protocol navigation requests, so we can not do the same logic w/o a fair bit of refactoring.  For now, iframes will be a bit stricter than main frame external navigation requests.

- Ted

[Chris Palmer]

I agree with Eric and Ryan that invoking external applications, or at least some external applications, is a powerful feature that we might want to make available only to secure origins. In particular, we know that people really do perceive app stores as 'curated' and 'safe', and hence it would be good to maintain the minimal chain of trust in good.example.com → GOOD app.

Requiring a user gesture to invoke the external application is also a fine idea, and I definitely think we should do that at least.

+chrome-security-enamel for perhaps additional UX thoughts.

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

[Ojan Vafai]

I think the question is just how much content we would break by doing this. I expect if it's a tiny percentage, then everyone would be fine with this. If it's a large percentage, then many people would disagree that it's worth changing. I think the next step if someone wants to investigate this is to add UseCounters/UMA.

[Ted Choc]

The thing that stands out to me is that desktop shows a dialog before redirecting the user to an external application.  On Android, we do it without any UI that would allow the user to decide whether they wanted to leave Chrome.

While I think requiring a user gesture is the right thing to do, it seems even more important on Android when Chrome is not prompting with any such UI.

To me, it seems very much in line with popup blocking, and I wonder if we should be treating it as such across all platforms.

My fix is indeed a quick one to prevent a particularly bad scenario on Android (since we are auto redirecting users), but there are a few cases that my change is indeed preventing.  Should we carry user gestures across iframe navigations (like Android does for main frame navigations)?  When we block a navigation on Android, all we do is log something to the console saying "navigation to blah is blocked".  Should we be doing more?

In general, navigations in Android are more likely to result in jumping to a native app by the nature of Android's design (intent-filters based on URLs and not explicit non-web-y schemes).  Blocking external navigations on non-https URLs will be a particularly hard sell on Android as I suspect that would break much of the Android intent ecosystem.

- Ted