1. 项目概述：从“万能钥匙”到“精准撬锁”

在网络安全领域，SQL注入（SQL Injection）是一个经久不衰的话题。它不像某些利用系统底层零日漏洞的攻击那样高深莫测，更像是一把针对应用层逻辑缺陷的“万能钥匙”。很多开发者，甚至是一些有一定经验的从业者，都曾天真地认为，只要在用户输入的地方加上几个引号过滤或者简单的关键字替换，就能高枕无忧。然而，现实是残酷的。攻击者手中的“钥匙”在不断进化，从最初的简单拼接，发展到利用OR、AND逻辑运算符以及引号的巧妙闭合来绕过看似严密的身份验证防线，这正是我们今天要深入探讨的核心。

这个主题的核心，就是剖析攻击者如何利用这些最基本的SQL语法元素，将一段用于验证用户名和密码的合法查询，扭曲成一张畅通无阻的“通行证”。它解决的不仅仅是“如何黑掉一个登录框”的问题，更深层次地揭示了后端代码在处理用户输入与SQL语句拼接时，因逻辑不严谨而产生的致命缺陷。无论你是刚入门的安全爱好者、正在学习Web开发的学生，还是负责维护企业应用系统的运维或开发人员，理解这些绕过技巧都至关重要。对于攻击方，这是渗透测试中必须掌握的基本功；对于防御方，这是审视自身代码、筑牢第一道防线的必修课。接下来，我们将不再停留在概念层面，而是深入到代码和逻辑的细节，看看OR、AND和那个小小的引号，是如何掀起大风浪的。

2. 漏洞原理与身份验证逻辑深度拆解

要理解绕过技巧，首先必须彻底弄明白“靶子”是怎么工作的。我们从一个最经典、也最脆弱的登录场景开始。

2.1 一个典型的脆弱登录后端逻辑

假设我们有一个登录页面，前端让用户输入用户名（username）和密码（password）。后端的PHP代码（其他语言逻辑类似）可能会这样写：

