郑重声明：文中技术内容仅限学习交流与安全研究，严禁用于任何非法用途。请遵守相关法律法规。
最近一段时间，我专注于几个高校系统的安全测试，在实战中发现了多个典型漏洞。本文将复盘其中六个案例，涉及支付漏洞、SQL注入、验证码回显、未授权访问等多种常见Web安全漏洞，并最终成功兑换了相应证书。
案例一：支付金额篡改漏洞
在信息收集时，我发现了某大学的一个电费充值小程序。这类功能通常会涉及在线支付，立刻让我联想到是否可能存在支付逻辑漏洞。
首先，我进入小程序，尝试充值10元电费。
接着，使用 Burp Suite 抓包拦截请求，发现关键参数 rechargeMoney。我将该参数的值从 10 修改为 0.019。这里的思路是，如果后端存在四舍五入逻辑，那么 0.019 可能会被处理为 0.02。
修改后放行请求，支付页面显示的实际支付金额为 0.01元。
支付成功后，刷新小程序查看余额，发现账户余额从原来的 7.75元 变成了 7.77元，实际到账了 0.02元。
这意味着，利用 0.019 这个值，实现了 支付0.01元，到账0.02元 的异常逻辑，成功验证了支付金额篡改漏洞，最终被评为高危。
案例二：SQL注入与验证码回显
某天收到邮件提示后，我对一所大学进行了资产收集，在其中一个系统中同时发现了SQL注入和验证码回显漏洞。
SQL注入发现
在系统的“添加设备”功能处进行测试。
抓取请求包后，发现 mac 参数，在其后添加单引号 ' 进行测试，页面直接返回了数据库错误信息。
看到报错信息如此直接，感觉可能存在注入点且没有WAF拦截。于是直接将数据包保存，使用 sqlmap 进行自动化验证，很快便确认了这是一个基于时间的盲注漏洞。
验证码回显漏洞
在同一学校的主公众号菜单中，找到了“充电桩”入口。
点击“立即充值”进入注册页面，输入手机号获取验证码，同时抓包。在服务器返回的响应包中，我发现了 验证码被明文返回。
这直接导致了任意用户注册/登录的风险。我查看了手机收到的真实短信验证码，与响应包中的完全一致，证实了漏洞。
最后，SQL注入提交后确认为重复漏洞，而验证码回显则成功拿下了中危评级。
案例三：未授权删除文件
这个案例来自一所防护比较严格的大学，其大部分系统都部署了WAF，稍有不慎就会触发拦截甚至封禁IP。然而，在一处线上打印系统中，我发现了问题。
该系统支持连接蓝牙打印，用户可以先上传图片。
我上传一张图片后，再尝试删除它，并抓取这个删除请求。
分析数据包，发现删除操作由 dwJobId 和 dwOldJobId 两个参数控制，且值相同。一个关键的疑问产生了：这个ID是否具有全局唯一性？如果没有足够的权限校验，我是否可以操作他人的文件ID？
我将数据包发送到重放器，将 dwJobId 和 dwOldJobId 的值修改为另一个猜测的数字（例如 3352414），然后重放。
服务器返回了相同的成功响应（code:0），这强烈暗示着 删除操作缺乏有效的身份鉴权，可能成功越权删除了其他用户的文件。第二天我复查时，发现该接口已增加了鉴权机制，但我的报告已被认可为中危漏洞。
案例四：两处未授权访问（信息泄露与越权操作）
在另一所大学的边缘资产中，我发现了两个独立的未授权访问漏洞。
未授权一：越权查看地址信息
在公众号的“在线充值”功能中，有一个地址管理页面。
我准备了两个测试账号A和B。用A账号查看地址管理页面并抓包。
分析请求，发现查询地址列表的API中有一个 takeawayPhone 参数，其值为当前用户的手机号。
我将A账号的请求发送到重放器，把 takeawayPhone 参数的值修改为B账号的手机号，成功获取到了B账号的地址信息。更甚者，当我把该参数值置空时，竟然返回了 其他多个用户的地址信息，造成了批量信息泄露。
未授权二：越权提交意见反馈
在同一系统的“意见反馈”功能处，我进行了类似的测试。
使用A账号提交一条反馈并抓包，发现请求体中包含 phone 参数。
我将A账号的数据包重放，并将 phone 参数的值修改为B账号的手机号。
操作完成后，刷新B账号的反馈页面，发现列表中多出了一条本不属于他的反馈记录，这证明我成功实现了 越权替他人提交反馈。
这两处未授权访问被打包提交，最终兑换了中危证书。
案例五：三处越权操作（身份、预约、取消）
这个案例在一次快速响应中完成，在一所大学的边缘资产里发现了三处相关联的越权漏洞。
越权一：修改他人身份信息
在“身份认证”功能处，使用A和B两个账号进行测试。
A账号点击“修改身份信息”并抓包，发现请求参数中包含 name 和 Fphone（疑似手机号）。
我将A账号的请求重放，把 Fphone 参数修改为B账号的手机号。
刷新B账号的页面，发现其身份信息已被错误地修改，验证了越权漏洞。
越权二：替他人预约服务
在“预约乘车”功能中重复上述流程。A账号提交预约后抓包，确认请求受 phone 参数控制且无其他认证。
重放A账号的请求，修改 phone 为B账号手机号。
刷新B账号的预约列表，发现多出了一条非本人操作的预约记录。
越权三：替他人取消预约
既然可以越权预约，那么很可能也存在越权取消。A账号取消自己的预约并抓包，发现由 id 参数控制。
获取B账号的某个预约ID，替换到A账号的请求包中进行重放。
刷新B账号页面，对应的预约果然被成功取消。
这三处逻辑相似的越权漏洞，最终通过了两个，一个因重复被驳回。
案例六：SQL注入与后台弱口令
最后一个案例混合了两种基础但危害不小的漏洞。
SQL注入
在某培训平台小程序中，发现搜索功能。
在搜索框输入 xh 进行查询并抓包。
在请求参数 column 后添加单引号 '，页面返回了SQL语法错误。
进一步测试，在 column 参数后构造 sleep(1)，页面响应出现明显延迟，确认存在基于时间的SQL注入漏洞。
后台弱口令
在同一个学校的采购系统登录界面，尝试使用经典弱口令 admin/admin 进行登录。
尝试后，竟然直接成功进入了系统后台。
这个案例再次证明了，即使存在复杂的漏洞，基础的弱口令问题依然广泛存在且危害巨大。最终，弱口令漏洞成功通过，SQL注入因重复被驳回。
总结与反思
回顾这六个案例，涉及的漏洞类型在当前的Web应用中仍然十分常见：
- 业务逻辑漏洞：如案例一的支付金额篡改，需要深入理解业务流程。
- 注入类漏洞：SQL注入依然频发，自动化工具（如sqlmap）在确认漏洞时非常高效。
- 权限校验缺失：未授权访问（增删改查）是重灾区，关键在于识别出控制数据归属的关键参数（如ID、手机号）。
- 敏感信息泄露：验证码、用户数据等在响应中直接回显。
- 弱口令：属于最原始但往往最有效的攻击入口。
在进行安全测试，尤其是 渗透测试 时，保持耐心和细致的观察力至关重要。每一个参数、每一次交互都可能是突破点。同时，所有测试必须在合法授权范围内进行，并将发现的问题及时提交给相关方修复。
这些实战经历不仅让我收获了证书，更重要的是积累了宝贵的经验。安全之路道阻且长，需要持续学习、思考和沉淀。希望这篇复盘能对同样在 Web安全 领域学习和探索的朋友有所启发。也欢迎大家在 云栈社区 交流更多技术心得。
发表于 1 小时前
|
查看: 3|
回复: 0
