search

WebView-CG / usage-and-challenges

Documenting usage scenarios for WebView and the challenges they create
https://webview-cg.github.io/usage-and-challenges/
Other
12 stars 4 forks source link

Challenge: Apps can use WebViews to bypass web security standards, privacy standards, and user choice. #36

Open aluhrs13 opened 2 years ago

aluhrs13 commented 2 years ago

Apps can use WebViews to bypass web security standards, privacy standards, and user choice.

Submitter(s)

Andy Luhrs

Motivation

Ensure privacy and security considerations and designs of the web are upheld regardless of if a browser or another app is serving the content.

Analysis

WebViews are extremely useful for apps trying to host their own web content in an application like many of the use-cases we've discussed. However, many of these use-cases could also be used in a malicious or user-hostile manner such as clickjacking or tracking. We need to ensure that websites have a mechanism to protect themselves and their users.

There have been three very thorough articles covering the problems in this space:

  1. @Slightlyoff: Hobson's Browser - How Apple, Facebook, and Google Broke the Mobile Browser Market by Silently Undermining User Choice (related slides).
  2. @KrauseFX: iOS Privacy: Instagram and Facebook can track anything you do on any website in their in-app browser, and Follow-up post iOS Privacy: Announcing InAppBrowser.com - see what JavaScript commands get injected through an in-app browser
  3. @adrianholovaty: Let websites framebust out of native apps

Additionally, many of the cases in the RFC for the X-Frame-Options header can be applied to WebViews.

Related W3C deliverables and/or work items

As mentioned above, the X-Frame-Options header is a solution to a similar problem.

How is the issue solved in the Browser?

There's very few places in a browser similar to this, the closest would be:

What's needed?

We need to propose a method for websites to opt-out of being hosted in a WebView to protect their content and their users. The posts above have a few reasonable starting points, in short:

This CG should go deeper into these problems and potential solutions.

jonathanKingston commented 2 years ago

Network requests

This proposal discusses the use of frames/documents and permitting the site to opt out of that; I think this is a great starting place.

I would suggest that resources are just as concerning for a site; resources likely aren't protecting against the browser being the attacker:

CORS is perhaps a better starting place of a security model into this issue; whereby any domain outside of app-bound domains would be treated as requiring a CORS pre-flight; the site then could send the correct headers to opt-out and permit the connection.

See also:

Preventing document loads

Browsers don't often make OPTIONS requests on navigations, but also this would be the case with the XFO header requirement; the flow would be:

  1. App loads example.com
  2. example.com returns XFO header
  3. OS creates a normal browser window and loads again example.com (ideally can reuse the initial network response from 2.)

Browsers often avoid stopping rendering of a top level document; I think it would be preferred to re-use the initial document response.

For 'capability URLs' this is particularly important that the browser doesn't re-issue a connection it's already made.

Privacy concerns

URL parameters could be a concern here, we're going to be allowing TrackerNetworkA App to open connections into another browser.

The browser should try it's best to circumvent smuggling of tracking ID's across this boundary; if in doubt perhaps ask the user if they wanted it to load in their default browser.

Browsers use-case

@muodov intends to respond here, I think it's worth warranting a carve-out for browsers that happen to use WebViews; I think this is very distinct to apps that use WebViews as supplemental to their core functionality.

Other

iframes are similar to WebViews conceptually and sites can opt-out of being hosted in an iframe via the X-Frame-Options header.

Don't forget CSP frame-ancestors.

muodov commented 2 years ago

This potentially affects many of existing use-cases, such as #30, #24, #29, #23, #20. Referencing them for visibility.

rayankans commented 2 years ago

The privacy issues stem from the fact that the embedder has access to the web content. Giving websites the ability to opt out from being embedded in a WebView seems like a separate issue to me.

I agree that iframes are similar to WebViews conceptually, in #31 I recommended leaning on the web's security model and mapping the iframe's same-origin policy to the WebView scenario. It basically boils down to only allowing embedders web content access to 1P domains.