$username = $_POST['username']; $password = $_POST['password']; $sql = "SELECT * FROM users WHERE username = '$username' AND password = '$password'"; $result = mysqli_query($conn, $sql); if (mysqli_num_rows($result) > 0) { // 登录成功 echo "Welcome, " . $username; } else { // 登录失败 echo "Invalid credentials!"; }

这段代码的意图很清晰：在users表中查找同时匹配username和password字段的记录。如果查询返回至少一行结果，就认为用户提供了正确的凭据。

它的致命伤在哪里？在于它直接将用户输入的$username和$password，未经任何处理就拼接进了SQL查询字符串中。用户输入从“数据”摇身一变，成了“代码”的一部分。这就是SQL注入滋生的土壤。

2.2 SQL查询的预期与扭曲

在正常登录时，如果用户输入admin和password123，拼接后的SQL语句是：

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

这条语句会去数据库里寻找用户名为admin且密码为password123的记录。找不到，就登录失败。逻辑正确。

但攻击者的思维不会停留于此。他们会想：我能否改变这个查询的“逻辑条件”，让它永远为真（True），从而绕过密码验证？答案是肯定的，而OR和AND这两个逻辑运算符，以及用于定义字符串的引号，就是实现这一目标的工具。

这里需要重温一下SQL中AND和OR的运算优先级：AND的优先级高于OR。这意味着在没有括号的情况下，A OR B AND C会被解释为A OR (B AND C)。这个特性在构造绕过语句时会被反复利用。

3. 核心绕过技巧实战解析

理解了靶子，我们就可以开始制作“钥匙”了。下面我们逐一拆解通过OR、AND和引号绕过的具体手法、原理和变种。

3.1 利用OR ‘1’=’1’实现永真条件绕过

这是SQL注入中最著名、最古老的技巧之一，但至今仍能在一些防护薄弱的应用中生效。

攻击载荷：在用户名或密码框中输入：admin' OR '1'='1当然，密码框可以留空或随意输入。

拼接后的SQL语句：

SELECT * FROM users WHERE username = 'admin' OR '1'='1' AND password = ''

根据优先级，这条语句实际等价于：

SELECT * FROM users WHERE (username = 'admin') OR ('1'='1' AND password = '')

由于‘1’=’1’是一个恒为真的条件，真 AND (password = ‘’)的结果取决于password = ‘’。但关键在于，前面已经有了username = ‘admin’ OR …。只要数据库中存在用户名为admin的记录，无论密码部分是否成立，整个OR运算的结果就已经为真了。更激进的做法是，在用户名框输入：' OR '1'='1' --（注意最后的空格）。

拼接后的语句：

SELECT * FROM users WHERE username = '' OR '1'='1' -- ' AND password = '...'

这里--（两个连字符后跟一个空格）在大多数数据库（如MySQL， SQL Server）中是单行注释符。它意味着其后的所有内容（包括原本的AND password...）都会被数据库引擎忽略。于是查询被简化为：

SELECT * FROM users WHERE username = '' OR '1'='1'

这是一个纯粹的永真条件，它会返回users表中的所有记录。通常登录逻辑只检查是否有结果返回（num_rows > 0），因此攻击者会以第一个返回的用户身份（往往是管理员）登录系统。

实操心得：在实际测试中，--（后面必须有空格）是MySQL的注释符。对于Oracle，注释符是--。有时需要尝试#（URL编码为%23）作为注释符，这在MySQL的某些场景或URL参数中更常用。如果应用有过滤，尝试将'1'='1'变形为'2' > '1'或'a' = 'a'，本质都是构造一个布尔真值。

3.2 利用AND与运算优先级进行精细绕过

当OR被过滤或应用逻辑更复杂时，AND可以登场。它的核心思路不是构造永真，而是通过运算优先级“吞掉”或“无效化”原查询中的部分条件。

攻击载荷：用户名：admin' --密码：任意值' OR '1'='1

拼接后的SQL语句：

SELECT * FROM users WHERE username = 'admin' -- ' AND password = '任意值' OR '1'='1'

同样，--注释掉了后面的密码验证部分。但如果我们不能使用注释符呢？考虑另一种情况，假设代码逻辑是检查返回的用户是否同时是“管理员角色”，查询可能是：

SELECT * FROM users WHERE username = '$user' AND password = '$pass' AND role = 'admin'

此时，攻击者可以在用户名输入：admin' AND '1'='1' AND '1'='1。 这看起来冗余，但假设防御代码愚蠢地只过滤了第一个OR，这个AND构成的永真链就能保证前面条件通过，同时后面的AND role='admin'依然生效（如果攻击者想假冒admin）。更常见的AND利用是与子查询结合获取信息，但在简单绕过中，它常作为OR的备选或组合技。

3.3 引号闭合：一切技巧的基础

无论是OR还是AND技巧，都建立在一个更基础的操作之上：引号闭合。如果无法正确闭合SQL语句中原本用于包裹字符串的单引号，所有注入代码都会因为语法错误而失效。

核心原理：后端代码期望的格式是username = ‘[用户输入]‘。攻击者输入中的第一个单引号‘，用于闭合代码中开头那个等待输入的单引号。随后，攻击者插入自己的SQL代码（如OR ‘1’=’1’）。最后，攻击者需要处理代码中原本用于闭合的那个结尾单引号。有三种主流处理方式：

1. 注释掉：使用--或#将其变为注释。
2. 使其平衡：在注入代码末尾再加一个单引号，与结尾的单引号配对，如‘ OR ‘1’=’1’。这样整个字符串部分是‘ ‘ OR ‘1’=’1’ ‘，语法正确。
3. 忽略它（导致错误）：有时在数字型注入中，或利用数据库特性，可能故意引发错误再利用，但在简单绕过中不常用。

数字型 vs 字符型注入：这是判断注入点类型的关键，也决定了引号的使用。

• 字符型：如WHERE id = ‘$input’。输入必须处理引号。我们上面讨论的都是字符型。
• 数字型：如WHERE id = $input。参数直接被当作数字处理，无需引号。绕过更简单，例如输入1 OR 1=1，语句变为WHERE id = 1 OR 1=1，永真条件直接生效，无需考虑引号闭合问题。在登录场景中，如果用户ID是数字型且用于验证，就可能存在此类漏洞。

注意事项：现代开发中，绝对、永远不要手动拼接SQL语句。使用参数化查询（Prepared Statements）或ORM框架，让数据库驱动来处理参数，从根本上将代码与数据分离，这是防御SQL注入的唯一最有效方法。所有关于过滤、转义的讨论，都应该建立在“无法使用参数化查询”的遗留系统改造前提下。

4. 手工注入实战：从探测到利用

理解了原理，我们模拟一次完整的手工注入攻击流程，目标是绕过一个登录表单。这里我们假设目标是一个简单的字符型注入漏洞。

4.1 第一步：探测与确认注入点

首先，我们需要判断输入点是否存在注入漏洞，以及是什么类型。

1. 基础探测：

   • 在用户名框输入一个单引号‘，密码随意。
   • 提交后，如果页面返回了数据库错误信息（如“You have an error in your SQL syntax...”），那么存在SQL注入漏洞的可能性极高。错误是因为我们输入的单引号破坏了SQL语法平衡。
   • 如果页面只是显示“登录失败”，没有错误信息，则需要更进一步的探测。

2. 布尔逻辑探测：

   • 输入：admin‘ AND ‘1’=’1（构造一个真条件）
   • 输入：admin‘ AND ‘1’=’2（构造一个假条件）
   • 观察页面反应。如果“真条件”返回的结果（可能是不同的错误信息、不同的响应时间、或不同的页面状态）与“假条件”返回的结果有明显区别，那么这里就存在一个基于布尔盲注的注入点。对于登录场景，真条件可能返回“用户不存在”或“密码错误”的细微差别，假条件则直接语法错误或统一错误。

3. 确定注入类型：

   • 如果输入admin‘ AND ‘1’=’1和admin‘ AND ‘1’=’2有区别，基本确定为字符型。
   • 也可以尝试数字型探测：如果用户名是数字ID，尝试1 AND 1=1和1 AND 1=2。

4.2 第二步：构造绕过载荷并实施攻击

确认是字符型注入后，我们开始构造绕过身份验证的载荷。

方案A：使用OR永真及注释符（最常用）

• 用户名：admin‘ OR ’1‘=’1‘ --
• 密码：留空或任意。
• 原理：闭合引号，插入OR ‘1’=’1‘永真条件，用--注释掉原查询中剩下的AND password=‘...’部分。期望以admin身份登录。

方案B：平衡引号法（当注释符被过滤）

• 用户名：‘ OR ’1‘=’1‘ OR ’‘=’
• 拼接后的SQL：

  SELECT * FROM users WHERE username = '' OR '1'='1' OR ''='' AND password = '...'

  • 第一个‘闭合开头引号。
  • OR ‘1’=’1‘插入永真条件。
  • OR ‘’=’’是一个技巧。它本身也是永真（空字符串等于空字符串）。更重要的是，它后面的‘用于闭合我们插入的字符串，而原SQL语句结尾的‘则与这个OR ‘’=’’后面的部分形成平衡。整个语句语法正确，且包含永真条件，可能返回所有用户。

方案C：针对特定用户的精准绕过如果知道一个存在的用户名（如testuser），可以尝试：

• 用户名：testuser‘ --
• 密码：任意。
• 原理：直接注释掉密码检查，只要testuser存在，即可登录。这常用于在已经知道部分用户信息的情况下进行横向移动。

4.3 第三步：验证结果与深入利用

成功绕过登录后，攻击才刚刚开始。攻击者通常会尝试：

1. 权限提升：登录后查看是否有修改密码、查看他人信息、访问管理后台的功能。
2. 数据库探查：如果应用在登录后仍有存在注入的点（如搜索功能、个人资料查看），可利用联合查询（UNION SELECT）获取数据库名、表名、列名，最终拖取所有用户凭证（密码哈希）、个人身份信息等敏感数据。
3. 文件系统与命令执行：在某些高权限数据库配置下（如MySQL的secure_file_priv设置不当），利用SELECT ... INTO OUTFILE写入Webshell，或利用数据库扩展功能执行系统命令。

实操心得：手工注入的过程也是与WAF（Web应用防火墙）和过滤机制斗智斗勇的过程。如果OR、AND、--、#等关键字被过滤，需要尝试大小写变形（Or，AnD）、双写绕过（OORR）、编码绕过（URL编码， Unicode编码）、内联注释（/*!OR*/）等技巧。例如，在MySQL中，/*!50000OR*/可能绕过一些简单的关键字过滤。

5. 防御策略与安全编码实践

了解了攻击，防御就有了明确的方向。所有防御都应围绕一个核心原则：绝不信任用户输入，将数据与代码分离。

5.1 根本解决方案：参数化查询（预编译语句）

这是唯一被广泛认可能从根本上防止SQL注入的方法。以PHP的PDO为例：

$username = $_POST['username']; $password = $_POST['password']; // 使用占位符（:username, :password）定义SQL结构 $sql = "SELECT * FROM users WHERE username = :username AND password = :password"; $stmt = $pdo->prepare($sql); // 将用户输入的数据以参数的形式绑定到占位符上 $stmt->bindParam(':username', $username); $stmt->bindParam(':password', $password); $stmt->execute(); if ($stmt->rowCount() > 0) { // 登录成功 }

在这个流程中，SQL语句（SELECT ... WHERE username = :username ...）首先被数据库编译成一个执行计划。:username和:password只是占位符。随后，用户输入的$username和$password值被作为纯粹的“数据”传递给这个已编译的计划。数据库引擎不会将数据解析为SQL代码的一部分，因此，即使用户输入包含‘ OR ‘1’=’1，它也只会被当作一个普通的字符串去和username字段进行比较，而不会改变查询逻辑。

5.2 辅助与补充方案

在无法立即全面改造为参数化查询的遗留系统中，可以采取以下深度防御措施：

1. 输入验证与白名单：

   • 类型检查：对于数字型ID，确保输入是整数（如使用intval()）。
   • 格式检查：对于用户名、邮箱，使用严格的正则表达式进行格式验证。
   • 长度限制：在应用层和数据库层（字段定义）对输入长度进行限制。
   • 白名单优于黑名单：定义允许的字符集合（如字母、数字、特定符号），拒绝其他所有字符，这比试图列出所有危险字符（黑名单）要可靠得多。

2. 转义处理（谨慎使用）：

   • 使用数据库驱动提供的专用转义函数，如MySQLi的mysqli_real_escape_string()。注意：它并非万能，且需确保数据库连接字符集正确（通常设为utf8mb4），否则可能存在宽字节注入等绕过风险。
   • 绝对避免自己写字符串替换函数（如str_replace(“‘“, “\'”, $input)），这极易被绕过。

3. 最小权限原则：

   • 为Web应用使用的数据库账户分配最小必要的权限。通常，登录、查询操作只需要SELECT权限。绝对不要使用root或具有FILE、EXECUTE、DROP等高级权限的账户连接数据库。这样即使发生注入，也能将损失降到最低。

4. 错误信息处理：

   • 在生产环境中，禁止向用户显示详细的数据库错误信息。应使用自定义的通用错误页面（如“系统内部错误”）。详细的错误信息是攻击者探测漏洞类型的宝贵线索。

5. 使用Web应用防火墙（WAF）：

   • WAF可以作为网络层面的一个防护层，根据规则集识别和阻断常见的SQL注入攻击模式。但它是一种缓解措施，而非根治方案。高明的攻击者可能通过混淆技术绕过WAF规则。

5.3 安全开发生命周期（SDL）集成

将安全考虑嵌入开发流程的每个阶段：

• 需求与设计阶段：明确安全需求，定义身份验证、数据验证的规范。
• 编码阶段：强制使用参数化查询的编码规范，进行结对编程或代码审查时重点关注SQL语句拼接。
• 测试阶段：进行渗透测试，使用SQLMap等自动化工具进行漏洞扫描，进行代码审计。
• 部署与运维阶段：配置安全的数据库权限，监控异常SQL查询日志。

6. 常见问题与高级绕过技巧实录

在实际渗透测试或代码审计中，你会遇到各种变种和防护措施。下面记录一些典型场景和应对技巧。

6.1 当关键字被过滤或转义时

场景：应用将OR、AND、SELECT、UNION等关键字替换为空或进行转义。

绕过技巧：

• 大小写混合：Or，aNd，SeLeCt。有些简单的过滤是大小写敏感的。
• 双写关键字：OORR，AANDND。如果过滤函数只执行一次替换，将OR替换为空，那么OORR在中间的OR被移除后，剩下的OR会拼接起来。
• 使用等价符号或函数：||可以替代OR（在某些数据库如SQLite， PostgreSQL中）。&&可以替代AND。用LIKE、IN等操作符进行变通查询。
• 注释分割：利用数据库支持的注释语法将关键字拆散。例如在MySQL中：SEL/*任意内容*/ECT。WAF可能识别完整的SELECT，但数据库引擎会忽略注释，正确执行SELECT。
• 编码绕过：对输入进行URL编码、HTML编码、十六进制编码等。例如，OR的URL编码是%4f%52。如果应用在验证后解码，而WAF在解码前检查，就可能绕过。

6.2 针对特定数据库的特性

不同数据库的SQL方言和特性不同，绕过方式也各异。

• MySQL：
  • 内联注释：/*!50000SELECT*/，/*!OR*/。/*!...*/在MySQL中会被执行，在其他数据库中被当作注释。
  • 利用&&和||：当AND和OR被过滤时可用（需在特定SQL模式下）。
  • 字符串连接函数：CONCAT(‘a‘， ‘b‘)可用于构造字符串，绕过引号过滤（如果引号被转义）。
• Microsoft SQL Server：
  • 使用+号进行字符串连接。
  • 使用EXEC(‘xp_cmdshell ...‘)执行系统命令（如果启用）。
  • 注释符为--。
• Oracle：
  • 字符串连接使用||。
  • 注释符为--。
  • 从双表查询：SELECT ‘constant‘ FROM DUAL。

6.3 盲注场景下的身份验证绕过

在无法直接看到错误信息或查询结果的“盲注”场景下，绕过登录依然可行，但更依赖于布尔逻辑或时间延迟判断。

基于布尔的盲注：

1. 提交admin‘ AND SUBSTRING(database()， 1， 1)=‘a‘ --。如果登录失败（或返回特定错误），说明数据库名第一个字母不是‘a‘。
2. 通过不断尝试，可以逐位猜解出数据库名、表名、字段值。虽然慢，但自动化工具（如SQLMap）可以高效完成。
3. 对于登录绕过，可以尝试admin‘ AND ‘1‘=‘1‘和admin‘ AND ‘1‘=‘2‘，观察“用户名不存在”和“密码错误”的细微区别，从而判断admin用户是否存在。

基于时间的盲注：

1. 提交admin‘ AND IF(SUBSTRING(database()，1，1)=‘a‘， SLEEP(5)， 0) --。
2. 如果页面响应延迟了5秒，说明条件为真。通过时间差来推断信息。
3. 在登录场景，时间盲注通常用于探测，而非直接绕过，因为需要等待。但可以构造如admin‘ OR IF(1=1， SLEEP(1)， 0) --，如果登录过程明显变慢，则说明注入存在且永真条件执行了SLEEP。

6.4 工具自动化利用：以SQLMap为例

手工注入是理解原理的基础，但在实战中，自动化工具能极大提高效率。以SQLMap检测一个登录表单为例：

1. 保存请求：使用Burp Suite拦截登录请求，将整个HTTP请求（包括Cookie、Headers）保存到一个文本文件（如login.txt）。
2. 基础检测：sqlmap -r login.txt --batch。-r表示从文件读取请求，--batch以非交互模式运行，自动选择默认选项。
3. 指定参数：如果请求中有多个参数（如user和pass），可以用-p指定，如sqlmap -r login.txt -p user，pass。
4. 获取数据：发现注入点后，可以枚举数据库--dbs，枚举表-D database_name --tables，拖取表数据-D db_name -T table_name --dump。
5. 绕过WAF：SQLMap内置了很多绕过脚本（tamper），如--tamper=space2comment（空格替换为注释），--tamper=between（用BETWEEN替换>比较符）等。

重要警告：仅在对你有合法授权测试的目标上使用SQLMap等工具！未经授权的攻击是违法行为。这些工具应在你自己搭建的靶场（如DVWA， SQLi Labs， Pikachu）中学习和练习。

7. 从靶场到实战：思维跃迁

在DVWA、Pikachu、PortSwigger靶场中练习，能让你熟悉各种注入场景和技巧。但实战环境远比靶场复杂。

实战与靶场的区别：

1. 错误信息：靶场常故意显示错误以辅助学习，实战中应用可能屏蔽所有错误，让你陷入盲注。
2. 输入点：靶场的注入点往往很明显。实战中，注入点可能隐藏在HTTP头部（如X-Forwarded-For）、Cookie、JSON或XML参数中，甚至是二次参数（服务器从获取的参数中再次解析出数据）。
3. 过滤与WAF：靶场防护级别可调但模式固定。实战中可能遇到商业WAF、自定义过滤规则、输入净化函数，需要更多的混淆和绕过技巧。
4. 业务逻辑耦合：实战中的SQL查询可能非常复杂，涉及多表联接、子查询。你的注入载荷必须保证不破坏整个查询的语法和业务逻辑，才能成功执行并获取数据。

建立实战思维：

• 全面探测：不局限于登录框。搜索框、排序参数（?order=id）、分页参数（?page=2）、任何与数据库交互的点都可能是注入点。
• 细心观察：注意页面响应的任何细微变化：响应时间、页面内容长度的差异、某个单词的出现与否、甚至是一个标点符号的改变。这都可能是盲注的判断依据。
• 保持耐心：手工盲注是一个枯燥且耗时的过程。自动化工具是帮手，但理解其原理才能调试工具 payload，应对复杂情况。
• 防御视角：最好的攻击者必须懂得防御。在尝试绕过时，多思考“如果我是开发者，这里该怎么防？”这种思维能帮你发现更多潜在的脆弱点。

手工注入的技艺，核心不在于记忆那些‘ OR ‘1’=’1的固定字符串，而在于深刻理解SQL语句的拼接逻辑、数据库的解析原理以及应用与数据库的交互方式。通过OR、AND和引号绕过身份验证，只是这门庞大技艺的入门砖。它揭示了一个朴素的真理：在安全的世界里，系统最脆弱的地方，往往存在于它对自己逻辑的过分自信，以及对用户输入的天真信任之中。修复它，也从这里开始。