AWVS扫描器扫出来的网站漏洞报告，往往比实际攻击路径更吓人。修改上周我帮一家电商公司处理站点时，网站AWVS报了个高危SQL注入，修改位置在商品搜索框。网站开发同事第一反应是修改“不可能，我们用了参数化查询”。网站

但AWVS的修改Payload确实打进去了。排查发现，网站问题出在搜索建议接口——那个老接口是修改五年前外包写的，压根没走统一的网站数据访问层。参数化查询只覆盖了新代码，修改老接口成了漏网之鱼。网站这很典型：AWVS不关心你的修改代码新旧，它只找能触达数据库的网站入口。

修改流程得讲究顺序。别一上来就改代码，先复现。AWVS的扫描报告里带完整的HTTP请求报文，把那个请求复制到Burp Suite里重放一遍，确认漏洞真实存在。有时候报告会误报——比如把JSONP回调参数当成XSS，实际上后端过滤了尖括号。复现能帮你筛掉至少三成噪音。

确认后，修改要分三层走。
第一层，堵住入口。拿注入漏洞举例，最直接的是给参数加白名单校验。搜索框只能接受字母、数字和有限符号，其他一律拒绝。别用黑名单，攻击者总有绕过姿势，白名单才是硬边界。

第二层，修底层函数。如果那个老搜索接口调用了公共的SQL拼接方法，得把这个方法改成强制参数化。这里有个坑——改公共函数会影响所有调用方，得跑一遍全量回归。我那次改完，商品分类页的筛选功能就报了500，原因是那页面的排序参数传了个表达式进来，以前拼接能跑，参数化后直接报错。这种连带问题，AWVS不会告诉你，得靠测试兜底。

第三层，加WAF规则做纵深防御。别指望代码修复一劳永逸，AWVS扫描是时点快照，新代码上线又可能引入新洞。在Nginx层加一条规则，拦截包含“UNION SELECT”或“sleep(”的请求，能挡住大部分自动化攻击。注意别把正常业务参数误伤——比如用户搜索“C++”里的加号，正则得写精确。

改完别急着提交，用AWVS的“重扫”功能验证。选仅扫描刚才那个漏洞的URL，而不是全站重扫——全站扫太慢，一个中型站点得跑两小时。验证通过后，再手动构造几个变种Payload试试，比如大小写混合、注释符穿插、编码绕过。AWVS能过，不代表攻击者绕不过。

还有个细节容易忽略：AWVS的漏洞详情里会标注“CWE-89”之类的分类编号，修复后要把编号和修复时间记录到内部漏洞台账里。等下次等保测评或客户审计时，这台账就是整改证据。别嫌麻烦，我见过有公司因为台账缺失，被甲方要求重新做渗透测试，白花好几万。

最后说句实在话——AWVS修改这事，本质是跟时间赛跑。扫描器发现的漏洞，攻击者可能早就在用了。修复优先级别全信CVSS评分，要看业务重要性。比如登录接口的SQL注入是10分，但后台管理员的弱口令漏洞可能只有7分，后者被利用的后果更致命。先修能直接拿权限的，再修需要复杂利用链的。这个判断，AWVS给不了你，得自己拿主意。