在浏览网页时,你肯定会遇到允许你使用社交媒体帐户登录的网站。此功能一般是使用流行的OAuth 2.0框架构建的。本文主要介绍如何识别和利用OAuth 2.0身份验证机制中发现的一些关键漏洞。
为了更好的理解OAuth,我们假设有如下场景:有一个提供云冲印的网站,该网站可以将用户储存在百度网盘的照片冲印出来。用户为了使用该服务,必须让云冲印网站读取自己存储在百度网盘上的照片。
传统方式需要用户将自己的百度网盘用户名和密码告诉云冲印服务提供者,后者就可以读取用户的照片了。然而这种做法有着严重的缺点:
为了解决以上问题就引入本文的主角OAuth。
OAuth是一种常用的授权框架,使网站和web应用程序能够请求对另一个应用程序上的用户帐户的有限访问。OAuth允许用户在不向请求的应用程序公开其登录凭据的情况下授予此访问权限。这意味着用户可以调整他们想要共享的数据,而不必将其帐户的完全控制权交给第三方。
基本的OAuth过程有两种应用场景:
OAuth 2.0最初是作为一种在应用程序之间共享对特定数据的访问的方式而开发的。它通过定义三个不同方(即客户端应用程序、资源所有者和OAuth服务提供商)之间的一系列交互来工作。
有许多不同的方式可以实现实际的OAuth流程,这些被称为OAuth“流”或“授予类型”,但总的来说,这两种类型都涉及以下阶段:
虽然OAuth最初并非用于此目的,但它也已发展成为一种对用户进行身份验证的手段。例如,你可能熟悉许多网站提供的使用现有社交媒体帐户登录的选项,而不必在相关网站注册。无论何时看到此选项,都很有可能是基于OAuth 2.0构建的。
对于OAuth身份验证机制,基本的OAuth流在很大程度上保持不变;主要区别在于客户端应用程序如何使用它接收的数据。从最终用户的角度来看,OAuth身份验证的结果大致类似于基于SAML的单点登录(SSO)。OAuth身份验证通常实现如下:
/userinfo
端点向资源服务器请求该数据。识别应用程序何时使用OAuth身份验证相对简单。如果你有看到使用其他网站的帐户登录的选项,这强烈表明正在使用OAuth。识别OAuth身份验证的最可靠方法是通过Burp代理流量,并在使用该登录选项时检查相应的HTTP消息。无论使用哪种OAuth授权类型,流的第一个请求都将始终是对 /authorization
端点的请求,其中包含许多专门用于OAuth的查询参数。特别要注意 client_id
、 redirect_uri
和 response_type
参数。例如,授权请求通常如下所示:
GET /authorization?client_id=12345&redirect_uri=https://client-app.com/callback&response_type=token&scope=openid%20profile&state=ae13d489bd00e3c24 HTTP/1.1
Host: oauth-authorization-server.com
正如前面已经提到的,OAuth规范的定义相对松散。对于客户端应用程序的实现来说尤其如此。OAuth流中有很多活动部分,每个授予类型中都有许多可选参数和配置设置,这意味着存在大量错误配置的空间。
由于通过浏览器发送访问令牌会带来危险,因此主要建议单页应用程序使用隐式授予类型。然而,由于其相对简单,它也经常用于经典的客户端-服务器web应用程序。
在这个流中,访问令牌作为URL片段通过用户的浏览器从OAuth服务发送到客户端应用程序。然后,客户端应用程序使用JavaScript访问令牌。问题是,如果应用程序想在用户关闭页面后维护会话,它需要将当前用户数据(通常是用户ID和访问令牌)存储在某个地方。
为了解决这个问题,客户端应用程序通常会在 POST 请求中将这些数据提交给服务器,然后为用户分配一个会话cookie,从而有效地将他们登录。这个请求大致相当于表单提交请求,该请求可能会作为经典的基于密码的登录的一部分发送。然而,在这种情况下,服务器没有任何机密或密码可以与提交的数据进行比较,这意味着它是隐式信任的。
在隐式流中,此 POST 请求通过浏览器暴露给攻击者。因此,如果客户端应用程序没有正确检查访问令牌是否与请求中的其他数据匹配,这种行为可能会导致严重的漏洞。在这种情况下,攻击者可以简单地更改发送到服务器的参数以模拟任何用户。
尽管OAuth流的许多组件都是可选的,但强烈建议使用其中一些组件,除非有重要原因不使用它们。一个这样的例子是 state 参数。
理想情况下, state 参数应该包含一个不可访问的值,例如在用户会话首次启动OAuth流时绑定到该会话的某个值的哈希。然后,该值作为客户端应用程序的CSRF令牌的形式在客户端应用程序和OAuth服务之间来回传递。因此,如果您注意到授权请求没有发送 state 参数,那么从攻击者的角度来看,这是非常有趣的。这可能意味着他们可以在诱骗用户的浏览器完成OAuth流之前自己启动OAuth,类似于传统的CSRF攻击。这可能会产生严重后果,具体取决于客户端应用程序使用OAuth的方式。
考虑一个允许用户使用经典的基于密码的机制登录的网站,或者使用OAuth将其帐户链接到社交媒体档案。在这种情况下,如果应用程序未能使用 state 参数,攻击者可能会将受害者用户在客户端应用程序上的帐户绑定到他们自己的社交媒体帐户,从而劫持受害者用户的帐户。
请注意,如果站点允许用户以独占方式通过OAuth登录,那么 state 参数可能不那么重要。然而,不使用 state 参数仍然可以允许攻击者构建登录CSRF攻击,从而诱使用户登录到攻击者的帐户。
最臭名昭著的基于OAuth的漏洞可能是OAuth服务本身的配置使攻击者能够窃取授权码或访问与其他用户帐户相关的令牌。通过窃取有效的代码或令牌,攻击者可能能够访问受害者的数据。
根据授权类型,通过受害者的浏览器将代码或令牌发送到授权请求的 redirect_uri
参数中指定的 /callback
端点。如果OAuth服务未能正确验证此URI,攻击者可能能够构建类似CSRF的攻击,诱使受害者的浏览器启动OAuth流,该流将代码或令牌发送给攻击者控制的站点。
请注意,使用
state
或nonce
保护并不一定能防止这些攻击,因为攻击者可以从自己的浏览器生成新值。
为了防止OAuth身份验证漏洞,OAuth提供程序和客户端应用程序都必须对密钥输入(尤其是 redirect_uri
参数)进行稳健的验证。OAuth规范中几乎没有内置的保护,因此由开发人员自己来确保OAuth流尽可能安全。
redirect_uris
的白名单。只要可能,请使用严格的逐字节比较来验证任何传入请求中的URI。只允许完全和精确的匹配,而不是使用模式匹配。这可以防止攻击者访问白名单域上的其他页面。state
参数。它的值还应该通过包括一些不可访问的、特定于会话的数据(例如包含会话cookie的哈希)来绑定到用户的会话。这有助于保护用户免受类似CSRF的攻击。这也使攻击者更难使用任何被盗的授权码。client_id
。此外,还应该检查请求的作用域,以确保它与最初授予令牌的作用域相匹配。state
参数,即使它不是强制性的。redirect_uri
参数不仅发送到 /authorization
端点,还发送到 /token
端点。PKCE ( RFC 7636 )
机制可以用于提供针对访问代码拦截或泄漏的额外保护。OpenID Connect id_token
,请确保根据JSON Web签名、JSON Web加密和OpenID规范对其进行了正确验证。<script>
标签从外部域执行。[1] https://portswigger.net/web-security/oauth
[2] https://portswigger.net/research/hidden-oauth-attack-vectors
[3] https://portswigger.net/web-security/oauth/grant-types
[4] https://portswigger.net/web-security/oauth/preventing
更多【运维-「 典型安全漏洞系列 」12.OAuth 2.0身份验证漏洞】相关视频教程:www.yxfzedu.com