登录框永远是全测最容易出戏的地方。我见过太多团队把精力耗在复杂的试用业务逻辑测试上，结果攻击者用一个最简单的全测SQL注入就撕开了口子。去年某家金融科技公司渗透测试，试用测试人员只是全测往用户名框里填了admin' or '1'='1，后台直接返回了全部用户表——那感觉就像你费心装了防盗门，试用结果发现窗户根本没关。全测

Web安全测试的试用核心其实就一句话：别信用户输入，也别信自己的全测假设。但真正执行时，试用很多人会漏掉几个关键角落。全测

先从最基础的试用参数篡改说起。别只盯着GET请求，全测POST体里的试用hidden字段才是重灾区。有个电商平台的全测案例特别典型：结算页面有个隐藏的discount字段，前端JS控制着它只能被修改为0.9。测试人员直接抓包改成0.1，订单金额瞬间缩水90%。这种漏洞不是技术门槛高，而是测试用例里压根没覆盖“修改隐藏域”这个场景。

文件上传功能更是个火药桶。常规测试会检查扩展名黑名单，但很多人忘了检查文件内容头。有个内容管理系统就是吃了这个亏——攻击者上传了一个伪装成JPEG的PHP脚本，文件头是FF D8 FF E0，但中间夹着可执行代码。服务器只验证了文件头，直接让脚本跑起来了。所以用例里必须加一条：用十六进制编辑器修改文件头，绕过类型检测。

再说说越权漏洞，这玩意儿最考验逻辑思维。垂直越权好测，普通用户去访问管理员接口就行。但水平越权需要你仔细分析业务关系。比如一个订单系统，用户A能查看订单号12345，那你得试试把订单号改成12346，看能不能看到别人家的订单。某社交平台曾出现过这样的漏洞：用户修改个人信息时，POST请求里带了个user_id参数，测试人员把它换成别人的ID，结果直接改掉了对方的头像。这种用例设计的关键在于找出所有涉及资源标识符的地方，不管是URL路径、请求体还是Cookie。

CSRF测试经常被人忽略，因为现在很多框架默认加了token校验。但总有漏网之鱼。有个内部管理系统，所有写操作都验证了token，唯独“导出报表”这个功能没加防护。攻击者构造一个恶意页面，诱导管理员点击，就能悄悄触发导出操作，把敏感数据下载到攻击者服务器。测试这类漏洞时，别光看表单，要检查所有带副作用的请求，包括AJAX调用和WebSocket消息。

还有一类容易踩坑的是逻辑漏洞，比如验证码回显。某政务网站找回密码功能，验证码直接放在响应头的X-Captcha字段里——这等于把钥匙挂在门口。测试人员盯着响应报文看了半天，才发现这个低级错误。所以用例里要明确：检查验证码是否在响应体、响应头、甚至JS源码中出现过。

最后说个有点邪门的点：HTTP方法覆盖。有些开发为了RESTful风格，允许客户端用X-HTTP-Method-Override头来指定实际请求方法。比如一个只允许GET的接口，你给它加个X-HTTP-Method-Override: DELETE，服务器可能就真的执行删除操作了。这种问题在Spring MVC项目里特别常见。

安全测试不是流水线作业，它需要你像小偷一样思考。别按部就班地跑扫描器，而是盯着每个业务动作问一句：“如果我是坏人，我会怎么利用这个功能？” 把那些“不可能被攻击”的假设列出来，逐条击破——往往漏洞就藏在这些假设里。