1. 项目概述：一次典型的登录绕过实战剖析

最近在墨者靶场里又刷了一遍SQL注入的登录绕过关卡，这玩意儿可以说是Web安全入门最经典的“敲门砖”了。很多新手朋友一听到“SQL注入”、“登录绕过”这些词，可能会觉得既神秘又复杂，感觉是黑客大神才能玩转的技术。其实不然，它的核心原理非常直接，就是利用程序对用户输入数据的“信任”，通过构造一些特殊的输入，让程序原本要执行的SQL语句“跑偏”，从而达到绕过正常登录校验的目的。我这次在墨者靶场里，就是利用这个原理，成功绕过了登录验证，直接进入了后台。整个过程就像是在和程序的设计者进行一次逻辑对话，你找到了他逻辑里的一个“口误”，然后巧妙地利用了这个口误。这篇文章，我就来详细拆解一下这次实战的全过程，从漏洞原理、手工探测、Payload构造，到最后的防御思路，我会用最直白的话讲清楚，哪怕你之前只听说过SQL注入这个名字，也能跟着一步步操作下来，理解背后的门道。这不仅是通关一个靶场，更是理解Web安全基础逻辑的绝佳途径。

2. 漏洞原理与场景深度拆解

2.1 SQL注入登录绕过的核心逻辑

要理解登录绕过，首先得明白一个正常的登录流程是怎么工作的。当我们在一个登录框输入用户名和密码，点击提交后，后台程序（比如用PHP、Java、Python写的）通常会做这样一件事：它会把我们输入的用户名和密码，拼接到一条查询数据库的SQL语句里。这条语句大概长这样：

SELECT * FROM users WHERE username = ‘输入的用户名’ AND password = ‘输入的密码’

程序的本意是：去数据库的users表里，找一找有没有同时满足“用户名等于A”且“密码等于B”的记录。如果能找到一条，说明用户名密码正确，登录成功；如果找不到，就登录失败。

漏洞就出在这个“拼接”的过程上。如果程序在拼接时，没有对我们输入的内容进行严格的检查和过滤，那么攻击者输入的就不仅仅是普通的用户名和密码了，而是一段可以“改变”整条SQL语句逻辑的“代码”。

举个例子，假设我们在用户名输入框里输入：admin’ --（注意最后有一个空格），密码框可以随便输入或者留空。那么，这条SQL语句被拼接后，就变成了：

SELECT * FROM users WHERE username = ‘admin’ -- ’ AND password = ‘随便什么’

这里的关键是--，它在SQL中是单行注释符，意思是--之后的所有内容都会被数据库忽略，不再作为SQL命令执行。所以，上面那条语句实际执行的效果就变成了：

SELECT * FROM users WHERE username = ‘admin’

看到了吗？密码验证部分AND password = …整个被注释掉了！数据库只会去检查有没有用户名叫admin，根本不管密码是什么。只要users表里存在admin这个用户，这条查询就能返回结果，程序就会认为登录成功。这就是最经典、最基础的SQL注入登录绕过。

注意：不同的数据库注释符可能不同。MySQL常用--（后面有个空格）或#，Oracle用--，SQL Server也用--。在实战探测时，需要根据目标数据库类型进行尝试。

2.2 墨者靶场环境与漏洞点分析

墨者靶场的这个“SQL注入漏洞测试(登录绕过)”关卡，模拟的就是一个存在上述漏洞的简易登录系统。它的前端就是一个典型的登录页面，有用户名和密码两个输入框。作为攻击者，我们的目标不是去猜解正确的用户名和密码，而是利用SQL注入漏洞，让程序在不知道正确密码的情况下，依然返回一个“登录成功”的结果。

根据经验，这类靶场为了教学目的，漏洞点通常设计得比较明显。漏洞大概率存在于用户名或密码参数的处理环节，程序直接将其拼接进SQL语句，且没有进行任何过滤。我们的任务就是通过手工输入各种测试Payload（有效载荷），观察系统的反应，来验证漏洞是否存在、并最终构造出能成功绕过的Payload。

在开始实操前，我们必须建立一个重要的思维：不要把它当成一个黑盒乱试。每一次输入，都是在向目标程序发送一个“问题”，通过它的“回答”（比如登录成功/失败、报错信息），我们来推断它内部的SQL语句大概长什么样。这是一个逻辑推理的过程。

3. 手工探测与漏洞验证流程

3.1 初步探测与漏洞存在性确认

拿到一个登录框，第一步不是直接上复杂的绕过Payload，而是进行基础探测，确认这里是否存在SQL注入漏洞，以及漏洞可能在哪里。

