OAuth 2.0 安全漏洞 (客户端，资源拥有者，授权服务器，令牌)3

一. 客户端漏洞

　　 1.针对客户端的CSRF攻击

　　　　在上一篇中说过，授权码许可和隐式许可类型中都提到了推荐使用state参数，state参数防止CSRF，CSRF是互联网上最常见的攻击之一，攻击者会将恶意的javascriprt代码嵌入到网页中，在用户不知的情况下向某个特定任务的URL发送请求。

　　　　比如一个支持授权码许可类型的OAuth客户端，它从授权服务器回调端点(Redirect)上收到code参数后，会使用这个收到的授权码去换取令牌，为了实施攻击，攻击者可以简单地发起一个OAuth流程，从目录授权服务器上获取授权码之后，就暂停OAuth流程，再设法让受害用户的客户端使用攻击者的授权码，后面只需他在网站上构建一个恶意页面即可，用如下代码：

<img src="https://oauthclient.com/callback?code=iiekdxio"

　　　　OAuth客户端的应对措施是生成一个难以猜测的state参数，并在首次向授权服务器发送请求时将其一同传递，OAuth规范要求授权服务器将此参数原样返回到重定向URL。客户端会检查state参数的值，如果该参数缺失或其值与最初传递至授权服务器的值不一致，则客户端可以终止授权流程并提示错误。

　　2.客户端凭据失窃

　　　　像隐式许可类型，客户端一般在纯Javascript应用，由于代码运行在浏览器中，因此也就不具备保密client_secret的能力，另一种情况是传统的服务端应用，可以使用授权码许可类型，能够将client_secret安全在存储在服务器上。

　　　　其中并不推荐原生应用中使用隐式许可类型，虽然client_secret以某种形式隐藏在编译后的代码中，但也不能将其视为保密信息。

　　3.客户端重定向URL注册

　　　　在授权服务器上创建新的OAuth客户端时，redirect_uri的设定极其重要，特别是要让redirect_uri尽可能地具体，下面是示例：

#一定要注册完整的URL
https://oauthclient.com/oauth/oauthprovider/callback
#不要只注册域
https://oauthclient.com
#也不要只注册一部分路径
https://oauthclient.com/oauth

　　　　授权服务器应该采用的唯一安全可靠的校验方法是精确匹配，任何其他的替代方案（包括正则匹配或者允许注册redirect_uri的子目录）都是次优方案，甚至会带来危险。客户端重定向URL注册可参考：asp.net core系列 56 IS4使用OpenID Connect添加用户认证

　　4.令牌失窃

　　　　攻击者在OAuth系统上打注意，他最终目标是窃取访问令牌，有了访问令牌，攻击者就可以操作资源服务器上的接口数据。客户端使用bearer令牌时，其中一种方法是可能通过url中带access_token参数，这种方法看起来简洁，但存在缺点，可能成为攻击者目标，推荐使用标准的Authoriaztion头部就不会有问题。　

　　　

二.常见的受保护资源漏洞

　　1.受保护的端点，因指定Content-Type为application/json类型，这样防止js脚本注入攻击。

　　2.如果资源端点要支持隐式许可类型，则要使用CORS(跨域共享资源)。

 

三.常见的授权服务器漏洞

　　授权服务器由面向用户的网站(前端信道)和面向机器的API(后端信道)两部分构成，包括使用服务器安全日志，使用具有有效证书的TLS，安全的宿主环境，正确的操作系统账户权限控制等。　它的责任重大，因为它是整个OAuth安全生态系统的关键。注意事项包括：

　　1）授权码使用一次之后将其销毁

　　2）授权服务器应用采用精确匹配的重定向URL校验算法，这是唯一安全的方法

　　3）留意在进行错误提示的过程中，信息有可能通过URL片段或者Referrer头部遭泄露。

 

四.如何保护bearer令牌　

 　　不要在不安全的信道上以明文形式传递访问令牌。根据OAuth核心规范，必须使用端到端的加密连接传输访问令牌，比如使用SSL/TLS。如果不使用TLS则无法保证OAuth bearer令牌在传输过程中的安全。

　　在授权服务器上，降低单个 访问令牌被泄露所造成的风险，缩短访问令牌的生命周期是很好的方法。

　　在受保护资源上，尽量缩小令牌的权限范围。