However, there's more to be said here since it will invalidate perfectly valid use cases like #4. That can perhaps be mitigated by OS browser permissions, or user permissions.

muodov commented 2 years ago

@aluhrs13 Thank you for raising this issue! As I understand, there are 3 related problems described in the linked articles (sorry if I'm repeating your statements):

  1. undermining user’s choice of the user agent
  2. malicious apps using webview capabilities for clickjacking, tracking and other potentially unwanted functionality
    • this is not only about accessing the loaded documents. To protect from tracking, we might want to block unwanted requests from being sent at all. Especially, if the app can alter the request headers
  3. web apps being embedded in native apps against the authors will (basically for the same reasons as XFO)

I think all of these cases are important and should be addressed here, and we need to consider details and edge cases.

It is worth mentioning that on most platforms apps can bundle a rendering engine and circumvent any protections provided by the Webview. This might be better solved on the platform level, out of scope of this CG.

As @rayankans and @jonathanKingston noted above, we should consider the “browser use-case”, when the app’s explicit purpose is providing user agency. In this case the concept of 1st/3rd party domains is not applicable.

pmeenan commented 2 years ago

What distinguishes a "browser" from a well-behaving app that is embedding HTML content and from a malicious app attempting to steal credentials?

There is a lot of risk of this going very sideways for the web without actually improving the security and privacy issues.

Would miniapps be based on web tech stacks if the webview restrictions existed (or were enforced by the webviews in wechat) when they first came around?

I think there are things we can do to make the web work better in an embedded context for well-behaved apps in a way that would be good for the web, apps and users but I don't think a technical solution to prevent abuse by malicious apps is particularly feasible (and hasn't been for a LONG time on desktop).

GDPR-like regulations, privacy policies and app-store review of those policies may be able to help reign-in questionable use of data by apps backed by large companies but they may not dissuade the authors behind malicious apps.

noamr commented 2 years ago

What distinguishes a "browser" from a well-behaving app that is embedding HTML content and from a malicious app attempting to steal credentials?

There is a lot of risk of this going very sideways for the web without actually improving the security and privacy issues.

  • Are we arguing that a ban on browser engines in mobile apps should be encouraged by app stores? If not, would we be pushing apps to ship 40+MB forks of browser engines instead?;

Both are higher barriers of entry (cost, engineering time...) than tracking using a standard WebView. It would make this kind of tracking still possible but harder. Also bundling a whole browser engine in an app that has other purposes would/should raise a flag to app store reviewers.

  • If apps can't build an integrated user experience, would we be pushing content off of the open web and into proprietary formats instead?

Perhaps not everything needs to be in the web platform, or be integrated gradually, and that's OK? Some highly integrated experiences require a lot of thinking on how to make them work safely between the main app and untrusted origins. We can innovate on improving those integrations and in the meantime the tradeoff between safety and experience would lead to a solution that's less seamless but more trustworthy.

  • Even for same-origin-bound webviews, does that actually solve the malicious app problem or can they proxy and rewrite the content through their own back-ends, still phishing credentials from users?

Create their own proxy browser? again this would be a higher barrier of entry than tracking using WebView APIs. An app that uses such service would have to go to great distances to give a web experience that feels legit to users. And of course they would lose out on any WebView<->OS integration.

I think the goal here should not be to hermetically seal the possibility to track users, which like you say is something app-stores/GDPR/other regulations can do, but at least to not make it a front-door easy platform provided API.

I think there are things we can do to make the web work better in an embedded context for well-behaved apps in a way that would be good for the web, apps and users but I don't think a technical solution to prevent abuse by malicious apps is particularly feasible (and hasn't been for a LONG time on desktop).

I think we need to do both. Otherwise why would people do anything different if they can have a WebView out of the box that tracks everything the user does?

Also, desktop is different because desktop users behave differently. People don't generally browse the web inside Electron apps.