1. 基础逻辑测试：我们首先尝试最经典的‘（单引号）测试。在用户名框输入一个单引号，比如输入‘，密码框随意输入123，然后点击登录。

• 如果页面出现数据库错误信息（比如“You have an error in your SQL syntax…”），这是一个强烈的信号！说明我们输入的单引号破坏了原SQL语句的语法结构，导致数据库执行出错并报错。这几乎可以肯定存在SQL注入漏洞，并且程序开启了错误回显，这非常有利于我们后续的注入。
• 如果页面只是提示“登录失败”，没有具体错误，这也不代表没有漏洞。可能是程序做了简单的错误处理，屏蔽了报错。我们需要进行下一步测试。

2. 逻辑绕过测试：尝试使用永真条件。比如，在用户名框输入：admin‘ or ‘1’=‘1，密码框同样随意输入或留空。 拼接后的SQL语句可能变为：SELECT * FROM users WHERE username = ‘admin‘ or ‘1’=‘1’ AND password = ‘xxx’由于‘1’=‘1‘这个条件永远为真（True），那么整个WHERE子句的结果就取决于or的逻辑。只要users表里有任意用户，或者admin用户存在，这条查询就很可能返回结果，导致绕过。如果使用‘ or 1=1 --，则能更干净地注释掉后面所有条件。

3. 注释符测试：这是针对登录绕过最直接的测试。在用户名框尝试输入：

• admin‘ --（注意--后有一个空格）
• admin‘ #（如果后端是MySQL，且过滤了--，可以尝试#，在URL中可能需要编码为%23）

如果输入admin‘ --后登录成功，而输入错误的admin‘（后面不带注释符）失败，那基本可以确定漏洞存在且可利用。

在墨者靶场中，我按照这个流程进行测试。当我输入admin‘ --时，系统直接跳转到了登录成功的页面。这说明靶场环境存在典型的字符型SQL注入漏洞，并且可以通过注释符来绕过密码验证。

3.2 确定注入点与数据库类型

虽然我们已经绕过了，但为了更深入理解，我们继续探测。登录绕过通常只需要找到一处注入点即可，但完整的SQL注入攻击需要了解更多信息。

1. 判断注入参数：我们已经知道用户名参数存在注入。有时密码参数也可能存在。可以单独在密码框进行类似的单引号、永真式测试。

2. 判断数据库类型：不同数据库的函数、语法稍有不同。可以通过报错信息或者特定函数来猜。

• 输入admin‘ and ‘1’=‘1和admin‘ and ‘1’=‘2，观察页面返回是否不同。如果不同，说明条件语句被执行，是字符型注入。
• 尝试数据库特有的函数，如：
  • version()： MySQL/PostgreSQL
  • @@version： MySQL/SQL Server
  • dbms_random.value： Oracle 例如输入：admin‘ and substring(version(),1,1)=‘5‘ --，如果页面正常，可能表示数据库版本号第一位是5（如MySQL 5.x）。

在本次墨者靶场的场景中，由于目标是快速登录绕过，且使用--注释符成功，可以初步推断后端数据库可能是MySQL、SQL Server或Oracle等支持--注释的。结合靶场常见设置，是MySQL的可能性较大。这一步的判断对于后续如果需要进行更深入的联合查询（Union Select）获取数据时，选择正确的函数和语法至关重要。

4. 构造有效Payload与实战绕过

4.1 通用Payload构造思路

在确认漏洞存在后，我们需要系统地构造能稳定实现登录绕过的Payload。核心思路是：让WHERE子句的查询条件恒为真，并优雅地处理掉原语句中我们不需要的部分（尤其是密码验证）。

以下是一些经典且高效的Payload，你可以把它们看作是一个“武器库”：

1. 注释符终结法（最常用、最干净）：

• admin‘ --（经典之选，注意空格）
• admin‘ #（MySQL中#也是注释符）
• admin‘/*任意内容*/（使用多行注释/* */，可以包裹掉后面的密码验证部分）

2. 永真条件法（无需猜测管理员用户名）：

• ‘ or 1=1 --
• ‘ or ‘a‘=‘a‘ --
• ‘ or ‘1‘ --这个Payload的精妙之处在于，它不依赖特定的用户名（如admin）。‘先闭合了用户名的前引号，然后or 1=1提供了一个永远为真的条件，最后--注释掉后续所有。只要users表里有任何一条记录，这个查询就会返回结果（通常是第一条），程序就可能让你以第一个用户的身份登录进去。

