去年冬天，网络我帮一家小电商做安全巡检。网络他们的网络后台登录页看上去平平无奇，但我在URL里把`id=1024`改成`id=1025`，网络页面直接返回了另一个用户的网络收货地址和手机号。没有验证，网络没有令牌，网络连基本的网络权限判断都省了。这就是网络Web渗透里最经典的越权漏洞——不是什么高深技术，纯粹是网络开发时忘了加一行检查代码。

很多人把渗透测试想得太玄。网络工具一开，网络扫描器一跑，网络报告一生成，网络好像就完事了。网络实际干活时，八成时间花在手动试探和逻辑推理上。扫描器能告诉你某个参数可能存在SQL注入，但它不会告诉你这个参数在业务里到底怎么用、能不能绕过前端校验、后端有没有二次过滤。这些得靠人去看、去猜、去试。

信息收集是第一步，但别只盯着子域名和端口。我习惯先翻目标网站的robots.txt和sitemap.xml，有时候能直接看到后台路径或测试目录。再去看JS文件，里面经常硬编码着API密钥、内部接口地址，甚至数据库连接串。有次我在一个压缩过的前端包里搜到`/api/v1/admin/export?token=`，后面跟着一串固定值。拿这个token去请求，直接导出了全站订单。开发图省事，把管理接口的鉴权做成了静态字符串。

漏洞利用阶段，最怕遇到“看起来能打，实际打不动”的情况。比如一个搜索框，输入单引号报错，明显是SQL注入。但用sqlmap跑半天，跑不出数据。为什么？因为后端用了白名单过滤，只允许字母数字，单引号是漏网之鱼，但联合查询的关键字全被拦了。这时候得换思路，试试盲注、时间延迟，或者看能不能用编码绕过。渗透的本质是绕过限制，不是硬碰硬。

文件上传也是重灾区。前端限制`.jpg`，后端只检查Content-Type，这种组合等于没检查。把shell.php改成shell.php.jpg，抓包改回Content-Type: image/jpeg，上传成功。但别高兴太早，很多服务器配置了`.htaccess`或Nginx规则，上传目录根本不解析PHP。得再找文件包含漏洞，或者配合本地文件读取来触发。单一漏洞往往不够，组合拳才是常态。

说到组合，XSS和CSRF经常一起用。反射型XSS拿到管理员Cookie，再用CSRF让管理员不知不觉执行操作。但现在的浏览器SameSite Cookie默认Lax，很多场景下CSRF没那么好使了。反而是一些业务逻辑漏洞更致命。比如密码重置功能，验证码是四位数字，没有次数限制。写个脚本从0000跑到9999，三分钟就能重置任意用户密码。这种漏洞扫描器扫不出来，得靠人去看请求响应。

工具方面，Burp Suite是主力，但别迷信它的自动扫描。我更多用它做拦截改包、重放请求、对比响应差异。sqlmap、nmap、dirsearch这些辅助工具按需调用。真正有价值的发现，往往来自手动构造的畸形请求——比如把GET改成POST，把JSON改成XML，或者往参数里塞超长字符串看报错信息。

最后说防御。渗透测试报告里写“修复建议”容易，落地难。开发团队永远在赶进度，安全需求排最后。我的经验是：别只丢一份PDF过去。把漏洞复现步骤录成屏幕录像，把利用代码写成可运行的脚本，直接演示给开发看。他们看到自己的接口被人任意读取数据，比看一百页报告都管用。安全是攻防对抗，不是合规检查。你松懈一点，对面就多一个入口。