内容摘要：去年秋天，我接手了一个内部系统的安全审计。那系统上线三年，平时跑得挺稳，没人觉得会出大事。结果我用一个很笨的办法——直接在登录框里敲了一串引号——数据库居然报错了。错误信息完整地吐出了SQL语句的结构

去年秋天，安全我接手了一个内部系统的漏洞安全审计。那系统上线三年，验证平时跑得挺稳，及加没人觉得会出大事。安全结果我用一个很笨的漏洞办法——直接在登录框里敲了一串引号——数据库居然报错了。错误信息完整地吐出了SQL语句的验证结构。那一刻我后背发凉，及加这等于把自家大门的安全锁芯拆下来给贼看。

漏洞验证的漏洞第一步从来不是拿工具扫，而是验证先想清楚攻击者会怎么想。他们不会按文档来，及加专挑你没想到的安全角落下手。那次测试我试了三十多个参数，漏洞最后在用户头像上传功能里找到了突破口：文件类型检查只看了HTTP头里的验证Content-Type，没验证文件内容。我改了一个字节的图片文件头，塞进去一段PHP代码，服务器就乖乖执行了。整个过程不到十分钟。

加固方案写起来容易，落地才是真功夫。光说“过滤输入”没用，得具体到是白名单还是黑名单。白名单要列出所有允许的字符集，黑名单永远堵不干净。我见过太多团队图省事，用黑名单拦了几个常见关键字就以为安全了——攻击者换一种编码方式就绕过去了。那次加固我坚持用参数化查询，把所有SQL语句改成预编译模式，改了整整两天，改完测试发现原本能跑的搜索功能慢了两百毫秒。性能损失是实实在在的，但比起数据泄露的代价，这点延迟不值一提。

还有一类漏洞特别隐蔽，跟代码逻辑无关，纯粹是配置问题。比如服务器上开着WebDAV，或者备份文件放在web根目录下。我遇到过一家公司，把数据库备份压缩包直接放在站点根目录，文件名还带日期。任何人猜一下就能下载到完整的数据。这种问题用不着什么高深技术，定期巡检配置文件就能发现。但就是没人巡检，直到出事才追悔莫及。

验证漏洞时你得有“破坏者心态”。别按正常流程走，故意传超长字符串、改请求方法、删掉必填字段。系统越是在边界条件下表现得奇怪，越说明有戏。有一次我仅仅把请求里的HTTP方法从POST改成PUT，就绕过了权限校验，拿到了管理员接口的返回数据。开发人员听到这个结果时一脸茫然，他们压根没想过有人会这么干。

加固不是一次性买卖。这周补了SQL注入，下周可能冒出个越权访问。我习惯在每次修复后重新跑一遍完整的攻击路径，不光验证原漏洞没了，还要看看有没有因为修漏洞引入新问题。比如为了防XSS给输出加了转义，结果把正常业务数据也转义了，页面显示乱码——这种乌龙我见过不止一次。

安全这事，说穿了就是跟攻击者比谁更细心。你多检查一道文件类型，他就得多花半小时找别的路。你给错误信息套个通用模板，他就猜不出后端用的什么框架。这些琐碎的功夫，堆起来就是一道墙。墙不一定要多高，但得让翻墙的人觉得费劲，觉得不值当，转头去找更软的柿子捏。