认证绕过漏洞是现在 Web 应用中存在的常见缺陷,但它们并不总是那么容易被发现。
随着技术的不断发展,各式各样的平台整合,传统的身份验证方法正在逐渐减少,新的验证方式不仅为用户使用提供了便捷,安全性也上升了一个台阶。虽然像利用单点登录(SSO)这样的方式对旧的用户登录方式进行改进,但是这些技术仍然可能包含关键的漏洞。无论是业务逻辑错误还是其他一些缺陷配置,那么如何发现这些脆弱点呢?
在这种情况下,用户使用有效凭据登录到应用程序,就会创建身份验证令牌进行身份验证。而此身份验证令牌在一段时间后过会过期。就在过期之前的这段时间内,通过 endpoint/refresh/tokenlogin
向服务器发送了一个包含 username
参数的请求,此时返回包中就会出现有效 auth 令牌。
随着平台的多样性,用户需求的不断提高,为了方便用户通过一次性用户身份验证登录多个应用程序和网站,大多数平台都会使用 SSO 系统。但是简单地使用 SSO 并不能自动保护系统: SSO 的配置也必须是安全的。
在这里,一个应用程序使用 Microsoft SSO 系统进行身份验证。当浏览internal.test.com
网址时,浏览器会重定向到单点登录系统:
乍一看,它好像是安全的,但是分析后端请求显示,关于重定向响应内容,程序返回了异常大的内容,内容超过40000字节!
为什么要这么返回?能不能一些其他操作来直接跳转进目的地?
自己就会发现,服务端将用户发送到重定向到 SSO 的过程的内容里泄露了对该请求的内部响应。那么篡改响应试试看。
将302
Find 头更改为200 OK
,并删除整个 Location 头。成功绕过。
当然,可以通过在Burp Suite
中添加 Match & Replace
规则来直接删除并自动更改值,从而实现这一过程的自动化。
像 WordPress、 Drupal 和 Hubspot 这样的CMS也需要进行安全配置,以免出现这样的漏洞。
这里举一个Liferay的例子,也是基于巧合遇到的。这应用有一个无需身份验证即可访问的登录页面。
Liferay使用 portlet 作为应用的sso,它在数字编号中有一个参数 p _ p _ id
。对于Portlet来讲,可以通过将参数更改为值58来访问登录 Portlet。在普通登录页面上,只能访问登录页。但是,通过直接访问 Portlet,可以访问Create Account
功能,然后允许self-registration
功能访问后台内容,无需授权。
尽管 Liferay 以前使用过这个工作流,但它的最新版本使用 Portlet 名称而不是数字 id。不过,也可以通过更改名称来访问其他 Portlet。
JWT 令牌或 JSON Web Token在Web 中应用十分广泛。但是,虽然默认情况下它们有一个安全机制,就是密钥,但是后端服务器的解析机制够不够安全就不一定了。
曾有个网站使用的是JWT,当直接访问时,应用程序将用户重定向到 Microsoft SSO
网页。
但是,一些 JS 文件可以在没有身份验证的情况下访问。测试时发现应用程序使用 JWT 令牌,这些令牌在安全登录后通过Microsoft SSO
系统发送。在后端机制中,存在一个安全错误配置,它没有检查是否是为特定应用程序生成的 JWT 令牌——相反,它接受任何具有有效签名的 JWT 令牌。这里使用微软网站上的一个 JWT 令牌示例:
对内容进行解码:
访问内部接口,成功获取数据:
在此案例中,通过 base64编码的 XML 请求发送到后端验证。在登录机制上,它将用户名、密码分别发送。Scode 参数中的值是密码的md5值。。请求中还有另一个有趣的标志: scode 有一个值为2。
尝试将值赋给1,成功了!于是尝试将Scode进行遍历。通过遍历发现,除了0之外,大多数都是报错的。换个思路,Scode 参数中的值是密码,对密码进行操作,也没有成功,密码值为空值呢?
最终发现,只要提供用户名和空密码就可以绕过认证。
复杂的身份验证机制可能成为新的攻击途径,特别是在容易出现业务逻辑缺陷的应用程序中。由于自动化的扫描器通常无法找到这些漏洞,因此仍然需要手动来找到它们。
本文作者:TideSec
本文为安全脉搏专栏作者发布,转载请注明:https://www.secpulse.com/archives/198619.html