```html

web网站漏洞扫描

上周帮朋友看一个刚上线的电商站点，后台居然能直接 ?洞扫id=1' OR '1'='1 把整张用户表拖出来。他一脸懵：“我用了框架啊，站漏怎么还有注入？洞扫” 漏洞扫描这事，真不是站漏装个插件就能高枕无忧。

扫描器本质上是洞扫个自动化爬虫加攻击载荷库。它先像普通用户一样点遍所有链接、站漏提交所有表单，洞扫把 URL 参数、站漏Cookie、洞扫HTTP 头都记下来。站漏然后针对每个输入点，洞扫塞入预定义的站漏恶意字符串——比如 ' or 1=1--、<script>alert(1)</script>、洞扫../../etc/passwd。站漏接着观察服务器回显：报错信息里有没有 SQL 语法错误？页面有没有弹出对话框？响应时间是不是突然变长？这些信号就是漏洞的脚印。

但扫描器不是神仙。去年我测一个用 React 写的后台，所有请求都走 /api/graphql，参数全在 JSON body 里。传统扫描器爬了半天只看到一堆 div，连个 ? 参数都没抓到。后来手动构造 GraphQL 查询，才发现有个 user(id: 1) 接口没做权限校验，直接能查别人订单。扫描器败给了前端路由和 API 抽象层。

“漏扫报告里标红的高危，十有八九是误报；真正要命的洞，往往藏在扫描器够不着的地方。”

常见的扫描类型分三种。第一种是黑盒扫描，完全不看源码，就靠发请求猜。像 Acunetix、AppScan 这类商业工具，爬虫强、载荷多，但遇到验证码、CSRF token、频率限制就歇菜。第二种是灰盒扫描，你给扫描器一个登录后的 Cookie，或者提供 Swagger 文档，它能测得更深。第三种是静态代码扫描，不碰运行环境，直接分析 Java 或 PHP 源码里的 Statement.executeQuery 拼接。我见过一个团队用 SonarQube 扫出 200 个“漏洞”，结果 180 个是测试代码里的硬编码密码，实际线上一个都用不了。

手动挖洞的乐趣在于逻辑。扫描器告诉你 /download?file=report.pdf 存在路径穿越，你试试 file=../../../../etc/passwd，返回 403。但如果你改成 file=....//....//etc/passwd，有些中间件会先删掉一个 ../，结果就绕过去了。这种绕过规则，扫描器的载荷库更新再快也追不上。我习惯用 Burp Suite 的 Intruder 配自定义字典，把公司内部常用的参数名（比如 debug=1、test_mode=true）全跑一遍。有次真跑出一个 /admin/export?table=users&format=csv 没鉴权，直接下载了全站用户手机号。

别迷信扫描结果。一个 XSS 漏洞在扫描器眼里是“中危”，但如果它出现在管理员后台的留言审核页面，攻击者可以偷走 admin 的 session，那就是妥妥的高危。反过来，一个 SQL 注入点如果只影响一个只读的、没敏感数据的统计接口，优先级可以往后放。去年某 CMS 爆出远程代码执行，扫描器全在测 /index.php?r=site/login，而真正的入口是 /vendor/phpunit/phpunit/src/Util/PHP/eval-stdin.php——一个开发依赖留下的后门。扫描器没覆盖这个路径，因为它的爬虫不解析 composer.json。

想靠扫描器保平安，至少得做三件事。第一，把扫描器接入 CI/CD，每次上线前自动跑一遍增量扫描，别等季度审计。第二，人工复核所有高危告警，别直接丢给开发修——我见过开发把 ?id=1 的报错页面改成空白页，以为修好了，其实注入还在，只是不回显了。第三，定期用 nuclei 或 xray 这类支持自定义 POC 的工具，把业务特有的漏洞模式写成 YAML 模板。比如你们站内信功能有个 /message/read?mid= 接口，就写个模板测越权。

最后说个真事。某金融客户买了某大厂漏扫，报告显示“无高风险漏洞”。我拿 Burp 抓包，发现登录接口的 remember_me cookie 是 base64(username:md5(password))。改成 base64(admin:md5(admin)) 直接登录后台。扫描器为什么不报？因为它只测了 username 和 password 参数，没分析 cookie 的生成逻辑。漏洞扫描是起点，不是终点。你手里的代理工具和脑子，比任何自动化脚本都值钱。

```