怎么会有人把XSS变成WebView？

Question

有几篇关于安卓/iOS WebViews中XSS漏洞的文章。我所说的WebView指的是“真实的”网页视图，而不是SFSafariViewController或Custom。

我理解XSS的主要概念。客户机XSS的一个例子可以是:将某人重定向到一个URL，其中包含一个经过操作的查询字符串。但是，谁会对WebView发起XSS攻击呢？

我自己也能想到一个例子:这个应用程序使用的是深度链接/通用链接。在这个通用链接的帮助下，应用程序将打开，一个意图将加载所请求的页面。当用户单击像https://example.com/openpage/bar?query=<script>alert('XSS');</script>这样的通用链接时，开发人员真的很懒，这可能会导致XSS。但是这是相当容易对付的，因此没有什么好害怕的。

当然，服务器XSS攻击也是可能的，但我指的是客户机XSS。

你能想到其他利用XSS的方法吗？因为如果我提到的是唯一的攻击，我认为XSS攻击WebView的风险很小。

Answer 1

让我们先弄清楚一些事情：

我理解XSS的主要概念；在一个普通的网站上，它可以通过将某人重定向到一个带有操纵查询字符串的URL来实现。

不，XSS是指攻击者可以将代码注入客户端代码，而客户端代码是执行客户端的。注入的代码可以显示覆盖(用于钓鱼目的的登录屏幕)、代表用户执行请求(调用API端点来执行XYZ操作)、将用户重定向到恶意网站等。

交付点可能会有所不同。在URL中使用查询字符串被认为是反射的XSS。但是，例如，您可以通过论坛上的评论(即存储/持久XSS )交付XSS有效负载。有关更多信息，请查看OWASP页面。

上述解释通常是在浏览器的上下文中解释的。现在，WebViews本质上是移动应用程序中的“嵌入式浏览器”。上述攻击方案也适用于WebViews。不过，有一个小小的变化！

首先，在Android和iOS的上下文中，有两种类型的WebViews: WebViews本质上启动新浏览器(SFSafariViewController on iOS，Chrome Custom on Android)和传统WebViews。据我所知，前者比后者更孤立(进程/许可方面)。因此，在非传统的WebViews中访问“应用程序数据”更加困难，因为它需要沙箱转义攻击。作为参考，Android/iOS中的每个应用程序都有自己的用户/组ID。每个应用程序的应用数据只能由应用程序本身访问(沙箱限制)。

其次，可以通过完全禁用WebViews来强化JavaScript。最有趣的XSS有效负载是通过JS交付的。HTML/CSS有效载荷仍然可以重定向或更改网页的布局！

第三，由于WebViews是应用程序的一部分，这意味着他们可以通过file://处理程序访问自己的本地应用程序数据。问题出在哪里？浏览器，因此WebViews不允许跨源请求。这意味着在example.com上服务的网站不能向www.evilwebsite.com或file://提出请求，除非设置了一些CORS标头。不过，有一个优势:有时移动应用程序通过自定义HTTP客户端下载网页，将其保存在本地，然后在WebView中打开保存的网页。现在我们没有交叉原产地问题，也可以访问应用程序数据。然而，这是月球和恒星需要对齐的情况之一：

1. 成功交付XSS有效载荷
2. 易受攻击的网页由移动应用程序使用。
3. 该移动应用程序以编程方式下载该页面，保存该页面并将其显示在WebView (跨原点✅)中。
4. 移动应用WebView配置为允许JavaScript (例如，在Android中，您需要显式地启用JS)。
5. 有趣的(未加密的)数据需要在app数据文件夹(例如共享首选项文件)中可用，这样才能使这种攻击从一开始就可行。