# 08 | 实践OAuth 2.0时，使用不当可能会导致哪些安全漏洞？
你好，我是王新栋。
当知道这一讲的主题是OAuth 2.0的安全漏洞时，你可能要问了：“OAuth 2.0 不是一种安全协议吗，不是保护Web API的吗？为啥OAuth 2.0自己还有安全的问题了呢？”
首先，OAuth 2.0 的确是一种安全协议。这没啥问题，但是它有很多使用规范，比如授权码是一个临时凭据只能被使用一次，要对重定向URI做校验等。那么，如果使用的时候你没有按照这样的规范来实施，就会有安全漏洞了。
其次，OAuth 2.0既然是“生长”在互联网这个大环境中，就一样会面对互联网上常见安全风险的攻击，比如跨站请求伪造（Cross-site request forgery，CSRF）、跨站脚本攻击（Cross Site Scripting，XSS）。
最后，除了这些常见攻击类型外，OAuth 2.0 自身也有可被利用的安全漏洞，比如授权码失窃、重定向URI伪造。
所以，我们**在实践OAuth 2.0的过程中，安全问题一定是重中之重**。接下来，我挑选了5个典型的安全问题，其中CSRF、XSS、水平越权这三种是互联网环境下常见的安全风险，授权码失窃和重定向URI被篡改属于OAuth2.0“专属”的安全风险。接下来，我就和你一起看看这些安全风险的由来，以及如何应对吧。
## CSRF攻击
对于CSRF的定义，《OAuth 2 in Action》这本书里的解释，是我目前看到的最为贴切的解释：恶意软件让浏览器向**已完成用户身份认证**的网站发起请求，并**执行有害的操作**，就是跨站请求伪造攻击。
它是互联网上最为常见的攻击之一。我们在实践OAuth2.0的过程，其实就是在构建一次互联网的应用。因此，OAuth 2.0同样也会面临这个攻击。接下来，我通过一个案例和你说明这个攻击类型。
有一个软件 A，我们让它来扮演攻击者，让它的开发者按照正常的流程使用极客时间。当该攻击者授权后，拿到授权码的值 codeA之后，“立即按下了暂停键”，不继续往下走了。那它想干啥呢，我们继续往下看。
这时，**有一个第三方软件B，比如咱们的Web版极客时间，来扮演受害者吧。**当然最终的受害者是用户，这里是用Web版极客时间来作为被软件A攻击的对象**。**
极客时间用于接收授权码的回调地址为 `https://time.geekbang.org/callback`。有一个用户G已经在极客时间的平台登录，且对极客时间进行了授权，也就是用户G已经在极客时间平台上有登录态了。
如果此时攻击者软件A，在自己的网站上构造了一个恶意页面：
```
```
如果这个时候用户G被攻击者软件A诱导而点击了这个恶意页面，那结果就是，极客时间使用codeA值去继续OAuth 2.0的流程了。这其实就走完了一个CSRF攻击的过程，如下图所示：
如果我们将OAuth 2.0用于了身份认证，那么就会造成严重的后果，因为用户G使用的极客时间的**授权上下文环境**跟攻击者软件A的**授权上下文环境**绑定在了一起。为了解释两个上下文环境绑定在一起可能带来的危害，我们还是拿极客时间来举例。
假如，极客时间提供了用户账号和微信账号做绑定的功能，也就是说用户先用自己的极客时间的账号登录，然后可以绑定微信账号，以便后续可以使用微信账号来登录。在绑定微信账号的时候，微信会咨询你是否给极客时间授权，让它获取你在微信上的个人信息。这时候，就需要用到OAuth 2.0的授权流程。
如果攻击者软件A，通过自己的极客时间账号事先做了上面的绑定操作，也就是说攻击者已经可以使用自己的微信账号来登录极客时间了。那有一天，软件A想要“搞事情”了，便在发起了一个授权请求后构造了一个攻击页面，里面包含的模拟代码正如我在上面描述的那样，来诱导用户G点击。
而用户G已经用极客时间的账号登录了极客时间，此时正要去做跟微信账号的绑定。如果这个时候他刚好点击了攻击者A“种下”的这个恶意页面，那么后面换取授权的访问令牌access\_token，以及通过accces\_token获取的信息就都是攻击者软件A的了。
这就相当于，用户G将自己的极客时间的账号跟攻击者软件A的微信账号绑定在了一起。这样一来，后续攻击者软件A就能够通过自己的微信账号，来登录用户G的极客时间了。这个后果可想而知。
那如何避免这种攻击呢？方法也很简单，实际上OAuth 2.0中也有这样的建议，就是**使用state参数**，它是一个随机值的参数。
还是以上面的场景为例，当极客时间请求授权码的时候附带一个自己生成state参数值，同时授权服务也要按照规则将这个随机的state值跟授权码code一起返回给极客时间。这样，当极客时间接收到授权码的时候，就要在极客时间这一侧做一个state参数值的比对校验，如果相同就继续流程，否则直接拒绝后续流程。
在这样的情况下，软件A要想再发起CSRF攻击，就必须另外构造一个state值，而这个state没那么容易被伪造。这本就是一个随机的数值，而且在生成时就遵从了被“猜中”的概率要极小的建议。比如，生成一个6位字母和数字的组合值，显然要比生成一个6位纯数字值被“猜中”的概率要小。所以，软件B通过使用state参数，就实现了一个基本的防跨站请求伪造保护。
我们再来总结下，这个攻击过程本质上就是，软件A（攻击者）用自己的授权码codeA的值，通过CSRF攻击，“替换”了软件B的授权码的值。
接下来，我再给你看一种互联网常见的安全攻击类型，也就是XSS攻击。
## XSS攻击
XSS攻击的主要手段是将恶意脚本注入到请求的输入中，攻击者可以通过注入的恶意脚本来进行攻击行为，比如搜集数据等。截止到2020年6月23日，在OWASP（一个开源的Web应用安全项目）上查看安全漏洞排名的话，它依然在[TOP10](https://owasp.org/www-project-top-ten/)榜单上面，可谓“大名鼎鼎”。
网络上有很多关于XSS的介绍了，我推荐你看看[《XSS攻击原理分析与防御技术》](https://segmentfault.com/a/1190000013315450)这篇文章，它很清晰地分析了XSS的原理以及防御方法。今天，我们主要看看它是怎么在OAuth 2.0的流程中“发挥”的。
当请求抵达受保护资源服务时，系统需要做校验，比如第三方软件身份合法性校验、访问令牌access\_token的校验，如果这些信息都不能被校验通过，受保护资源服务就会返回错误的信息。
大多数情况下，受保护资源都是把输入的内容，比如app\_id invalid、access\_token invalid ，再回显一遍，这时就会被XSS攻击者捕获到机会。试想下，如果攻击者传入了一些恶意的、搜集用户数据的JavaScript 代码，受保护资源服务直接原路返回到用户的页面上，那么当用户触发到这些代码的时候就会遭受到攻击。
因此，受保护资源服务就需要对这类XSS漏洞做修复，而具体的修复方法跟其它网站防御XSS类似，最简单的方法就是**对此类非法信息做转义过滤**，比如对包含`