数据库注入漏洞｜八成栽在字符串拼接

数据库注入漏洞这种事，追到根上大多不是攻击手段多高明，而是代码里那句字符串拼接。用户传上来的东西直接怼进 SQL 语句，等于把钥匙挂在门把手上。翻过不少出事的站点，绕来绕去都绕回同一类写法，框架不背这个锅，服务器也不背。

数据库注入漏洞，多数绕回同一行代码

最常见的一幕是登录验证：`SELECT * FROM users WHERE name=’$name’ AND pwd=’$pwd’`，看着挺正常，输入框里填个 `’ OR ‘1’=’1` 回车，条件永远成立，账号密码都不用猜。也有人拿搜索参数、文章 id、分页的 page 下手，位置不同，套路一样。代码里只要有这种把变量和 SQL 缝在一起的写法，就得留个心眼，别等出事再回头找。

一条查询怎么被拆成两条

SQL 自己是有语法的，数据库解析的时候分不清哪一段是用户数据、哪一段是指令。你拼进去一个单引号，前面的字符串提前收尾，后面写什么它都当语句执行。`id=1 UNION SELECT …` 能拖数据，`1;DROP TABLE` 这种堆叠要看驱动和账号权限，`SLEEP(5)` 可以拿来盲注试探。整数型参数没那么依赖引号，`id=1 OR 1=1` 一样成立。所以别以为把引号转义了就万事大吉，方向从一开始就错了。

转义函数不是救命稻草

addslashes、mysql_real_escape_string 那一套，不少人当成护身符。宽字节环境里 %df%27 这类组合能把转义吃掉，这是老坑，老到很多人以为它不存在。magic_quotes_gpc 早废了，翻老代码还能看见它的影子。整数型参数压根不用引号，转义函数再勤快也挡不住。黑名单过滤 select、union、or 这些词，换个大小写、插个注释、用等价写法就绕过去。过滤本身没错，错在把它当成唯一的门。

参数化查询，写对了才管用

正道是预处理加参数绑定，PDO 的 prepare、mysqli 的 bind_param，让数据老老实实当数据。可写法上有几个坑得提：表名、字段名、ORDER BY、LIMIT 这些位置绑不了占位符，一有人把排序字段从 URL 里接过来，防线就塌；LIKE 查询要把 % 拼在参数里而不是 SQL 里；IN 的条件数不固定，很多人又回去循环拼接。还有 PDO 的 ATTR_EMULATE_PREPARES 打开时是模拟预处理，某些写法下仍旧是拼接，这一点坑过不少人。ORM 也一样，一个 whereRaw 就把前面的努力清零。

WAF 和权限，只能算补漏

WAF 有用，但它认的是特征，变形过的 payload 不一定拦得住，误报也不少见。日志里翻到一堆 union、information_schema 的请求，说明早就有人在试，这时候该回头改代码，别只加规则。数据库账号权限这件事更容易被忽略：业务库别用 root 连，能读的账号不给写权限，后台报表和主站分账号。报错页面把表结构、路径、SQL 语句全吐出来，等于给对手递说明书，生产环境把详细报错关掉，相关配置以框架或服务商文档为准。

二次注入，藏得比较深

还有一种不容易发现：数据先存进去，入库前转义过一遍，看着安全；过些天从库里取出来，又被拼进另一条语句，这时候没人再转义，就爆了。注册时填的用户名、后台的备注、导出时的筛选条件，都可能是入口。存储过程里动态拼 SQL 也是同一个道理，别以为进了数据库就安全。审计代码时这类地方最费眼神，但值得翻，尤其是那些上线年头久、改过好几拨人的老项目。

上线前，值得逐条过的几处

说几个能动手的：全局搜拼接符，还有 `query(`、`exec(`、`raw(` 这类调用，重点看参数从哪来；所有从请求里直接取的变量，落到 SQL 前必须过白名单或绑定；表名和排序字段用固定数组映射，别让用户传；数据库账号按最小权限分；生产环境关报错、开慢查询；上线前跑一次扫描，别只看报告红不红，看看它到底报在哪一行。这些做完，剩下的风险才是能接受的。

数据库注入漏洞不是什么高深的东西，它就是一行偷懒的代码。修起来也不玄，把拼接换成绑定，把权限收一收，把报错藏起来，三件事做到位，大部分事故就跟你没关系了。真要动手，今天先把代码里所有拼接的位置列个清单，比看十篇教程都实在。