安全测试怎么测

上周有个做电商的安全朋友找我，说他们上线前跑了三轮安全测试，测试测结果还是安全被一个初中生用万能密码登进了后台。我问他测了什么，测试测他说扫了端口、安全查了SQL注入、测试测跑了AWVS。安全问题出在哪？测试测他们没测“逻辑”——那个初中生只是在登录框里输入了 admin' or '1'='1，而他们的安全测试用例里只验证了“密码错误时返回401”。

安全测试不是测试测买把锁把门锁上就完事。它更像请个开锁师傅来，安全把他能想到的测试测所有歪招都试一遍。我见过太多团队把安全测试等同于“漏扫报告”，安全扫完没高危就上线，测试测结果被薅走几十万优惠券。安全漏扫工具能发现已知漏洞，但发现不了“满100减99”的优惠券能叠加使用这种业务逻辑漏洞。

先说最容易被糊弄的环节：身份认证。很多测试只测“正确密码能登录”，但真正要测的是错误路径。密码错误返回什么？账号不存在返回什么？这两个提示如果不一样，攻击者就能枚举出所有有效用户名。我习惯用Burp Suite的Intruder跑一遍用户名字典，看响应长度差异。还有个经典案例：某App的“忘记密码”功能，验证码是4位数字，没有次数限制。我写了个脚本从0000跑到9999，三分钟就重置了别人的密码。这种测试不需要什么高深工具，写个循环就行。

授权测试是另一个重灾区。你登录了A账号，把请求里的用户ID改成B账号的，看能不能拿到B的数据。这叫水平越权。垂直越权更简单：用普通用户token去调管理员接口。我见过一个系统，前端隐藏了“删除用户”按钮，但后端接口没做角色校验。普通用户抓包改个参数就能删库。测试方法很土：拿低权限账号，把高权限接口全跑一遍，看返回是403还是200。

输入验证这块，SQL注入和XSS是老生常谈，但很多人只测了GET参数，忘了JSON body、HTTP头、甚至Cookie。有个细节：测试注入时别只盯着单引号，试试 1' AND SLEEP(5)-- 看响应时间。如果数据库是MongoDB，注入的是 { "$ne": null} 这种NoSQL语法。工具扫不出来的，得手工构造。

业务逻辑漏洞最考验人。比如支付时把金额改成负数，看能不能反向充值；比如订单状态从“待支付”直接改成“已发货”；比如抽奖接口没有频率限制，写个while循环抽一万次。这些没有通用工具，只能靠理解业务。我通常会画一张业务流程图，在每个节点问自己：“如果我是攻击者，这里能怎么绕？”

最后说个容易被忽略的：第三方组件。你代码写得再安全，引用的开源库有CVE照样完蛋。用 dependency-check 或 trivy 扫一遍依赖，比人工审计快得多。但别全信扫描结果——有些CVE需要特定配置才能触发，得看实际调用路径。

安全测试的终点不是“没有高危漏洞”，而是“攻击者试了所有已知路径都进不来”。这需要测试人员有点“坏人思维”。工具能帮你省力，但替代不了手工构造请求时的直觉。下次上线前，别只跑扫描器了，找个开发同事，让他试着黑进自己写的系统。通常十分钟内，他就能发现三个你没想到的漏洞。