wed渗透

去年秋天，一个做安全测试的朋友给我看了他手机里的一张截图。某家连锁酒店的Wi-Fi登录页面，URL里明晃晃挂着一个参数：?redirect=http://booking.xxx.com/room/1024。他把1024改成了1025，页面直接跳进了另一个用户的订单详情——姓名、手机号、身份证后六位，全在。

这不是什么高深漏洞。就是一个没做权限校验的接口，配上可遍历的ID。开发大概觉得"没人会去改这个数字"。但渗透测试的本质就在这儿：专门去改那些"没人会改"的东西。

WED是什么，先把概念理清楚

WED不是某个工具的名字，它是Web Extra Dimension的缩写，圈内人用来指代Web应用渗透中那些"非标准入口"——不靠SQL注入、不靠XSS弹窗，而是从业务逻辑、参数信任链、前端与后端的信息差里找突破口。

常规扫描器扫不到这些东西。AWVS和Burp的主动扫描能发现注入点和已知CVE，但一个"把VIP等级从1改成3就能白嫖会员权益"的漏洞，扫描器永远报不出来。它需要人去看、去猜、去试。

一个参数引发的连锁反应

回到那个酒店案例。redirect参数本身只做了跳转，但后端在跳转前会校验当前session有没有权限访问目标订单。问题出在校验逻辑写在了前端——JS里判断了一下用户ID是否匹配，匹配就放行。抓包改包，JS那层形同虚设。

这种"前端校验、后端裸奔"的模式太常见了。我见过一个电商后台，删除商品的接口只靠前端按钮的disabled属性控制权限，用curl直接发DELETE请求，库存商品照样被删。开发觉得"按钮都灰了，用户点不了"，但攻击者根本不点按钮。

业务逻辑漏洞比技术漏洞更致命

技术漏洞有补丁可打，业务逻辑漏洞往往要改代码架构。某次我测试一个优惠券系统，发现优惠券的折扣金额是前端传过来的。原价100，前端传discount=99，后端直接按1块钱结算。没有签名校验，没有服务端重算。这种漏洞扫描器不会报，因为从HTTP响应看一切正常，200 OK，数据也"对"。

还有一种更隐蔽的：并发竞争。一个账户余额100，同时发20个提现请求，每个提现100。如果后端没加锁，数据库里余额可能变成-1900。这种漏洞在代码审计时都容易被忽略，只有实际跑并发才能触发。

工具是辅助，思路才是核心

Burp Suite的Repeater和Intruder是吃饭的家伙，但别指望插件能替你思考。我习惯先把目标的所有接口在Burp里过一遍，看参数命名规律。user_id、order_no、file_path——这些参数名一出现，就值得多试几组值。

文件上传也是重灾区。前端限制.jpg，后端只检查Content-Type，改包成image/jpeg传个.php上去，如果服务器没配解析限制，直接getshell。更离谱的是有的系统把上传文件放在Web目录下，文件名还保留原样，连路径都不用猜。

防守方的视角

站在开发这边，防WED类渗透没有银弹。核心原则就一条：永远不要信任客户端传来的任何数据。权限校验必须落在服务端，每个请求都要重新验证当前用户是否有权操作目标资源。参数化查询防注入，但防不了"把ID改成别人的"——那是越权，得靠RBAC或ABAC模型去卡。

日志和监控也得跟上。一个用户在一分钟内遍历了1000个订单ID，这种异常行为应该触发告警。很多公司被拖库了才发现，之前已经有大量异常请求，只是没人看日志。

渗透测试报告里，我一般把WED类漏洞标成"高危"。不是因为它技术含量高，而是因为它直接触碰业务核心——钱、数据、权限。一个SQL注入可能只拿到数据库里的哈希，一个越权漏洞能直接看到用户的身份证照片。哪个更疼，不用多说。