3. 联合查询法（更高级，可指定登录用户）：如果我们需要以特定用户（如admin）身份登录，且知道该用户的id，可以使用联合查询（Union Select）来“伪造”一条查询结果。但这需要我们知道表结构和列数，步骤稍复杂：

• 先确定查询的列数：‘ order by 3 --（不断递增数字，直到页面出错，出错前的数字就是列数）。
• 假设列数为3，且id,username,password分别是第1,2,3列。我们可以构造：‘ union select 1, ‘admin‘, ‘dummy_password‘ from users where username=‘admin‘ --这个Payload会联合一条我们自定义的记录（id=1,username=‘admin‘,password=‘dummy_password‘）到原查询结果中。如果程序登录逻辑是取查询结果的第一条，我们就能以admin身份登录。

4.2 墨者靶场实战绕过记录

在墨者靶场，我采用了最直接的“注释符终结法”。操作步骤如下：

1. 打开靶场登录页面。页面非常简洁，只有用户名、密码两个输入框和一个提交按钮。
2. 第一次尝试（基础测试）：在用户名框输入admin‘（一个单引号），密码框输入test，点击登录。页面提示“登录失败”，但没有数据库报错。这说明程序可能做了基础错误处理，或者单引号被转义了？我们需要进一步测试。
3. 第二次尝试（注释符测试）：在用户名框输入admin‘ --（admin后面跟一个单引号，两个减号，一个空格），密码框留空或随意输入。点击登录。
4. 结果：页面成功跳转！显示“登录成功，欢迎您，admin！”之类的提示。这意味着注入成功，我们绕过了密码验证，以admin身份进入了系统。

为什么成功了？我们来还原后台可能的SQL语句： 原语句：SELECT * FROM users WHERE username = ‘[用户输入]‘ AND password = ‘[密码输入]‘我们输入后，语句变为：SELECT * FROM users WHERE username = ‘admin‘ -- ‘ AND password = ‘…‘--后面的密码验证部分被注释，实际执行：SELECT * FROM users WHERE username = ‘admin‘数据库顺利找到了admin用户，返回结果，登录成功。

实操心得：在输入--时，那个空格至关重要。在很多数据库（如MySQL）中，--后面必须紧跟一个空格或控制字符（如换行）才是有效的注释符。很多新手在这里踩坑，输入admin‘--（没有空格），导致绕过失败。在浏览器表单中直接输入空格是没问题的，但如果是在URL中进行GET请求注入，空格需要编码为+或%20，而--后的空格有时会被忽略，更稳妥的做法是使用#（在URL中编码为%23）。

5. 漏洞根源与防御方案探讨

5.1 为什么会产生这种漏洞？

这个看似简单的漏洞，根源在于开发过程中的几个常见疏忽：

1. 信任用户输入：这是万恶之源。程序将用户输入（来自表单、URL参数、Cookie等）直接视为可信数据，未经任何处理就拼接进SQL语句。
2. 字符串拼接构造SQL：使用原始的字符串连接方式来组装SQL命令（如“SELECT * FROM users WHERE username = ‘” + username + “’ AND …”），而不是使用安全的参数化方法。
3. 缺乏输入验证与过滤：没有对输入进行严格的类型检查、长度限制、危险字符（如单引号、分号、注释符）过滤或转义。
4. 错误信息泄露：将详细的数据库错误信息直接显示给前端用户，这为攻击者提供了探测漏洞的“灯塔”。

5.2 如何从根本上防御SQL注入？

防御的核心原则是：“数据与代码分离”。永远不要将用户输入的数据当作SQL代码的一部分来执行。

1. 使用预编译语句（参数化查询）——首选方案这是目前最有效、最根本的防御手段。它的原理是SQL语句的模板（结构）预先被数据库编译，用户输入的数据仅仅作为“参数”传入，不会被当作SQL语法的一部分进行解析。

• Java (JDBC):

  String sql = “SELECT * FROM users WHERE username = ? AND password = ?”; PreparedStatement stmt = connection.prepareStatement(sql); stmt.setString(1, username); // 参数1， 即使username包含‘ or 1=1 --，也会被当作普通字符串处理 stmt.setString(2, password); // 参数2 ResultSet rs = stmt.executeQuery();

• Python (PyMySQL/sqlite3):

  cursor.execute(“SELECT * FROM users WHERE username = %s AND password = %s”, (username, password))

• PHP (PDO):

  $stmt = $pdo->prepare(“SELECT * FROM users WHERE username = :user AND password = :pass”); $stmt->execute([‘:user’ => $username, ‘:pass’ => $password]);

