BP靶场之身份认证漏洞

身份验证漏洞

从概念上讲,身份验证漏洞很容易理解。然而,由于身份验证与安全之间的明确关系,它们通常至关重要。身份验证漏洞可以让攻击者访问敏感数据和功能。它们还暴露了额外的攻击面,以便进一步利用。因此,了解如何识别和利用身份验证漏洞以及如何绕过常见的保护措施非常重要。

1
2
3

认证和授权的区别：
	身份验证是验证用户是否是他们声称是谁的过程。
	授权涉及验证用户是否被允许做某事。

Lab: Username enumeration via different responses

进行一个爆破

用户名和密码的列表已经给出

一开始的思路是，集群炸弹直接梭哈

但是wp是狙击手去遍历，这里我就直接梭哈了

筛选长度这个就是密码了

直接登录进去就欧克了

绕过双因素身份验证

有时,双因素身份验证的实现存在缺陷,以至于可以完全绕过它。

如果用户首先被提示输入密码,然后提示在单独的页面上输入验证码,则用户在输入验证码之前实际上处于“登录”状态。在这种情况下,值得测试的是,在完成第一个身份验证步骤后,是否可以直接跳到“仅登录”页面。偶尔,你会发现一个网站实际上并没有在加载页面之前检查你是否完成了第二步。

Lab: 2FA simple bypass

先用题目给的账号登录进去然后会自动发送邮件这个时候你去退出/返回页面的时候再进去账户就已经是登录的状态了也就是说验证码其实没有用到只是发送了

那么依据这个情况可以直接访问carlos的账户登录然后直接进入账户页面即可

SSRF

服务器端请求伪造是一个Web安全漏洞,允许攻击者导致服务器端应用程序向意外位置发出请求。

在典型的 SSRF 攻击中,攻击者可能导致服务器连接到组织基础架构内的内部服务。在其他情况下,它们可能能够强制服务器连接到任意外部系统。这可能会泄露敏感数据,例如授权凭据。

对服务器的 SSRF 攻击

在针对服务器的 SSRF 攻击中,攻击者通过其环回网络接口,使应用程序向托管应用程序的服务器发出 HTTP 请求。这通常涉及提供一个包含主机名的URL,例如127.0.0.1(指向环回适配器的保留 IP 地址)或localhost(同一适配器常用的名称)。

例如,想象一个购物应用程序,让用户查看特定商店中是否有库存的物品。要提供库存信息,应用程序必须查询各种后端 REST API。它通过前端HTTP请求将URL传递给相关的后端API端点来做到这一点。当用户查看某个项目的库存状态时,其浏览器会提出以下请求:

POST /product/stock HTTP/1.0
Content-Type: application/x-www-form-urlencoded
Content-Length: 118

stockApi=http://stock.weliketoshop.net:8080/product/stock/check%3Fp
roductId%3D6%26storeId%3D1

这导致服务器向指定的URL发出请求,检索库存状态,并将其返回给用户。

在本例中,攻击者可以修改请求以指定服务器本地的 URL:

POST /product/stock HTTP/1.0
Content-Type: application/x-www-form-urlencoded
Content-Length: 118

stockApi=http://localhost/admin

服务器获取内容/adminURL 并返回给用户。

攻击者可以访问/adminURL,但管理功能通常只对经过身份验证的用户访问。这意味着攻击者不会看到任何感兴趣的东西。但是,如果请求/adminURL来自本地机器,正常的访问控制被绕过。应用程序授予对管理功能的完全访问权限,因为该请求似乎来自受信任的位置。

Lab: Basic SSRF against the local server

实验室商品有一个查看库存有一个api接口

是通过这一个地方去进行一个调用

正常的管理员页面是/admin

我们是访问不到的

![](http://images.lwwww.top/images/20250524132944426.png

然后修改一下api去调用的传参访问 http://localhost/admin

然后我们访问到这个页面看一下找到删除的链接

/admin/delete?username=carlos

然后就很显而易见了直接整一个payload就是

解决

Lab: Basic SSRF against another back-end system

这个和前面一样只不过不是固定的localhost和127.0.0.1了变成内网的某个地址了多了一步探测内网的步骤

剩下的没啥好记录的了-~~还是懒，嗯就先到这了~~