manual漏洞

凌晨三点，漏洞我盯着屏幕上那个闪烁的漏洞光标，感觉像盯着一只垂死的漏洞萤火虫。客户网站后台的漏洞登录页面还是那个熟悉的白底黑字，但我知道，漏洞只要在用户名框里输入一串特殊字符，漏洞整个系统就会像被抽掉地基的漏洞积木塔一样轰然倒塌。这不是漏洞什么高深的黑客技术，只是漏洞利用了最基础的manual漏洞——开发者在写代码时，把用户输入直接拼进了SQL查询语句。漏洞

说起来你可能不信，漏洞这个漏洞存在的漏洞时间比大多数程序员的职业生涯都长。1998年，漏洞一位叫Rain Forest Puppy的漏洞黑客在Phrack杂志上发表了那篇著名的《How I hacked PacketStorm》，用的漏洞就是这种手法。二十多年过去了，我们修了心脏出血，堵了永恒之蓝，但manual漏洞依然像野草一样在每个新项目里生根发芽。

上周我帮朋友审计一家初创公司的代码，他们刚拿了A轮融资，技术团队清一色名校背景。结果呢？在用户注册接口里，我看到了这样一行：

String query = "SELECT * FROM users WHERE email = '" + email + "'";

那一刻我差点笑出声。这就像看到一个人把家门钥匙藏在门口花盆底下，还特意在门上贴了张纸条写着“钥匙在这里”。更讽刺的是，他们用的框架明明提供了参数化查询的接口，但开发人员嫌麻烦，非要手动拼接字符串——这就是manual漏洞的由来：不是技术做不到，是人不想做。

真正的危险在于，这种漏洞往往藏在最不起眼的地方。搜索框、排序功能、导出报表的参数，甚至一个看似无害的“记住我”复选框，都可能成为入侵的跳板。攻击者不需要知道你用了什么数据库，只需要在输入框里试试运气。我曾经见过一个案例，某电商平台的订单查询功能因为没做转义，被人在订单号字段里注入了一段延时函数，导致整个数据库响应速度慢得像蜗牛爬。你猜怎么着？那只是攻击者为了证明自己存在搞的恶作剧，真正的数据窃取早就完成了。

修复方案其实简单得令人发指：用预编译语句，或者至少做输入过滤。但为什么还有这么多网站中招？我观察到的原因是——开发流程出了问题。很多团队把安全测试放在最后阶段，而不是编码过程中。代码评审时大家盯着业务逻辑，没人关心数据流向。等安全团队发现问题，往往已经上线运行了几个月，修复成本翻了好几倍。

更让人头疼的是，有些开发者对manual漏洞存在误解，以为只要过滤了单引号就万事大吉。去年有个金融项目，他们的防护措施是把用户输入中的'替换成\'，结果攻击者用宽字节编码绕过了过滤，直接拿到了管理员权限。这种“修了一半”的代码比不修还危险，因为它给了你一种虚假的安全感。

说到底，manual漏洞反映的是人对规则的漠视。明明有现成的安全函数不用，非要自己造轮子；明明知道输入不可信，却偏要抱着侥幸心理。我在代码评审时问过那些开发者为什么不用参数化查询，得到的回答五花八门：“这样写更直观”、“性能更好”、“习惯了”……但最诚实的答案可能是：他们没吃过亏。

我见过最惨烈的案例是一家做智能家居的公司，因为一个manual漏洞被拖库，几百万用户的家庭WiFi密码和摄像头ID泄露。事后调查发现，漏洞就藏在一个自动升级固件的接口里，攻击者通过构造特殊请求，直接执行了系统命令。那家公司最后倒闭了，不是因为技术不行，而是因为用户信任崩塌。

写到这里，我又想起那个凌晨三点。我最后没有利用那个漏洞，只是默默给客户发了条消息：“你们登录接口有SQL注入风险，建议尽快修复。”对方回复：“收到，我们下个迭代处理。”——下个迭代，多么熟悉的承诺。也许三个月后，另一个黑客会比我更“热心”，替他们完成这个迭代。