2. 使用安全的ORM框架对象关系映射（ORM）框架如Hibernate（Java）、Entity Framework（.NET）、SQLAlchemy（Python）等，它们底层通常使用参数化查询，能有效避免手写SQL导致的注入问题。

3. 严格的输入验证与过滤

• 白名单验证：对于已知的、有限集合的输入（如性别、状态码），只接受预定义的值。
• 类型与格式检查：确保输入符合预期类型（如数字、邮箱格式）。
• 长度限制：防止过长的输入导致缓冲区溢出等问题。
• 危险字符转义：如果因历史原因必须拼接SQL（强烈不推荐），必须对输入中的特殊字符进行转义。例如，在MySQL中，使用mysqli_real_escape_string()函数。但请注意，转义并非绝对安全，在某些复杂的字符编码场景下可能被绕过。

4. 最小权限原则为Web应用连接数据库的账户分配最小的、必要的权限。例如，只授予SELECT权限，不授予DROP、UPDATE、DELETE等权限。这样即使发生注入，危害也能被限制。

5. 避免详细的错误回显在生产环境中，禁止将数据库的详细错误信息直接展示给用户。应使用统一的、模糊的错误提示页面，并将详细错误记录到服务器日志中供管理员查看。

6. 常见问题与排查技巧实录

在实际测试和教学过程中，我遇到过很多小伙伴提出的典型问题。这里整理一下，希望能帮你避开这些坑。

Q1: 我输入了admin‘ --，为什么还是提示登录失败？A1: 首先，检查--后面是否有空格。其次，尝试其他注释符，如#（在URL中需编码为%23）或/*注释内容*/。再者，目标可能不是字符型注入，或者是数字型注入。尝试在用户名框输入1 or 1=1 --（假设用户名字段是数字ID）。最后，可能漏洞不在用户名参数，而在密码参数，或者程序对单引号进行了转义（如将‘转换为\’），这时可以尝试双写绕过admin‘‘ --，或者使用宽字节等高级技巧（这超出了基础绕过的范畴）。

Q2: 我看到了数据库报错信息，但不知道下一步该怎么利用？A2: 报错信息是黄金！它不仅能确认漏洞，还能透露数据库类型、表名、列名等信息。关注错误信息中的关键词，如“MySQL”、“SQLite”、“near ‘xxx’ at line 1”。你可以利用报错注入函数，如MySQL的updatexml()、extractvalue()，来主动触发错误并回显我们想要查询的数据。例如：admin‘ and updatexml(1, concat(0x7e, (select database()), 0x7e), 1) --，可能会在错误信息中看到数据库名。

Q3: 使用‘ or 1=1 --登录后，进入的不是admin账户，而是另一个普通用户，怎么办？A3: 这很正常。‘ or 1=1 --会让查询返回users表中所有满足1=1（即所有）的记录。程序登录逻辑通常是取查询结果集的第一条。如果admin不是表中的第一条记录，你就登录了其他账户。如果你想指定登录admin，可以尝试：

• admin‘ --（前提是知道用户名）
• ‘ or username=‘admin‘ --（前提是知道用户名字段叫username）
• 使用联合查询（Union Select）来精确控制返回的数据，如前文所述。

Q4: 在测试时，页面突然无法访问了，是被封IP了吗？A4: 在实战中，频繁的异常请求可能触发目标网站的WAF（Web应用防火墙）或入侵检测系统的规则，导致你的IP被暂时封锁。在靶场环境中，一般不会。如果是在授权测试的真实环境，需要控制测试频率，使用代理池，并严格遵守测试范围。在靶场中如果遇到，可以尝试重置靶场环境或等待一段时间。

Q5: 我学会了手工注入，但感觉效率很低，有工具吗？A5: 有的。Sqlmap是一款自动化SQL注入测试的开源神器。对于登录绕过这种简单的注入点，使用Sqlmap可以快速验证并获取数据。基本命令如：sqlmap -u “http://target.com/login.php” --data “username=admin&password=pass” --technique=B --current-db。但强烈建议先精通手工注入的原理和过程，再使用工具。工具是手臂，原理才是大脑。不懂原理，你看不懂工具的 payload，也应对不了稍微复杂一点的WAF。

手工绕过登录只是SQL注入的“初体验”。真正掌握SQL注入，需要深入理解数据库查询、联合查询、布尔盲注、时间盲注、报错注入、堆叠查询等多种技术，并能根据目标的反应灵活调整Payload。墨者靶场的这个关卡，就像一把钥匙，为你打开了Web安全这扇大门的第一道锁。门后的世界更广阔，也更有挑战性。