去年秋天，网站一个做跨境电商的漏洞朋友半夜给我打电话，说网站首页被替换成了一张黑底红字的检测图片，上面写着“你的网站数据库在我手里”。他以为只是漏洞首页被篡改，结果登录服务器一看，检测订单表里多了几十条0元订单，网站收货地址全是漏洞乱码。攻击者通过一个两年前就没再更新的检测插件漏洞，拿到了数据库的网站写入权限。这件事让我重新审视一个老话题：网站漏洞检测。漏洞多数人以为装个WAF、检测开个HTTPS就万事大吉，网站实际上漏洞往往藏在那些“能用就行”的漏洞角落。

漏洞检测不是检测拿扫描器跑一遍就完事。我见过太多团队把AWVS或Xray的扫描报告当成安全验收单，报告显示“无高危漏洞”就收工。但扫描器能发现的，通常只是已知的、有明确特征的问题。比如SQL注入的报错特征、XSS的反射点，这些它能抓。可逻辑漏洞呢？比如优惠券可以无限叠加、密码重置 token 不失效、越权查看他人订单，扫描器基本无能为力。这些漏洞得靠人去看代码、去抓包、去模拟正常用户和攻击者两种视角来回切换。

说个具体的例子。某在线教育平台，扫描器跑了三遍都说安全。我手动测试时发现，它的课程购买接口在提交订单时，价格参数是前端传的。把价格从199改成0.01，订单照样生成，支付网关也只收一分钱。这种参数篡改漏洞，扫描器不会报，因为它不认为“修改价格”是异常输入。可对平台来说，这就是直接的资金损失。检测这类漏洞，得把每个涉及金额、权限、数量的接口都拿出来，逐一问：这个参数如果被恶意修改，系统会怎样？

再往深一层，很多漏洞是“配置”带来的，不是代码写错了。比如目录遍历，代码里可能写了过滤，但Nginx的autoindex没关，访问 /uploads/ 直接列出所有用户上传的文件。或者Spring Boot的actuator端点没做鉴权，/env 里明文躺着数据库密码。这类问题扫描器有时能发现，但经常被归为“信息泄露”低危，运维看一眼就忽略。实际上，一个泄露的数据库密码足以让整个网站沦陷。我习惯在检测时先跑一遍目录扫描和端口扫描，把那些“不该对外开放”的东西找出来，比盯着代码里的注入点更有效。

工具方面，别迷信某一个。Burp Suite 用来手工测试和抓包改包，nuclei 跑批量POC，dirsearch 扫目录，再配合自写的Python脚本处理业务逻辑。我通常先让扫描器跑一轮，把结果按接口分类，然后针对每个接口构造畸形请求：空值、超长字符串、数组、JSON里嵌套对象、修改HTTP方法。有一次在一个用户注册接口，把email字段改成数组格式，后端直接抛了500错误，堆栈信息里带出了数据库连接串。这种问题扫描器不会主动报，因为它的payload字典里没有这种“合法但异常”的结构。

最后说个容易被忽略的点：漏洞检测的频率。很多公司一年做一次渗透测试，报告出来修完就完事。但网站每周都在发版，新代码可能引入新漏洞。我的建议是把检测拆开：上线前用自动化工具扫一遍增量代码，每周跑一次全量扫描，每季度做一次人工渗透。别等出事再补，攻击者不会按你的排期来。那个跨境电商的朋友后来把插件全换成了自研的，虽然丑，但至少每个接口的权限都自己控着。安全这事，省下的功夫最后都会变成事故。