上周帮一个做电商的网站朋友看站点，扫描器报了一堆低危漏洞。低危他扫了一眼说“低危嘛，漏洞不管了”。网站我让他把报告打开，低危指着其中一条“Cookie未设置HttpOnly标志”问他：你知道这意味着什么吗？漏洞他摇头。我说，网站你后台的低危登录态Cookie，前端JavaScript能直接读。漏洞只要有一个XSS点，网站哪怕是低危个低危的反射型XSS，攻击者就能把你的漏洞用户会话偷走。低危加低危，网站等于高危。低危

很多人对漏洞分级有误解。漏洞CVSS评分低的，不代表危害小，只代表利用条件相对苛刻。可条件这东西，在真实攻击链里从来不是孤立的。我见过一个案例，某政务网站存在“缺少X-Content-Type-Options头”这种低危问题，配合一个上传功能的内容嗅探缺陷，直接让攻击者把图片当HTML解析，存储型XSS就这么来的。扫描器给两个漏洞各打3分，加起来不到7分，但实际影响是用户数据被批量窃取。

低危漏洞还有个特点：数量多。一个中等规模的Web应用，扫出几十个低危是常态。它们像老房子墙角的裂缝，单看每条都不致命，但雨季一来，水顺着裂缝渗进去，墙皮整片脱落。比如“SSL/TLS弱加密套件”这条，很多运维觉得“反正有HTTPS就行”。可如果站点还支持RC4或者3DES，攻击者能在中间人位置降级协商，把加密流量变成可读的。去年某金融类App被曝出通信内容可被解密，根因就是服务器保留了出口级加密套件——扫描器给的是低危，因为利用需要中间人位置，但一旦条件满足，后果是灾难性的。

再说“目录列表可浏览”。这漏洞听起来人畜无害，不就是能看到文件列表吗？可如果那个目录里恰好有备份文件、日志文件、甚至数据库导出文件呢？我见过一个站点，/backup/目录没关列表，里面躺着三年前的整站源码压缩包。攻击者下载后，从源码里翻出数据库连接串，直接连库拖走用户表。扫描器给目录列表的评分是2.6，但实际造成的损失是百万级用户信息泄露。低危漏洞从来不是独立存在的，它是攻击链上的一个环节。

那怎么处理？我的做法是：先分类，再定优先级。信息泄露类低危，比如版本号暴露、目录列表，优先修，因为它们是攻击者的地图。配置类低危，比如缺少安全响应头、Cookie属性不全，批量修，写进Nginx配置或者中间件里，一次搞定。加密类低危，比如弱加密套件、证书链不完整，必须修，因为影响的是传输层信任基础。至于那些“点击劫持防护缺失”之类的，看业务场景——后台管理页面必须加X-Frame-Options，前台展示页可以暂缓。

修低危漏洞还有个好处：成本低。加一个响应头，改一行配置，重启服务，五分钟的事。但如果不修，等哪天被人拿低危漏洞当跳板打进来，应急响应的时间成本、数据恢复成本、公关成本，够你加一万次响应头。我见过太多团队，盯着高危漏洞修，低危全扔进“接受风险”列表。结果渗透测试报告里，攻击路径偏偏就是从低危开始的。攻击者不傻，他们专挑你觉得“无所谓”的地方下手。

最后说个真实细节。某次我给一个客户做复测，上次报告里有一条“登录页面未设置速率限制”，他们标记为低危不修。复测时我用Burp跑了个密码字典，十分钟跑出三个弱口令账号。登录进去一看，其中一个账号有后台管理权限。这条低危漏洞直接变成了高危入口。所以别再看评分下菜了，低危漏洞是地基里的白蚁，单只看不见，聚起来能蛀空整栋楼。