sql注入攻击实验

把单引号塞进登录框，入攻回车，击实整个用户表就摊在浏览器里了。入攻这不是击实电影桥段，是入攻上周我在本地靶场亲手复现的 SQL 注入。代码里那行 SELECT * FROM users WHERE name = '$name'，击实只要 $name 填上 ' OR '1'='1，入攻数据库就把所有账号当成了合法身份。击实问题不在数据库，入攻在拼接字符串的击实人。

我搭的入攻环境是 PHP 7.4 + MySQL 5.7，前端一个灰扑扑的击实登录页。先输 admin' --，入攻注释掉后面的击实密码校验，直接进了后台。入攻再试 ' UNION SELECT 1,user(),database() --，页面回显里蹦出 root@localhost 和库名 testdb。那一刻挺安静，就鼠标点了一下，数据自己走出来了。注入的本质是让用户输入变成 SQL 语法的一部分，而不是数据。数据库分不清哪段是代码、哪段是值，谁拼的字符串谁背锅。

手工注入慢，但能看清每一步。用 ORDER BY 猜列数，从 1 试到 5 报错，说明当前查询用了 4 列。UNION SELECT 时列数必须对齐，否则直接 500。接着查 information_schema.tables，把表名一个个捞出来。有个细节：MySQL 5.0 以上才有 information_schema，老版本得靠盲注。盲注更磨人，用 SUBSTRING 和 ASCII 逐字符猜，一个库名能跑半小时。布尔盲注看页面真假，时间盲注看 SLEEP(5) 卡不卡。我试过用 IF(ASCII(SUBSTRING(database(),1,1))>100,SLEEP(3),0)，浏览器转圈的那几秒，心里反而踏实——说明注入点活着。

工具当然快。sqlmap 一条命令 -u "http://target/login.php" --data="name=1&pass=1" --dbs，库名、表名、字段、数据全给你拖出来。但工具跑出来的结果我总要多看两眼，因为有些注入点被 WAF 拦了，sqlmap 会换 tamper 脚本绕，绕得对不对得自己验证。有次它报存在注入，我手工一测是误报——参数进了 LIKE 语句，单引号被转义了，工具没识别出来。工具是拐杖，腿还得自己长。

防御这事，说烂了但总有人踩坑。预处理语句是正解，PDO 或 mysqli 的 prepare 把 SQL 结构和数据分开传，数据库先编译再填值，单引号永远只是单引号。我见过有人用 addslashes 就以为万事大吉，宽字节注入（%df'）直接绕过。还有过滤 union 关键字的，大小写混写、内联注释 /*!union*/ 照样过。白名单比黑名单靠谱，参数化比转义靠谱，最小权限比 root 连库靠谱。给 Web 应用配个只能 SELECT 的数据库账号，就算注入了也拖不走 mysql.user。

实验做完我把靶场删了，但那条拼接字符串的代码还留在脑子里。SQL 注入二十多年前就有人写论文，到现在 OWASP Top 10 里还能排上号。不是技术难防，是写代码的人图省事。下次看见 ".$_GET['id']." 直接拼进查询，我大概会先叹口气，再默默改成 ? 占位符。