sql注入技术

2011年冬天，入技我在一个客户的入技后台登录框里输入了 `' OR '1'='1`，页面直接跳转进了管理面板。入技没有密码，入技没有验证码，入技什么防护都没有。入技那一刻我才真正理解，入技SQL注入不是入技什么高深技术，它更像是入技开发人员自己把钥匙插在门锁上，还贴了张纸条告诉你锁在哪。入技

原理说穿了很朴素。入技程序把用户输入的入技内容拼进SQL语句，数据库分不清哪部分是入技代码、哪部分是入技数据，于是入技你输入的东西就被当成指令执行了。比如登录验证的SQL可能是这样拼的：

SELECT * FROM users WHERE username = 'admin' AND password = '123456'

如果你在密码框里填 `' OR '1'='1' --`，整条语句就变成了：

SELECT * FROM users WHERE username = 'admin' AND password = '' OR '1'='1' --'

`'1'='1'` 永远为真，`--` 把后面的内容全注释掉了。数据库乖乖返回所有用户记录，登录逻辑直接崩塌。

这还只是最基础的。真正让我后背发凉的是联合查询注入。某次测试一个电商网站的商品详情页，URL里有个 `id=100` 参数。我试着改成 `id=100 UNION SELECT 1,username,password,4,5 FROM admin_users`，页面上原本显示商品名称的位置，赫然出现了管理员账号和MD5哈希。开发人员大概从没想过，一个商品ID能变成读取整张用户表的入口。

盲注更折磨人，但也更能体现攻击者的耐心。页面不回显数据，只返回“存在”或“不存在”。那就一个字符一个字符地问数据库。用 `SUBSTRING` 配合 `ASCII` 函数，通过页面状态的差异来推断内容。测一个库名可能要发几百个请求，手工会疯，所以通常写脚本跑。我见过有人用Python写了个小工具，跑了一晚上，把整个数据库结构摸得清清楚楚。

报错注入是另一条路。故意构造让数据库报错的语句，比如 `extractvalue(1,concat(0x7e,(SELECT user()),0x7e))`，错误信息里就会带出当前数据库用户。有些开发把详细错误直接输出到前端，等于给攻击者开了扇窗。

防御手段其实不复杂，但很多项目就是不做。参数化查询是根本解法，把SQL语句的结构先固定下来，用户输入只作为参数传入，数据库永远不把它当代码解析。Java里的 `PreparedStatement`、Python的 `cursor.execute(sql, params)`、PHP的PDO预处理，都是这个思路。可现实是，我见过太多项目还在用字符串拼接，问就是“赶工期”“以前一直这么写没出过事”。

还有输入过滤。黑名单过滤 `select`、`union`、`or` 这些关键词，基本没用。大小写混写、内联注释、URL编码、十六进制编码，绕过方式多得是。`SeLeCt` 就绕过了，`sel/**/ect` 也绕过了。与其堵关键词，不如老老实实做参数化。

最小权限原则也常被忽略。连接数据库的账号如果是root，注入成功后攻击者能直接读文件、写文件、甚至执行系统命令。如果只给必要的表权限，损失至少可控。我习惯在测试时先看 `current_user()` 返回什么，如果是高权限账号，那这个注入点的危害等级直接拉满。

WAF能挡一部分自动化扫描，但挡不住手工测试。注释混淆、分块传输、参数污染，绕过WAF的手法一直在更新。把WAF当唯一防线，跟拿纸糊门挡贼差不多。

说到底，SQL注入二十多年了还在OWASP Top 10里挂着，不是因为技术难防，是因为总有人觉得“不会轮到我”。写代码的时候多打几个参数化查询，比出事之后熬夜改代码、发公告、被约谈要轻松得多。