vAPI靶场

Att@ckxu2025-05-272025-05-29

前期准备工作

安装

git clone https://github.com/roottusk/vapi.git
cd vapi/
docker-compose up -d

安装完成后访问http://IP:80/vapi/ 即可访问 vAPI

postman配置

下载的/vapi/postman路径下有两个文件

vAPI.postman_collection.json
vAPI_ENV.postman_environment.json

将这两个文件一起导入postman

设置host

之后要再修改值

或者直接在环境中添加变量

在之后直接引用这个环境

通关过程

API1 - 失效的对象级授权

Broken Object Level Authorization
损坏的对象级授权

失效的对象级别授权指未对通过身份验证的用户实施恰当的访问控制。攻击者可以利用这些缺陷访问未经授权的功能或数据（直接的对象引用或限制的URL）。例如：访问其他用户的帐户、查看敏感文件、修改其他用户的数据、更改访问权限等。

简单的API权限校验缺失导致的越权

接口

Create User

传入字段值

{
    "username": "123",
    "name": "123",
    "course": "123",
    "password": "123"
}

Get User

成功获取

Update User

传入字段值

{
    "username":"123",
    "name":"456",
    "course":"123",
    "password":"123"
}

成功修改用户信息

再使用GetUser接口检验一下

漏洞利用

我们发现，当我们CreateUser时，会自动生成一个Authorization-Token请求头，这个值就是一个合法的Token

当我们将Token删除时，页面返回失败

当我们将Token值更改时，页面同样返回失败

说明该接口是根据Token字段来判断是否处于登录状态

而当我们修改api1_id参数值为6时，返回了其他用户的信息，说明接口只判断了用户名和密码是否匹配，而没有判断id与用户名是否匹配

因此通过遍历id值可以得到所有用户信息

id为1时，即得到flag

同时还可以访问UpdateUser接口进行修改任意用户信息

总结

漏洞是由于创建CreateUser时生成了Token，在之后进行GetUser和UpdateUser时只检验了Token是否合法，而没有检验Token和id是否匹配，从而导致了越权

修复建议

对于进行其他操作时，要通过接收Token对数据库中存储的用户id进行校验

API2 - 失效的用户认证

API 通常不会正确验证用户身份。这个问题基本上围绕认证方面，如弱口令、默认口令、明文存储、弱加密、密码爆破、GET方式传输令牌和密码等。

接口

User Login

需要输入email和password

Get Detail

获取用户信息，是通过Token来获取用户信息

漏洞利用

这是一个邮箱和密码的字典

尝试postman转发到burp去爆破

postman代理配置

burp代理配置

爆破配置

爆破时关闭URL编码

最后获得的正确的邮箱密码

harber.leif@beatty.info
kU-wDE7r

hauck.aletha@yahoo.com
kU-wDE7r

savanna48@ortiz.com
zTyBwV/9

使用Get Details接口，可以获得所有用户的数据

总结

当我们使用Get Details接口时，未授权成功返回了所有数据，并没有对Token进行校验

修复建议

校验Token并且只匹配并返回Token所对应的用户的数据

添加登陆验证码
限制账号、IP登陆次数

API3 - 过度的数据暴露

API 可能会返回大量不必要的数据作为响应，并在客户端对其进行过滤以仅显示所需的数据。攻击者可以通过使用 Burpsuite，并访问响应中返回的过多数据。

接口

Create User

创建用户

{
    "username":"123",
    "password":"123",
    "name":"123"
}

漏洞利用

安装资源包中的apk

需要高版本安卓，我这里用安卓7.1无法安装，9.0可以安装

填写url

http://192.168.174.130/vapi

点击save，填写刚刚注册的用户信息

观察数据包发现，有一个comment数据包泄露了敏感信息

手机前端不会显示暴露的信息，但在数据包中会有显示

总结

数据交互时由于配置不当，可能会在一些数据包中泄露了敏感信息

API4 - 资源缺失 & 速率限制

接口

Mobile Login

手机号登录，通过手机号登录，输入手机号，提示已将4位数的OTP发送到手机。

OTP：One Time Password，又称一次性口令、一次性密码、动态密码、单次有效密码。

Verify OTP

对传入的4位数字的OTP进行验证

Get Details

验证通过，获取用户信息

漏洞利用

后台没有对访问速率与错误次数进行限制，可暴力破解4位OTP

burp爆破

