前言
在 Web 渗透测试中，业务逻辑类漏洞往往容易被开发忽视，水平越权属于高频出现的中危业务漏洞。本次测试对象为某期刊投稿网站，系统存在稿件操作接口未校验请求用户与稿件归属关系，攻击者可篡改请求 ID，直接对其他用户的投稿执行撤稿操作，影响业务数据真实性。本文完整记录本次漏洞复现全过程。
漏洞 / 测试基础信息
| 项目 | 详情 |
|---|---|
| 漏洞类型 | 水平越权（中危） |
| 资产环境 | 互联网公网资产 |
| 测试所需账号 | 需要注册 2 个普通投稿账号 |
| 漏洞现象 | 篡改请求中的稿件 ID，可越权撤销其他用户的投稿稿件，后台可收到越权产生的撤稿请求 |
| 漏洞原理 | 后端仅通过前端传入的稿件 |
漏洞思路梳理
- 业务场景：期刊投稿系统，每个账号管理自己提交的稿件，正常逻辑只允许操作本人稿件。
- 观察功能点：撤稿功能请求携带稿件 id 参数，id 由前端可控。
- 猜想：后端是否只根据 id 处理业务，没有校验账号‑稿件的所属绑定关系。
- 验证思路：两个不同账号各自投稿，抓包修改请求里的稿件 id，使用 A 账号的会话，传入 B 账号的稿件 id，观察是否可以成功执行撤稿。
- 结果：接口未做权限校验，成功越权操作他人稿件。
实操 / 测试流程
测试前置：注册 2 个独立账号，两个账号分别提交一篇测试稿件。
- 使用账号 A 登录系统，进入已投稿件页面，页面存在撤稿功能按钮，点击撤稿，观察 URL / 请求数据包，发现请求参数携带稿件
id字段，该字段标识待操作的稿件。 - 使用 Burp Suite 抓取账号 A 执行撤稿操作的完整流量包。
- 修改抓包数据包，将数据包内的稿件 id，替换为账号 B 提交的稿件 id。
- 将修改之后的数据包发送到服务端。
- 观察页面返回结果：原本是账号 A 的撤稿界面，页面内容切换为账号 B 的稿件信息，成功触发针对账号 B 稿件的撤稿流程。
- 后台收到了越权操作产生的撤稿信息，完成越权漏洞验证。
漏洞总结
核心问题
业务接口执行撤稿逻辑时，仅信任前端传入的稿件 ID 参数，缺少服务端权限校验，没有校验当前登录用户是否拥有该稿件的操作权限。攻击者仅需要普通用户账号，修改请求参数 id，就可以访问、操作其他同级别用户的业务数据。
漏洞危害
- 恶意用户可以越权撤销其他作者的投稿稿件，干扰期刊正常投稿业务流程。
- 可以篡改、查看其他用户稿件信息，造成业务数据被非法篡改。
- 造成期刊稿件数据混乱，对平台公信力造成损害。
修复建议
- 服务端强制校验权限（最重要）：执行稿件查询、撤稿、编辑等所有稿件相关接口，后端必须根据 session/token 拿到当前登录用户身份，在数据库校验：
当前登录用户ID == 稿件所属作者ID，校验不通过直接拒绝请求返回无权限，不能只依赖前端传入的稿件 id 做业务处理。 - 禁止完全信任前端可控参数，所有业务对象 ID，后端必须做权限鉴权，不能直接拿来执行数据库操作。
- 对业务逻辑接口增加安全测试，针对越权做专项测试用例，覆盖增删改查各类业务动作。
- 日志记录：记录稿件操作行为，记录操作人、稿件 id，方便出现异常行为时溯源审计。
测试心得
- 水平越权多出现在业务系统，重点关注业务功能：编辑、删除、撤回、查询等，观察 URL、请求 body 中是否存在 id、articleId 等对象标识参数。
- 越权漏洞属于业务逻辑漏洞，waf 很难拦截，更多需要代码层面、业务层做校验。
- 复现越权漏洞，必备两个权限相同的测试账号，一个账号抓包，替换另一个账号业务对象 ID 进行验证。
安全声明
⚠️本文中所有内容仅为安全研究、渗透测试学习交流使用，禁止未经授权对非自有资产进行任何渗透、漏洞测试行为，未经授权测试属于违法行为。所有测试操作应当在获得书面授权的测试环境中开展。
