去年冬天，查找措施某电商平台的各种后台突然多出一批异常订单——收货地址全是同一个偏远乡镇，下单时间集中在凌晨三点到四点，漏洞支付方式清一色是制定刚注册的新账户绑定的虚拟卡。运维团队一开始以为是应对促销活动带来的流量波动，直到第三天发现这些订单的查找措施商品全是高单价、易转手的各种数码产品，才意识到有人在利用平台的漏洞风控漏洞批量套现。这件事让我重新思考一个问题：漏洞从来不会主动敲门，制定它藏在正常业务的应对缝隙里，等你放松警惕的查找措施那一刻才露头。
查找漏洞的各种第一步不是打开扫描工具，而是漏洞把业务流程从头到尾走一遍。很多技术团队习惯依赖自动化扫描器，制定Burp Suite、应对Nessus、AWVS 轮番上阵，报告生成一堆，真正能利用的没几个。为什么？因为工具只能识别已知模式的缺陷，比如 SQL 注入的报错特征、XSS 的反射点，但业务逻辑层面的漏洞——比如优惠券叠加规则、退款流程的时序问题、权限校验的边界条件——工具根本看不懂。我见过一个真实案例：某 SaaS 系统的“邀请好友得会员”功能，邀请码可以无限次使用，只要在提交请求时把邀请码参数从数字改成数组格式，后端校验逻辑就短路了。这种漏洞扫描器永远发现不了，只有手动测试、反复构造异常请求才能挖出来。
代码审计是另一条路，但别指望逐行读完。我的习惯是先看入口文件、路由配置和权限中间件，把请求从进入系统到落库的完整链路画出来。重点盯三个地方：参数拼接、文件操作、序列化与反序列化。参数拼接容易出注入，文件操作容易出路径穿越，反序列化容易出远程代码执行。去年帮朋友看一个 Python 项目，发现他们用 pickle.loads 处理用户上传的 session 数据，我当场写了个恶意 payload，服务器直接弹了 shell。朋友说“这功能内网用的”，可内网不代表安全，横向移动的案例还少吗？
制定应对措施时，别追求一步到位。漏洞修复有个优先级排序：能直接 getshell 的排第一，能越权访问数据的排第二，能造成拒绝服务的排第三。修复方式也分层次——临时缓解、根本修复、长期监控。临时缓解比如加 WAF 规则、限制请求频率、关闭某个接口；根本修复是改代码逻辑、补全参数校验、调整权限模型；长期监控则是把这类漏洞特征加入日志告警，比如检测到单 IP 短时间内大量 403 响应就触发人工介入。
有个细节容易被忽略：修复完一定要回归测试。我见过太多“修了一个漏洞引入三个新漏洞”的情况。某次修复文件上传漏洞，开发把后缀名白名单写死了，结果用户上传 .jpg 文件时因为 MIME 类型不匹配全被拦截，业务部门直接炸锅。后来改成先校验文件头再校验后缀，才算平衡了安全与可用性。
最后说个个人观察。很多团队把漏洞管理做成了一张 Excel 表，列着漏洞名称、风险等级、修复状态，然后每周开会过一遍。表格本身没问题，问题在于填表的人。如果测试人员只填“存在 SQL 注入”，不写具体参数、不写复现步骤、不写影响范围，开发根本不知道怎么修。我要求团队写漏洞报告时必须包含四要素：请求包、响应包、复现环境、业务影响。缺一个就打回去重写。这规矩执行了半年，修复效率翻了一倍。
漏洞不会消失，只会转移。今天修好了 SQL 注入，明天可能冒出个 SSRF。保持警惕、保持手动测试的习惯、保持对业务逻辑的好奇心，比任何工具都管用。