五种不一样的身份验证绕过技术

五种不一样的身份验证绕过技术

声明：文章中涉及的程序(方法)可能带有攻击性，仅供安全研究与教学之用，读者将其信息做其他用途，由用户承担全部法律及连带责任，文章作者不承担任何法律及连带责任。

前言

身份验证绕过是现代web应用程序中普遍存在的问题，但这类漏洞不容易发现。

尽管单点登录(SSO)等工具通常是对旧的登录用户方式的改进，但仍然可能包含严重的漏洞。无论是业务逻辑漏洞还是其他软件缺陷，都需要敏锐的眼光来审视。

本文将主要介绍五种身份验证绕过技术。

示例1 -刷新令牌接口的配置错误

在这个示例中,用户一旦使用有效凭证登录到应用程序,它就会创建一个在应用程序其他地方使用的承载身份验证令牌。

该认证令牌在一段时间后过期。就在过期之前,应用程序从接口 /refresh/tokenlogin向后端服务器发送了一个请求，该请求在头部和HTTP主体部分的用户名参数中包含有效的身份验证令牌。

进一步的测试表明，删除请求上的Authorization头并更改HTTP主体上的用户名参数,为提供的用户名创建一个新的有效令牌。利用此漏洞，拥有匿名配置文件的攻击者可以通过提供用户名为任何用户生成身份验证令牌。

示例2 - SSO配置不正确

大多数应用程序都使用SSO系统,因为SSO系统更容易安全管理;但是简单地使用SSO并不能保护系统:SSO的配置也必须得到保护。

一个应用程序使用Microsoft SSO系统进行身份验证。当访问internal.redacted.com 时，web浏览器会重定向到单点登录系统:

看上去是安全的,但对后端请求的分析显示，应用程序在重定向响应上返回了异常大的内容长度(超过40,000字节!这里返回了46875字节)

这是配置错误。在将用户发送到SSO的重定向时，应用程序向每个请求泄露了其内部响应。因此，可以篡改响应，将302 Found头更改为200 OK，并删除整个Location头，从而获得对整个应用程序的访问

主要做了两件事:

• 将302的响应改为200
• 删除整个Location头

此外，可以通过在Burp Suite中添加Match & Replace规则来自动删除标题并自动更改值，从而实现这个过程的自动化。

示例3 -基于CMS的权限问题

内容管理系统(CMS)，如WordPress、Drupal和Hubspot也需要进行安全配置，以免它们在您的组织中引入漏洞。

在一个内部应用程序中使用了一个流行的CMS平台Liferay。该应用程序只有一个不需要身份验证就可以访问的登录页面。

对于那些不熟悉Liferay的人来说，CMS使用portlet作为应用程序工作流，它的参数是p_p_id。对于该应用程序，可以通过将参数更改为值58来访问登录portlet。

虽然Liferay以前使用过这个工作流，但它的最新版本使用portlet名称而不是id。不过，也可以通过更改名称来访问其他portlet。

示例4 -JWT令牌的使用

JWT令牌，或者称为 JSON web令牌，在新的web应用程序中很流行。虽然它们默认具有安全机制，后端服务器配置也应该是安全的。

我的一项任务是在他们的内部应用程序中使用SSO身份验证。当直接访问时，应用程序将用户重定向到Microsoft SSO web页面。到目前为止，一切顺利。

但是一些JS文件不需要身份验证就可以访问;

测试显示，该应用程序使用了安全登录后通过Microsoft SSO系统发送的JWT令牌。在后端机制上，存在一个安全错误配置，即不检查是否为特定的应用程序生成了JWT令牌,相反，它接受任何具有有效签名的JWT令牌。因此，使用来自微软网站的JWT令牌示例:

通用值

有可能访问内部接口，泄露公司数据。

例5 -将认证类型修改为Null

在这个实例中，应用程序通过base64编码的XML请求发送 post请求。在登录机制中，它将用户名作为参数别名，将密码作为scode发送。scode参数内的值是hash过的, 快速分析表明它使用了所提供的密码值的md5值。请求中还有一个有趣的迹象：scode有一个类型为2的属性。

我试着把值赋给1，这将接受明文密码。发现起作用了!

所以，在明文值中使用暴力破解是可能的。这表明我在正确的方向

那么，把它赋值为空值呢？或者其他值，如-1、0或999999999？除了0值之外，大部分都返回了错误代码。我用0这个属性试了几次，但都没有成功，直到我把密码值作为一个空值发送。

我意识到，只要提供用户名和空密码，就可以访问任何帐户。这是一只相当大的漏洞。