去年有个做电商的全测朋友找我，说他们后台被人越权查了三百多个订单的试培手机号。代码我看了半天，全测没发现明显漏洞——参数校验有，试培权限判断也有，全测但就是试培被绕过了。后来抓包才发现，全测问题出在HTTP方法上：前端用GET请求查订单，试培后端只校验了GET请求的全测权限，攻击者把请求改成POST，试培同一个接口直接返回了全量数据。全测这事儿让我意识到，试培web安全测试里最要命的全测往往不是那些教科书上的经典漏洞，而是试培开发人员自己都没意识到的逻辑盲区。

说到工具，全测Burp Suite几乎是绕不开的。但很多人只拿它当抓包改包的工具用，其实它的Scanner模块对被动扫描挺友好。我习惯把浏览器代理挂上Burp，然后正常点一遍网站功能，让它自己跑被动扫描。这样能捞到一些低危但真实存在的问题，比如cookie没加HttpOnly、响应头缺X-Frame-Options。这些单个拎出来不算大事，组合起来就可能变成点击劫持或者XSS的跳板。不过别太依赖自动扫描，去年某次测试中Scanner报了个“SQL注入”，我兴奋了半天，手工验证发现是时间盲注的误报——参数里有个sleep函数被当成了注入特征。

手工测试的核心其实是理解业务流。拿密码找回功能举例，正常流程是：输入邮箱→收验证码→提交新密码。测试的时候我会盯住验证码的生成逻辑和校验逻辑。有的系统验证码是前端生成的，那直接改JS就能绕过；有的系统校验时只对比了验证码是否正确，没绑定用户会话，那就可以用A用户的验证码去重置B用户的密码。这种漏洞扫描器根本扫不出来，得靠人脑去模拟攻击者的思路。我见过最离谱的一个案例：某网站重置密码时，验证码是四位数字，但服务端只校验了前两位——也就是说爆破范围从一万种直接降到一百种。

XSS现在纯反射型的不多了，但存储型依然常见。前阵子测一个论坛，发帖内容过滤了<script>标签，但没过滤<img src=x onerror=alert(1)>。更搞笑的是，他们过滤逻辑是黑名单，只拦了script和onclick，onerror、onload这些全放行了。我提交了一个带onerror的img标签，帖子页面直接弹窗。修复建议别只写“加强过滤”，得具体到用白名单还是转义方案——HTML实体编码能解决大部分问题，但如果是富文本编辑器，还得考虑DOM型XSS，比如innerHTML直接插入用户输入。

CSRF这块，很多人以为加个token就万事大吉。我测过一个系统，token确实有，但token跟用户会话没绑定——A用户的token可以给B用户用。攻击者只要拿到自己的token，构造一个表单让受害者提交，照样能改掉受害者的邮箱。正确的做法是token必须和session关联，且每次请求后失效。还有，别只依赖Referer校验，那个头可以伪造，也可以被用户浏览器设置成不发送。

文件上传的坑更深。黑名单校验扩展名基本没用，改个大小写、加个空格、用.phtml或者.php5就能绕过。白名单相对靠谱，但还得看文件内容有没有被解析。我遇到过上传图片马的情况：文件头是GIF89a，后面跟PHP代码，服务端只检查了Content-Type和文件头，直接存成了.php。测试的时候可以试试上传.htaccess文件，把图片目录解析成PHP，再传个图片马，直接 getshell。当然，这得在授权测试范围内做。

最后说个容易忽略的点：测试完记得清理数据。有次我测一个后台，插了十几条XSS测试数据，忘了删。结果客户运营人员登录后台，页面弹了一堆alert，差点把我拉黑。安全测试是找问题，不是搞破坏。留个后门或者脏数据，性质就变了。

(责任编辑：娱乐)