爆破成功的key就是Get Details接口的Token值

FZvjaFlMgUfnpFJDhKx-92xeXx_sCr7Y

总结

由于没有对OTP爆破进行限制，导致OTP可爆破

修复建议

限制OTP错误次数。
增强OTP复杂度。

API5 - 失效的功能级授权

有些时候，普通用户可以调整请求的方法，检索到他们不应该检索到的信息，或执行他不应该访问的操作。

此题参考垂直越权漏洞。

接口

Create User

创建用户

{
    "username":"123",
    "password":"123",
    "name":"123",
    "address":"ABC",
    "mobileno":"888888888"
}

Get User

获取用户

漏洞利用

创建用户之后获取用户，在获取用户的接口处尝试将id改为1，说明进行了Token和id的校验

而我们访问users接口，可以看到管理员信息

总结

这里虽然对id和Token进行了校验，但是对于Users接口并没有做鉴权，导致普通用户可以访问该接口来查看全部用户信息

修复建议

对于users访问时进行鉴权，校验Token，非管理员Token无法访问该接口

API6 - 批量分配

有时候，API 会信任从客户端接收到的用户输入，并在不经过过滤的情况下，将其直接保存在数据库中。为了获得对受限功能的未经授权的访问，攻击者可以通过 API 文档、有根据的猜测或 HTTP 回复识别额外的对象，并将它们包含在请求中。例如，攻击者可能会将 &admin=true 参数附加到用户的注册并获得管理员权限。

接口

Create User

创建用户

{
    "name":"123",
    "username":"123",
    "password":"123"
}

Get User

获取用户信息

漏洞利用

这里创建用户之后，获取用户信息，credit字段值为0，积分为0

想要获取积分，尝试在创建用户时手动添加积分字段并且赋值

{
    "name":"1234",
    "username":"1234",
    "password":"1234",
    "credit":"1000"
}

在点击Get User接口查看用户信息，发现积分成功被添加上，同时得到flag

这里如果刚开始创建的没有积分字段的用户123，而再次创建一个添加积分字段的123，如果这两个用户的用户名和密码都相同时，不会在新创建的用户信息中看到添加成功积分，因为这里的Token是基于用户名和密码来生成的，而创建两个用户名和密码都相同的用户，他们生成的Token也一致，虽然的确是两个不同的用户id，此时基于Token查看新创建的用户信息，查到的仍然是之前创建的那个用户123的信息，因此并没有成功添加积分字段

因此，Token严格来说应该基于用户id和用户名密码来生成

总结

在创建用户时，我们可以基于查看用户信息所返回的字段来尝试手动添加相应字段

API7 - 安全性配置不当

安全配置不当包括默认或不完整的配置、配置不当的HTTP头、不必要的HTTP请求方法、跨源资源共享(CORS)配置不当、以及包含敏感数据的详细的报错消息等问题。攻击者可能会利用这些不当的配置来获得未经授权访问或破坏安全机制。

此题涉及CORS配置不当

跨域资源共享（CORS）是一种浏览器机制，可实现对位于给定域外部的资源的受控访问。它扩展了同源策略（SOP）并增加了灵活性。但是，如果网站的CORS策略配置和实施不当，它也可能带来用户敏感数据被窃取、基于跨域的攻击等风险。

关于CORS漏洞https://blog.csdn.net/weixin_46622976/article/details/128452494

接口

Create User

创建用户

{
    "username":"123",
    "password":"123"
}

User Login

用户登录

根据Token来校验登录

并且生成Cookie

Get Key

获取密钥

这个接口只能够在登录后使用

未登录时使用：

User Logout

用户退出

漏洞利用

漏洞就在获取密钥的接口处

在登录状态后的获取密钥的接口，请求时添加请求头Origin，值可以为任意，仍然可以得到正确的响应，说明存在CORS漏洞

同时响应头

总结

这里涉及到CORS的防御

Access-Control-Allow-Origin中指定的来源只能是受信任的站点，避免使用Access-Control-Allow-Origin: *，避免使用Access-Control-Allow-Origin: null，否则攻击者可以伪造来源请求实现跨域资源窃取。
严格校验“Origin”值，校验的正则表达式一定要编写完善，避免出现绕过的情况。
减少“Access-Control-Allow-Methods”所允许的请求方法。
除了正确配置CORS之外，Web服务器还应继续对敏感数据进行保护，例如身份验证和会话管理等