扫描网站漏洞

去年秋天，扫描我帮一个做跨境电商的网站朋友看他的独立站。凌晨两点，漏洞他发来一条消息：“后台多了三个管理员账号，扫描我根本没建过。网站”我让他立刻截图服务器日志，漏洞自己打开终端敲了一条命令。扫描五分钟后，网站我告诉他：“你的漏洞网站被人从文件上传接口传了个PHP WebShell，提权到root了。扫描”他愣了半分钟，网站回了一句：“我网站才上线四个月。漏洞”

这就是扫描扫描网站漏洞这件事最残酷的地方——大多数站长第一次意识到漏洞存在，已经是网站被人打穿之后。主动扫描，漏洞本质上是在别人动手之前，自己先当一回“坏人”。

扫描器到底在扫什么

市面上常见的工具，比如AWVS、Nessus、Xray，核心逻辑并不神秘。它们手里攥着一个庞大的“特征库”，里面是成千上万条已知漏洞的指纹。扫描时，工具会向目标网站发送大量精心构造的请求，然后观察返回内容里有没有匹配的特征。

举个例子。SQL注入的扫描，工具会往参数里塞 ' OR '1'='1 这类payload，如果页面返回了数据库报错信息，或者布尔条件导致页面内容发生规律性变化，就判定存在注入点。XSS扫描则更直接，插一段 <script>alert(1)</script>，看它会不会原样出现在响应HTML里。

听起来很机械，但实际扫描时，最耗时间的不是发请求，而是“去重”和“误报过滤”。一个中等规模的电商站，爬虫跑一遍能抓出几千个带参数的URL。每个URL的每个参数都要试几十种payload，请求量轻松破十万。扫完之后，报告里可能躺着两百条“疑似漏洞”，其中真正能利用的不到十条。剩下那些，要么是WAF拦截页面被误判，要么是业务逻辑本身允许的异常输入。

手工测试和自动化扫描的分界线

我自己的习惯是：自动化扫描只用来做“广度覆盖”，真正判断漏洞能不能用，必须手工验证。去年扫一个政务站，工具报了一个“存储型XSS”，位置在留言板。我手动提交了一条带 <img src=x onerror=alert(1)> 的留言，页面确实弹窗了。但当我换成一个真实的窃取Cookie的payload时，发现后台对 document.cookie 做了HttpOnly保护，而且留言内容在入库前被过滤了 onerror 之外的很多危险属性。工具报的“漏洞”存在，但利用价值几乎为零。

反过来，有些漏洞自动化工具根本扫不出来。比如逻辑漏洞——注册时把用户ID从1001改成1000，看看能不能看到别人的订单。这种需要理解业务语义的测试，扫描器无能为力。我见过一个在线教育平台，课程购买接口的 course_id 参数没有做归属校验，只要遍历ID就能以0元价格“购买”任意课程。这种漏洞在AWVS的报告里永远不会出现。

扫描之外，更值得关注的事

很多人把扫描报告当成体检单，扫完没高危就放心了。这个心态很危险。扫描器只能发现“已知的已知”，而攻击者往往利用的是“已知的未知”——比如某个开源组件刚爆出0day，扫描器特征库还没更新。去年Log4j2漏洞爆发时，我认识的几个运维凌晨三点爬起来手动排查，因为他们的扫描器还没推送新规则。

我自己的做法是：每月固定跑一次全量扫描，但平时更关注三件事。一是服务器出站流量，如果Web进程突然往外连一个陌生IP，大概率是WebShell在回连。二是文件完整性，用 find /var/www -mtime -1 -type f 每天查一遍最近修改过的文件，比任何扫描器都灵敏。三是日志里的异常状态码，比如大量200响应出现在不存在的路径上，可能是扫描器在爆破目录，也可能是攻击者在试探。

扫描网站漏洞这件事，工具能帮你省掉80%的重复劳动，但剩下20%的判断，得靠人。别指望一键扫描能给你安全感，真正的安全感来自你对自己网站每一行代码、每一个接口的熟悉程度。那个被传了WebShell的朋友，后来把上传接口的白名单从“只允许图片”改成了“只允许特定后缀+文件头校验+重命名存储”，再扫，干净了。