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令牌在传输过程中的安全。

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

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

 

posted on 2023-01-30 17:00  花阴偷移  阅读(60)  评论(0编辑  收藏  举报

导航