pmeenan commented 2 years ago
  • Even for same-origin-bound webviews, does that actually solve the malicious app problem or can they proxy and rewrite the content through their own back-ends, still phishing credentials from users?

Create their own proxy browser? again this would be a higher barrier of entry than tracking using WebView APIs. An app that uses such service would have to go to great distances to give a web experience that feels legit to users. And of course they would lose out on any WebView<->OS integration.

No, I mean use a webview but proxy the underlying pages through servers that I control, rewriting content on the edge (pretty trivial if you're targeting specific pages).

Something like navigating to:

https://evil.com/myaccount.google.com

and then have evil.com make the underlying fetch request for whatever URL it is provided and rewrite any URLs in the returned content to also be proxied.

That would satisfy same-origin requirements for webview or an app-level networking policy but is trivial to implement.

Heck, that's how WebPageTest can re-write production pages for running what-if tests. You can point the browser to a cloudflare edge worker that proxies requests to the actual origin, rewriting content along the way.

Do browsers also have some level of tracking restrictions that should be applied? What, intrinsically, makes the field telemetry reported by "browsers" (and used for search ranking by Google) different from any similar data that a well-behaved webview app would gather (say, to improve ranking of shared content in a social networking app)?

Clear privacy policies and requirements should apply to all apps - browser or webview-embedding. Raising the bar for malicious apps while simultaneously breaking use cases for well-behaved apps feels like a bad trade-off that still won't actually prevent malicious usage.

rejhgadellaa commented 2 years ago

Just coining my 2 cents to advocate for the user and the owner of the site here.

For example, proxying evil.com/my-bank.com would not just work in an IAB, it would also work in a malicious browser app that brings its own engine. If the user decided to trust such an app to be his user agent, XFO and CSF will be pointless anyway. I would argue that users generally do not (knowingly) choose IABs, or any WebView-capable app, to be their user agent, and that scenario is what this proposal (also) targets.

Regarding legitimate browser apps that use WebViews (DuckDuckGo comes to mind): yes, there needs to be a mechanism to allow those apps to open websites in a WebView even when that site requests the default browser. DDG can be set as default on Android, I would assume the same goes for iOS? So - oversimplified - if an app is set as default browser, it would continue to open the site?

aluhrs13 commented 2 years ago

Great discussion everyone, loving all the perspectives. I just wanted to share a quick note from the WebView CG meeting this morning - We agreed that the existence of this challenge and inclusion in this CG makes sense, but that doesn't mean that we need to come up with a solution. Challenges can exist to help future considerations and discussions, not just be addressed with technical solutions.

slightlyoff commented 2 years ago

What distinguishes a "browser" from a well-behaving app that is embedding HTML content and from a malicious app attempting to steal credentials?

Browsers are applications that handle http and https links using the OS affordance for registering to be the default handler. Applications that do not offer to handle links are not browsers.

There is a lot of risk of this going very sideways for the web without actually improving the security and privacy issues.

  • Are we arguing that a ban on browser engines in mobile apps should be encouraged by app stores? If not, would we be pushing apps to ship 40+MB forks of browser engines instead?

No. Browsers can be constructed using WebViews or their own engines. Non-browsers, likewise, should be able to use either a WebView or their own engines, subject to restrictions on non-browsers regarding third-party, non-collaborative content.

  • How would we justify defining a webview-based "browser" that includes content suggestion features and other integrations separate from a content app that also includes web-based content in a webview?

Browsers are browsers, per the above definition, and can do whatever they like with first and third-party content. Restrictions should only attach to non-browsers in the context of third-party content.

  • If apps can't build an integrated user experience, would we be pushing content off of the open web and into proprietary formats instead?

If the counterfactual to non-browser apps stealing traffic to third-party content they do not produce, maintain, or help monetize as effectively as true browsers do is that this third-party content will somehow not be on the web in the future, the mechanism for that is unclear.

If the question is about first and second-party content, apps already frequently move that content out of the open web. But nothing about any proposal here would constraint an app's ability to use a WebView to display that content.

  • Even for same-origin-bound webviews, does that actually solve the malicious app problem or can they proxy and rewrite the content through their own back-ends, still phishing credentials from users?

Proxy-and-rewrite is possible today. What such a policy would do is to ensure that bad actors are seen by all to be acting badly, whereas today they hide in the shadows of unobstrusive UI and undocumented-but-broken platform implementations.

  • Same goes for opera-mini-like server-rendered but streamed content.

To the extent that such an app is the user's choice, and that the app handles http and https links correctly, it is a browser, and there is no issue.

Would miniapps be based on web tech stacks if the webview restrictions existed (or were enforced by the webviews in wechat) when they first came around?

I think there are things we can do to make the web work better in an embedded context for well-behaved apps in a way that would be good for the web, apps and users but I don't think a technical solution to prevent abuse by malicious apps is particularly feasible (and hasn't been for a LONG time on desktop).

