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