深度解析Sqli-labs Less-24：mysql_escape_string()为何在二次注入中失效

当开发者第一次听说"二次注入"这个概念时，往往会感到困惑——明明已经使用了转义函数，为什么还是会出现SQL注入漏洞？这正是Sqli-labs第24关(Less-24)要向我们揭示的核心问题。本文将从一个代码审计师的视角，深入剖析这个经典案例背后的技术细节。

1. 二次注入的本质与危害

二次注入(Second-Order SQL Injection)是一种特殊的SQL注入形式，它与传统注入的最大区别在于攻击载荷的触发时机。不同于即时执行的注入攻击，二次注入的特点是：

• 延迟执行：恶意输入先被存储到数据库中，之后在另一个操作中被触发
• 绕过常规防御：在初次输入时可能通过了转义处理，但在后续使用时却成为注入点
• 高隐蔽性：由于攻击与触发分离，在常规安全扫描中难以发现

在Less-24的案例中，攻击者可以注册一个精心构造的用户名(如admin'-- )，然后在修改密码功能中触发注入。这会导致系统错误地修改了其他用户(如admin)的密码，而非攻击者自己的账户。

关键点：二次注入的破坏性往往比普通注入更大，因为它能绕过许多常规的输入过滤机制，直接操作数据库中的关键数据。

2. 函数选择失误：mysql_escape_string()的致命缺陷

Less-24的核心漏洞源于对mysql_escape_string()函数的不当使用。让我们通过对比分析来理解这个问题：

2.1 两种转义函数的本质区别

mysql_escape_string()的主要问题在于：

1. 不感知数据库连接：它无法获取当前数据库连接的字符集设置
2. 静态转义规则：使用固定的转义规则，不考虑实际字符集环境
3. 无法处理宽字符：在多字节字符集(如GBK、BIG5)下可能被绕过

php复制// 危险示例：使用mysql_escape_string()
$username = mysql_escape_string($_POST['username']);
$query = "INSERT INTO users VALUES ('$username', ...)";

// 安全示例：使用mysql_real_escape_string()
$username = mysql_real_escape_string($_POST['username'], $connection);
$query = "INSERT INTO users VALUES ('$username', ...)";

2.2 字符集如何影响注入防护

当数据库连接使用多字节字符集时，mysql_escape_string()的缺陷会变得更加明显。考虑以下场景：

1. 数据库连接使用GBK字符集
2. 攻击者输入0xbf27(在GBK中是一个合法字符)
3. mysql_escape_string()看到的是单引号(0x27)并尝试转义
4. 但由于字符集不匹配，转义后的结果可能仍然构成注入

而mysql_real_escape_string()会考虑当前连接的字符集，确保转义后的字符串在特定字符集环境下是安全的。

3. 代码审计实战：Less-24漏洞链分析

让我们深入分析Less-24中的完整漏洞链，理解二次注入是如何在代码层面发生的。

3.1 用户注册阶段的缺陷

在login_create.php中，用户注册处理代码如下：

php复制$username = mysql_escape_string($_POST['username']);
$password = mysql_escape_string($_POST['password']);
$query = "INSERT INTO users (username, password) VALUES ('$username', '$password')";

这里的关键问题是：

1. 使用了不安全的mysql_escape_string()
2. 没有对用户名做额外的格式校验
3. 允许特殊字符(如单引号)作为用户名的一部分

3.2 密码修改功能的漏洞

真正的漏洞触发点在pass_change.php：

php复制// 直接从SESSION获取用户名，未经任何处理
$username = $_SESSION['username'];
$curr_pass = mysql_real_escape_string($_POST['current_password']);
$pass = mysql_real_escape_string($_POST['password']);
$query = "UPDATE users SET PASSWORD='$pass' WHERE username='$username' AND password='$curr_pass'";

这段代码存在几个严重问题：

1. 信任边界突破：直接从SESSION中获取用户名，假设它是安全的
2. 上下文不一致：注册时使用mysql_escape_string()，修改密码时使用mysql_real_escape_string()
3. 缺乏数据一致性检查：没有验证用户名是否符合预期格式

3.3 完整的攻击路径

攻击者可以按照以下步骤利用这个漏洞：

1. 注册一个恶意用户名：admin'--
2. 系统将用户名存储为：admin'-- (单引号被转义)
3. 登录后尝试修改密码
4. 系统构建的SQL语句变为：

   sql复制UPDATE users SET PASSWORD='newpass' WHERE username='admin'-- ' AND password='current'
   

5. 注释符--使条件后半部分失效，实际修改的是admin用户的密码

4. 防御二次注入的最佳实践

基于Less-24的教训，我们可以总结出以下防御策略：

4.1 输入验证层

• 白名单验证：对用户名等字段实施严格的格式限制（如只允许字母数字）
• 长度限制：防止过长的恶意输入
• 业务逻辑校验：检查输入是否符合业务规则

php复制// 安全的用户名验证示例
if (!preg_match('/^[a-zA-Z0-9_]{3,20}$/', $username)) {
    die('Invalid username format');
}

4.2 数据处理层

• 统一转义策略：始终使用mysql_real_escape_string()或更好的预处理语句
• 上下文一致：确保数据在整个生命周期中使用相同的安全处理方式
• 字符集明确：在连接数据库后立即设置字符集

php复制// 设置字符集示例
mysql_set_charset('utf8', $connection);

4.3 输出使用层

• 最小权限原则：数据库用户只应拥有必要的最小权限
• 预处理语句：使用PDO或MySQLi的预处理功能
• 数据净化：从数据库读取数据后仍要进行适当的处理

php复制// 使用预处理语句的示例
$stmt = $pdo->prepare("UPDATE users SET PASSWORD=:pass WHERE username=:user");
$stmt->execute([':pass' => $pass, ':user' => $username]);

5. 从Less-24看安全编码原则

通过对Less-24的分析，我们可以提炼出几个关键的安全编码原则：

1. 不信任任何数据：包括来自数据库、SESSION、COOKIE等"看似安全"的来源
2. 防御深度：在每一层（输入、处理、输出）都实施适当的安全措施
3. 一致性：确保数据在整个应用生命周期中得到一致的安全处理
4. 最小化攻击面：限制用户可以输入的内容和格式
5. 安全函数选择：了解不同安全函数的适用场景和局限性

在实际开发中，建议完全避免使用mysql_escape_string()等已弃用的函数，转而使用更现代的数据库访问方式如PDO。同时，代码审计时应特别关注数据流经的各个环节，查找可能存在的信任边界突破点。