GDPR-like regulations, privacy policies and app-store review of those policies may be able to help reign-in questionable use of data by apps backed by large companies but they may not dissuade the authors behind malicious apps.

pmeenan commented 2 years ago

I don't think we're every going to agree on the basics of what software is "allowed" to present web-addressed HTML content to users (and I'm pretty sure it's a hill that many of us are willing to die on on various sides of the argument).

I agree that sites should be allowed to prevent their content from being crawled, scraped or otherwise consumed by a service where they don't want to have their content used. I'm not sure solving that for malicious apps is achievable but I'm totally on-board with defining ways that well-behaved apps should honor content owner's wishes (maybe with options for "block" and "block unless you can open in a system-level default browser").

Same goes for applying privacy and data protection rules equally across all apps - browsers and others equally.

Where we differ pretty fundamentally is that I see the "web" as a set of well-defined specs on how to:

Restrictions beyond that are artificial gates that we are inventing to restrict how content can be consumed and presented to users and will forever limit the "web" to running within what we think of as a stand-alone browser today (most of which do more than JUST loading links - and many of which expressly choose to violate the specs to better serve their users).

Where it matters for this working group is that webviews provide an easy way for apps to get a high-level of consistency and compatibility with the specs above on a given platform and help contribute to a web that works everywhere. If the relationship becomes more adversarial with well-behaving apps in order to push "the web belongs to browsers" then the risks are that the web just won't work as well or as consistently as it would have otherwise.

muodov commented 2 years ago

Some very thoughtful comments here, thank you all. This issue is an entry point to a (probably) big set of security and privacy concerns regarding WebView usage. I think we should try to identify specific topics and eventually split this discussion into multiple threads.

There seem to be some concrete problems such as tracking in IAB and unwanted embedding (see my previous comment), and also some broader discussions such as "respecting user choice" and "what is a browser". Those are also important and could directly affect the security threat model. Should we split these or are there other perspectives on this?

Re the browser definition, I was thinking about this point by @pmeenan:

Even for same-origin-bound webviews, does that actually solve the malicious app problem or can they proxy and rewrite the content through their own back-ends, still phishing credentials from users?

"normal" browsers have an address bar, which is a natural way for users to verify if they are interacting with a trusted origin. Full-fledged WebViews lack the address bar and other UI elements, which by itself may be a concern in scenarios like this.

QingAn commented 1 year ago

This issue is an entry point to a (probably) big set of security and privacy concerns regarding WebView usage. I think we should try to identify specific topics and eventually split this discussion into multiple threads.

There seem to be some concrete problems such as tracking in IAB and unwanted embedding (see my previous comment), and also some broader discussions such as "respecting user choice" and "what is a browser". Those are also important and could directly affect the security threat model. Should we split these or are there other perspectives on this?

+1

muodov commented 1 year ago

I took a stab of splitting this discussion into separate threads:

I couldn't articulate the "user choice" problem as it feels like something platform-specific, but happy to be corrected. @KrauseFx

Is there anything I missed?