会引起SQL注入漏洞的关键字

你写了一条查询，用户输入 1' OR '1'='1，漏洞整个表的键字数据就全被拖走了。这不是注入什么高深攻击，就是漏洞几个关键字在作祟。我见过太多代码，键字拼接字符串的注入时候对 UNION 视而不见，对 -- 毫无防备。漏洞下面这些词，键字只要出现在未过滤的注入输入里，数据库就得抖三抖。漏洞

OR 和 AND 排第一梯队。键字它们本身不是注入坏东西，但一旦被塞进 WHERE 子句，漏洞逻辑就彻底变了。键字比如登录验证：

如果用户输入 admin' --，后面的密码检查直接被注释掉。-- 这个注释符，在SQL里是单行注释，攻击者用它砍掉剩余查询。另一个注释符 # 在MySQL里同样致命。还有 /* */，多行注释，用来绕过一些简单的过滤。

UNION 是数据泄露的直通车。攻击者构造 ' UNION SELECT username, password FROM users --，只要列数匹配，就能把敏感表的内容拼到正常结果里。我见过一个电商网站，搜索框没过滤 UNION，结果整个用户表被拖库。那个搜索框返回的是商品列表，但攻击者通过调整列数，硬生生把管理员密码塞进了商品描述里。

SELECT 本身不直接引发注入，但它常和 UNION 搭配。单独出现时，如果参数被拼进 ORDER BY 后面，也能玩出花。比如 ORDER BY 1 -- 用来探测列数，或者 ORDER BY (SELECT ...) 做盲注。还有 INTO OUTFILE，MySQL里写文件，直接提权。这个关键字组合一旦可用，服务器就成肉鸡了。

“我见过最离谱的代码，把用户输入的 DROP 直接拼进查询。结果测试人员输入 '; DROP TABLE users; --，整个表没了。还好是测试环境。”

EXEC 或 EXECUTE 在SQL Server里是执行动态SQL的。如果输入点能触达这里，攻击者可以执行任意命令。xp_cmdshell 这个扩展存储过程更狠，直接调系统命令。不过现在默认关闭，但老版本或者配置疏忽的实例依然危险。

时间盲注里，SLEEP、BENCHMARK、WAITFOR DELAY 是关键词。它们不返回数据，但通过响应时间判断注入是否成功。比如 '; IF (1=1) WAITFOR DELAY '0:0:5' --，页面卡5秒，说明注入点存在。这种手法隐蔽，但日志里会留下大量异常延迟。

HAVING 和 GROUP BY 在报错注入里常见。攻击者用 HAVING 1=1 制造错误，让数据库把版本信息、表名吐在错误消息里。还有 EXTRACTVALUE、UPDATEXML，MySQL的报错函数，配合 CONCAT 把数据拼进XPath错误里。这些关键字单独看人畜无害，组合起来就是读表利器。

布尔盲注依赖 AND 和 OR 的短路逻辑。比如 AND SUBSTRING((SELECT password FROM users LIMIT 1),1,1) = 'a'，逐字符猜解。这里 SUBSTRING、ASCII、LIMIT 都是辅助关键字。它们本身不触发漏洞，但让注入变得可行。

防御上，别只盯着黑名单。我见过过滤了 OR 却漏了 || 的，Oracle里 || 是字符串连接，但某些数据库里也能当逻辑或。&& 同理。还有 %27 这种URL编码的引号，绕过简单过滤。参数化查询才是正路，但很多老系统改不动，那就得靠输入验证和最小权限。

数据库用户权限别给太高。Web应用连数据库的账号，只给必要的SELECT、INSERT、UPDATE，别给 DROP、FILE、EXEC。这样即使注入成功，攻击者也拿不到太多东西。我见过一个后台，数据库用户是root，结果注入后直接 LOAD_FILE('/etc/passwd')，系统文件都读出来了。

最后提一句，information_schema 这个库名不算关键字，但注入后第一步往往是查它。表名、列名全在里面。攻击者用 UNION SELECT table_name FROM information_schema.tables 摸清结构。所以别把敏感表名起得太直白，比如 admin_users、credit_cards，这等于给攻击者递地图。

关键字列表可以很长，但核心就那几个：OR、AND、UNION、SELECT、--、#、/*、EXEC、SLEEP、BENCHMARK、WAITFOR、INTO OUTFILE、LOAD_FILE。写代码时看到它们出现在用户输入里，就该警觉。别等拖库了才去翻日志。