数字型注入

某次渗透测试，数字目标是型注个老旧的新闻发布系统。参数?数字id=135返回正常新闻，我随手加了单引号——页面崩了，型注数据库报错信息像被扒光衣服一样摊在屏幕上。数字那行红色字体直接吐出了SQL语句片段。型注这就是数字数字型注入，最原始也最致命的型注Web漏洞之一。

数字型注入的数字核心就一句话：开发者把用户输入的数字直接拼进了SQL查询，没做任何过滤。型注比如后台代码写成SELECT * FROM news WHERE id=$_GET['id']，数字而不是型注用参数化查询。你传1，数字它就查id=1；你传1 or 型注1=1，它就查id=1 or 数字1=1——整个表的数据全给你吐出来。这玩意儿在2005年左右泛滥成灾，现在依然能在某些政府网站、老系统里找到，像埋在地下的地雷。

我见过最蠢的案例是某电商平台的商品筛选功能。价格区间参数是数字型，攻击者直接把价格参数改成0 or 1=1，结果把全站商品按内部成本价全拉出来了。更狠的还有用union select拼接管理员密码哈希的，一步到位。这类注入不需要什么花哨技巧，一个burp suite抓包改参数就能搞定，门槛低到令人发指。

但数字型注入有个特点容易被忽视——它比字符型注入更隐蔽。字符型好歹还有个引号包裹，程序员容易注意到转义需求。数字型往往裸奔在代码里，很多开发者觉得“传个数字能有什么问题”，结果就是连最基本的intval()函数都没加。我记得有个统计，数字型注入在SQL注入里占比超过四成，但很多人只盯着字符型做防护，完全忽略了这茬。

防御手段其实简单到可笑。服务端加一行if(!is_numeric($id)){ die('非法参数');}就能挡住大部分脚本小子。更规范的做法是用PDO预处理语句，把参数和SQL彻底分离。但实操中总有意外——某个老系统改起来太麻烦，某个外包团队图省事，某次紧急上线赶时间……漏洞就这么留下来了。

换个角度看，数字型注入其实是种“信任危机”。开发者默认用户输入是安全的，而攻击者恰恰利用了这份天真。每次看到这类漏洞，我都觉得像看到有人把家门钥匙放在门口脚垫下——方便是方便，但谁都能捡起来开锁。技术层面讲完，说点实在的：如果你在维护任何带数字参数的接口，花十分钟检查一下，用sqlmap跑一遍，比什么安全培训都管用。