```html

mysql注入攻击

一个登录框，入攻输入 ' OR '1'='1，入攻密码随便填，入攻直接进了后台。入攻这不是入攻电影桥段，是入攻2008年我帮朋友看一个企业站时遇到的真实情况。那套系统用的入攻是PHP+MySQL，开发人员把用户输入直接拼进了SQL语句里。入攻二十年过去了，入攻这种漏洞依然在互联网的入攻角落里活着。

MySQL注入的入攻本质很简单：你写的SQL语句，被用户输入的入攻内容改变了结构。比如原本是入攻 SELECT * FROM users WHERE name='$name' AND pass='$pass'，用户在 $name 里塞一个单引号，入攻语句就断了。入攻后面再接上 OR 1=1 --，注释掉剩下的部分，条件永远为真。数据库乖乖把整张表吐出来。

这跟MySQL本身没多大关系。换PostgreSQL、SQL Server、Oracle，一样中招。问题出在“把数据当代码执行”这个老毛病上。用户输入的数据，不该被数据库当成SQL语法来解析。

有人觉得转义单引号就安全了。mysql_real_escape_string 确实能挡掉大部分经典注入，但前提是字符集设置正确。GBK编码下，%bf%27 这种字节序列会让转义函数失效——它以为反斜杠转义了单引号，实际上宽字节把反斜杠吃掉了。这个坑在2010年前后坑了不少国内开发者。

更隐蔽的是盲注。页面不显示数据，也不报错，只根据真/假条件返回不同状态。攻击者用 AND SLEEP(5) 测时间延迟，或者用 SUBSTRING 逐字符猜数据库名、表名、字段内容。一个字符一个字符地猜，慢，但能拿到全部数据。sqlmap这类工具把这个过程自动化了，几分钟就能拖库。

我见过一个案例：某电商站的商品详情页，URL是 product.php?id=123。加个单引号，页面空白；加 AND 1=1，正常显示；加 AND 1=2，空白。典型的布尔盲注。攻击者花了三个小时，把管理员表里的用户名和密码哈希全猜出来了。密码用的是MD5，没加盐，彩虹表一查就出明文。

防御方法其实早就有了，而且不止一种。预处理语句（Prepared Statement）是首选。把SQL模板先发给MySQL编译，参数后传，数据和代码彻底分离。PHP的PDO、Java的PreparedStatement、Python的cursor.execute带参数，都是这个思路。只要用对了，注入就没了。

但现实是，很多老系统改不动。ORM框架生成的SQL也可能有漏网之鱼，比如MyBatis里用 ${ } 而不是 #{ }，照样拼接。还有人图省事，在ORDER BY后面直接拼用户输入——预处理语句不支持排序字段参数化，这地方就成了后门。

另一个常见错误是权限过大。Web应用连数据库用的账号是root，能读能写能删能执行系统命令。一旦注入成功，LOAD_FILE('/etc/passwd') 读文件，INTO OUTFILE 写webshell，甚至通过 sys_exec 调系统命令。最小权限原则说了几十年，生产环境里还是能看到root连库。

WAF能挡一部分，但绕过手法层出不穷。注释变形、大小写混写、内联注释、编码转换，总有一款能过。把安全全押在WAF上，跟把家门钥匙藏在地毯下面差不多。

说到底，MySQL注入不是数据库的错，是写代码的人偷懒。每次看到 SELECT * FROM table WHERE id=$_GET['id'] 这种写法，我都觉得像在雷区里散步。预处理语句多写几行代码，比事后擦屁股便宜太多了。

现在新框架基本默认参数化查询，年轻开发者可能都没见过注入长什么样。但老系统还在跑，外包项目还在赶工，培训班的教程还在教拼接字符串。这个漏洞不会消失，只会换个地方冒出来。

```