```html

安全漏洞怎么解决

上周三凌晨两点，我盯着一个刚上线的漏洞内部系统日志，发现有个参数居然能直接传 ../etc/passwd 并且返回了文件内容。解决这不是安全什么高深漏洞，就是漏洞典型的路径穿越。开发同学图省事，解决直接用用户输入拼了文件路径。安全那一刻我就想，漏洞安全漏洞这东西，解决从来不是安全靠“高度重视”就能消失的，得动手拆。漏洞

很多人一听到漏洞，解决第一反应是安全打补丁。补丁当然要打，漏洞但补丁只是解决止血。真正要解决，得先承认一个事实：漏洞不是被“修”没的，是被“挤”没的。你堵住一个入口，攻击面就小一圈。我见过太多团队，出了事就加一个正则过滤，结果第二天换个编码又绕过去了。这种“打地鼠”式修复，累死三班倒的安全工程师也没用。

拿去年一个真实案例说。某电商后台有个订单查询接口，参数是订单号。开发用了预编译语句，SQL注入防住了。但订单号没做归属校验，用户A改一下订单号就能看用户B的收货地址。这算漏洞吗？算。可它不在任何扫描器的规则库里。怎么解决？不是加WAF，是在业务逻辑层加一行 if (order.userId != currentUserId) return 403;。就这么简单。但这一行，需要写代码的人脑子里有根弦——所有来自客户端的输入，默认都是敌意。

“安全不是产品，是过程。” —— 这话被说烂了，但真正照做的人，会在每次提交代码前问自己：这个参数如果被篡改，最坏能坏到什么程度？

我自己的习惯是，拿到一个功能先不写代码，画数据流图。从入口到数据库，中间经过几个信任边界。每跨一次边界，就加一次校验。比如上传文件，前端校验后缀名？没用。后端收到后，先检查魔术字节，再重命名成随机字符串，最后存到非Web目录。三步做完，就算上传了.php文件也执行不了。这比事后买一堆安全设备便宜得多。

还有一类漏洞，纯粹是“懒”出来的。比如默认密码。某次我帮朋友看一个路由器，后台密码居然是 admin/admin。我说你改一下。他说改了怕忘。结果一周后他家摄像头被直播了。解决这种漏洞不需要技术，需要一点羞耻心——别把用户当傻子，也别把自己当例外。

那已经上线的系统怎么办？我的做法是：先做资产梳理。你不知道自己有多少个接口、多少个老版本还在跑，就谈不上解决。拿个扫描器跑一遍，把高危的、能直接拿shell的排前面。但别迷信扫描结果。我见过扫描器报了一百个漏洞，结果最严重的那个是运维把测试环境数据库端口开在公网，密码是 123456。这扫描器可不会告诉你。

修复的时候，优先级这样排：能直接控制服务器的 > 能读写数据库的 > 能越权看别人数据的 > 信息泄露。排完就动手，别开会。开会讨论“这个漏洞影响不大吧”的时间，够你改三行代码了。

最后说个反直觉的：有些漏洞解决不了，只能隔离。比如一个十年前的老系统，源码都没了，只跑在一台Windows Server 2003上。你非要修它的RCE漏洞，不如把它关进内网，前面加个反向代理，只放行特定IP和特定路径。这叫“补偿控制”。安全不是非黑即白，是权衡。能修就修，修不了就藏，藏不了就监控。最怕的是假装看不见。

总结一下我自己的操作清单：输入校验用白名单，别用黑名单；数据库权限最小化，别用root连；文件上传重命名加隔离；后台接口每个都加越权检查；老系统能下就下，下不了就关内网。这些事做到八成，剩下的漏洞要么够不着，要么打进来也掀不起浪。安全没有满分，但可以做到让攻击成本高于收益。这就够了。