一个SQL注入就能让电商平台用户数据裸奔，安全这事我亲眼见过。测试去年某家创业公司做渗透测试，包括开发小哥拍着胸脯说“我们用了ORM框架，安全防注入妥妥的测试”，结果测试人员只在搜索框输入了`' OR 1=1 --`，包括后台订单表就整个拉出来了。安全所以说web安全测试不是测试跑个漏洞扫描器就完事，它得覆盖六个层面。包括

认证和会话管理是安全头一道坎。拿登录功能来说，测试很多人以为密码加密存储就安全了，包括可偏偏忽略会话令牌。安全测试时要试：退出登录后点浏览器后退键，测试能不能看到缓存页面？包括把cookie里的session ID手动改几个字符，服务器会不会报错？更绝的是有些系统用URL参数传递会话标识，日志里一抓一大把。我见过某银行网银系统，会话超时设成两小时，测试人员直接拿同事的登录链接在另一台机器上打开，居然能正常操作——这哪是会话管理，简直是裸奔。

输入验证这块最考验细心。除了经典的XSS和SQL注入，现在还得防着JSON注入、模板注入、甚至SSTI。有次测试一个搜索功能，输入`{ { 7*7}}`，页面直接显示49，说明服务端模板被解析了——攻击者下一步就能执行任意代码。文件上传更是重灾区，光改后缀名绕过还不够，得检查图片头伪造、压缩包炸弹、SVG里的脚本注入。记得有家SaaS服务商允许上传CSV，结果导入功能直接把公式当命令执行，整张表格被Excel公式攻击清空了。

业务逻辑漏洞才是真正考验脑子的地方。这类问题工具扫不出来，全凭测试人员的“坏心眼”。比如修改密码流程，能不能用旧密码直接覆盖新密码？找回密码的验证码是不是六位数字且不限制尝试次数？更隐蔽的是越权访问——把订单详情页URL里的订单号加一减一，看能不能看到别人的收货地址。我碰到过最离谱的案例是某票务系统，改一下优惠券金额参数，99元的票直接变0.01元，开发压根没想过前端传参还能被篡改。

传输层安全测试总被人忽视。现在基本都上了HTTPS，可证书过期了没人管，或者干脆没做证书绑定。用Burp Suite抓包时发现，某政府网站虽然用了HTTPS，但登录请求里的密码字段是Base64编码——这跟明文传输没区别。更别提那些允许TLS 1.0协议的老系统，用Wireshark一抓就能还原加密前的数据流。测试时记得检查混合内容：页面里只要有一张图走HTTP协议，整个加密通道就白搭了。

客户端安全测试得从浏览器视角出发。DOM XSS防不胜防，尤其现在前端框架流行，开发者容易忽略`innerHTML`的危险性。用开发者工具改掉前端JS的校验逻辑，就能绕过长度限制和格式检查——这种测试最直观，能让人瞬间明白“前端校验只是用户体验，不是安全防线”。还有那些第三方依赖库，npm包里藏了挖矿脚本的新闻还少吗？用npm audit扫一遍，高危漏洞一抓一大把。

最后是容量与资源管理测试，说白了就是压力测试的变种。但安全角度的侧重点不同，得看系统在极端情况下会不会泄露敏感信息。比如上传超大文件时，报错信息里带不带服务器绝对路径？并发登录时，数据库连接池耗尽后，新请求会不会把堆栈信息直接抛给用户？有次测一个物联网管理后台，用JMeter模拟500个并发请求，系统直接返回了Redis的IP地址和端口号——这信息泄露得也太慷慨了。

这六块内容看着多，实际测试时是交织在一起的。身份认证漏洞可能引发越权访问，输入验证缺陷可能导致会话劫持。真正的安全测试不是按部就班过清单，而是像侦探一样，从每个响应头、每个异常报错里嗅出突破口。工具只是辅助，重要的是脑子里的那根弦——永远假设攻击者比开发更了解系统。