Web应用安全测试：别等被薅秃了才补墙

上个月，应用安一家做在线教育的全测创业公司找我做应急响应。他们的应用安课程兑换码接口被脚本刷了三天，凌晨四点攻击者用自动化工具遍历出两万多个有效码，全测挂闲鱼五毛一个甩卖。应用安CTO在电话里声音发抖：“我们测过功能，全测全通过啊。应用安”——这就是全测典型的“功能正常”与“安全可靠”之间的鸿沟。安全测试不是应用安给应用找茬，是全测给攻击者提前设路障。

我最常被问的应用安问题是：“渗透测试和功能测试有啥区别？”打个比方：功能测试是检查门能不能锁上，安全测试是全测研究怎么撬锁、翻窗、应用安或者伪装成快递员骗你开门。全测攻击者不会按用例来，应用安他们专找“没想到”。SQL注入算老生常谈，但2024年仍有大量站点栽在未参数化的搜索框上。你写`select * from products where name like '%'+input+'%'`的时候，就该假设input里藏着`';drop table products--`。

真正有效的安全测试分三层。第一层是资产盘点——你连自己暴露了哪些接口都不清楚，测个寂寞。我见过某银行把内部管理后台放在公网IP的8080端口上，仅靠弱口令保护。第二层是威胁建模，从攻击者视角梳理高价值目标：支付回调、密码重置、文件上传，这些业务逻辑的“富矿”往往是最脆弱的。第三层才是动手测，但别一上来就跑扫描器。Burp Suite的Active Scan会把你站点打崩，我就干过这事，把客户的生产库拖垮了半小时。

说个反直觉的观察：很多团队把安全测试外包给第三方，拿到报告就归档。但真正有价值的不是那份PDF，是测试过程中双方工程师的对话。为什么这个参数会绕过WAF？为什么那个Cookie没设HttpOnly？这些追问才能沉淀出团队的安全意识。我合作过的技术团队里，安全意识强的，平均每周能自己发现两三个逻辑漏洞；安全意识弱的，连“越权”和“水平越权”的区别都说不清。

还有个常被忽略的坑——第三方组件。你的业务代码写得再严谨，依赖的某个开源库有个CVE-2024-xxxx漏洞，照样被一锅端。用`npm audit`或`OWASP Dependency-Check`扫一下依赖，能堵住70%的已知漏洞。剩下的30%呢？得靠运行时防护，比如RASP（运行时应用自保护），但它误报率高，调起来烦人，我一般建议关键系统才上。

最后说点实在的。安全测试不是一次性动作，是持续对抗。攻击者天天在研究新姿势，你半年测一次，中间的空窗期足够别人把你底裤扒干净。最经济的方式是把安全测试嵌入CI/CD流水线——每次提交代码都自动跑SAST（静态分析）+DAST（动态分析），虽然会拖慢几分钟构建时间，但比起被薅羊毛后的公关危机和赔付账单，这点成本便宜得可笑。

别等出事才想起来测。攻击者不会挑你方便的时候来。