首页/资讯中心/详情

PHP代码审计实战：从原理到挖掘SQL注入漏洞

PHP代码审计实战：从原理到挖掘SQL注入漏洞
📅 发布时间：2026/6/29 1:44:59

1. 项目概述：从“黑盒”到“白盒”的攻防视角转换

做安全的朋友，尤其是刚入行的新人，一提到SQL注入，脑子里蹦出来的第一反应可能就是sqlmap、Burp Suite这些工具，对着一个输入框或者URL参数一顿“梭哈”，看到返回了数据库信息，就觉得“成了”。这确实是入门最快的方式，我们称之为“黑盒测试”——你不需要知道服务器内部是怎么写的，只管从外面往里“捅”，看哪里有反应。但如果你满足于此，那你的技术天花板可能也就到这儿了。真正的进阶，或者说想从一个“脚本小子”成长为能独立挖掘漏洞、理解漏洞根源的安全工程师，“代码审计”是你绕不开的一道坎。而PHP，作为Web开发史上应用最广泛、遗留代码也最多的语言之一，自然成了我们学习代码审计、特别是SQL注入审计的绝佳“标本”。

今天，我们就来“浅谈”一下PHP代码审计中的SQL注入。这个“浅”字，不是说内容简单，而是指我们会从一个更贴近实战、更注重思路的角度切入，不堆砌晦涩的理论，而是像解刨一只麻雀一样，带你看看那些漏洞代码到底长什么样，为什么会写成这样，以及我们该如何像猎人一样，在成千上万行代码中把它们揪出来。你会发现，当你掌握了白盒审计的思维，再回头去看那些黑盒测试，会有一种“降维打击”的感觉——你不仅能发现漏洞，更能预判漏洞可能出现的位置，甚至能推测出开发者的编码习惯。

2. SQL注入原理再认识：不仅仅是‘or’1’=’1’

在开始审计之前，我们必须把SQL注入的原理吃透，这不仅仅是知道一个万能密码' or '1'='1那么简单。从代码层面理解，SQL注入的本质是：程序将用户可控的数据，未经充分处理，直接拼接到了SQL查询语句中，从而改变了原语句的语义。

2.1 漏洞产生的核心链条

这个链条非常清晰：

  1. 用户输入可控：来自$_GET，$_POST，$_REQUEST，$_COOKIE，甚至$_SERVER中部分字段（如HTTP头）的数据。
  2. 拼接SQL语句：PHP代码中，使用字符串连接符（.）或双引号字符串内插，将这些数据直接嵌入到SQL字符串中。
  3. 语句被执行：拼接好的字符串被传递给mysql_query()，mysqli_query()或PDO的query()等方法执行。

举个例子，一段典型的漏洞代码：

$id = $_GET['id']; $sql = "SELECT * FROM users WHERE id = $id"; $result = mysql_query($sql);

当用户访问page.php?id=1时，SQL语句是SELECT * FROM users WHERE id = 1，没问题。但当攻击者访问page.php?id=1 UNION SELECT 1,2,database()时，语句就变成了SELECT * FROM users WHERE id = 1 UNION SELECT 1,2,database()。因为$id被直接拼接，攻击者输入的UNION SELECT...不再是数据，而成了SQL语法的一部分，这就是注入。

2.2 注入点类型与审计关注点

在审计时，我们不仅要找明显的数字型、字符型注入，更要关注那些不那么直观的“二次注入”、“宽字节注入”等。

  • 数字型注入：如上例，参数直接嵌入，无需闭合引号。审计时关注intval()、is_numeric()等过滤函数是否缺失。
  • 字符型注入：参数被引号包裹，如WHERE name='$name'。攻击者需要先闭合前引号。审计时需关注addslashes()、mysql_real_escape_string()在特定字符集（如GBK）下可能失效导致的宽字节注入。
  • 搜索型注入：参数用于LIKE子句，如WHERE title LIKE '%$keyword%'。这里的通配符%和_本身也可能被滥用。
  • ORDER BY注入：ORDER BY $field $order，这里$field和$order通常无法用预编译语句绑定，需要白名单过滤。
  • 二次注入：数据第一次入库时被转义（如变成O\'Brien），但取出后再次用于拼接SQL时，转义符被去除（变回O'Brien），造成注入。这是审计中最容易遗漏的，需要跟踪数据的完整生命周期。

注意：很多新手会认为用了addslashes()就高枕无忧了。但在数据库连接字符集为GBK等宽字符集时，可能存在宽字节注入（例如输入%df%27，经过addslashes变成%df%5c%27，%df%5c在GBK下可能被解析为一个汉字，从而“吃掉”转义反斜杠，使单引号逃逸）。审计老系统时，这是一个关键检查点。

3. 审计方法论：从“全局扫描”到“定点深挖”

面对一个完整的PHP项目，尤其是那些动辄几十万行的CMS或老旧系统，不能像无头苍蝇一样乱撞。需要有一套高效的审计流程。

3.1 信息收集与入口点定位

首先，不要急着看代码。

  1. 了解项目结构：看看是MVC框架（如ThinkPHP, Laravel, Yii）还是传统混编脚本。框架通常有统一的数据库操作层，而传统脚本可能每个文件都是独立的风险点。
  2. 识别用户输入入口：全局搜索$_GET，$_POST，$_REQUEST，$_COOKIE，$_SERVER['HTTP_']，$_FILES。这是所有风险的源头。
  3. 定位SQL执行函数：搜索mysql_query，mysqli_query，mysqli::query，pg_query，PDO::query，PDO::exec，以及ORM框架的execute、find、select等方法。一些框架封装了自己的方法，如$db->getOne()。

3.2 正向追踪与反向追踪

这是两种核心的代码跟踪思路。

  • 正向追踪（从输入到执行）：选定一个用户输入变量（如$_GET['id']），在代码编辑器中查看它的所有引用，跟踪它流经了哪些函数、是否被过滤、最终是否被拼接到SQL语句中。这种方法适合审计功能点明确的模块。
  • 反向追踪（从执行到输入）：找到一个SQL执行函数，向上回溯，看这个SQL语句字符串（$sql）是如何构建的，其中的变量从何而来，在赋值过程中是否经过安全处理。这种方法能系统性地发现所有SQL执行点的问题，是全面审计的常用手段。

3.3 关键函数与过滤机制审计

审计不是只看有没有拼接，更要看过滤是否到位、是否可被绕过。

  1. 过滤函数审计：

    • intval()，floatval()：用于数字型参数，但要注意intval('1 union select')结果是1，看似安全，但如果SQL语句是...id=$id，攻击者传入1 union select，intval后$id为1，但原始的$_GET['id']可能在其他地方被使用。审计时要确认过滤后的变量被使用，而非原始输入。
    • addslashes()，mysql_real_escape_string()：用于转义特殊字符。审计点在于：①是否在所有涉及数据库操作的地方都用了？②数据库连接字符集是否统一（防宽字节）？③是否在magic_quotes_gpc开启的环境下又做了一次转义，导致双重转义？
    • htmlspecialchars()：这是防XSS的，对SQL注入无效！但很多开发者会混淆，看到用了这个函数就以为安全了，审计时要特别注意。
    • preg_replace()，str_replace()：自定义过滤。例如$id = str_replace("union", "", $_GET['id'])。这种过滤极其脆弱，大小写、双写（uniunionon）、注释分割都可能绕过。审计时对任何基于黑名单字符串替换的过滤都要持高度怀疑态度。

  2. 预编译语句审计： 使用PDO或MySQLi的预编译（参数绑定）是防止SQL注入的最佳实践。但预编译也可能被误用！

    // 错误用法：拼接后再准备 $sql = "SELECT * FROM users WHERE id = " . $_GET['id']; // 拼接发生在prepare之前！ $stmt = $pdo->prepare($sql); // 注入已发生，prepare无力回天 $stmt->execute(); // 正确用法：用占位符 $sql = "SELECT * FROM users WHERE id = ?"; $stmt = $pdo->prepare($sql); $stmt->execute([$_GET['id']]); // 数据作为参数绑定，安全

    审计关键：检查prepare()的调用是否在字符串拼接之后？占位符（?或:name）是否用于所有用户输入的位置？ORDER BY等动态从句是否错误地使用了绑定？

4. 实战案例拆解：从简单到复杂的注入挖掘

我们通过几个典型场景，把上述方法论用起来。

4.1 案例一：直接拼接的显性注入

这是最“低级”但也最常见于老旧代码中的漏洞。

// file: user/profile.php include('config.php'); // 包含数据库连接 $username = $_SESSION['username']; // 看起来来自session，似乎安全？ $sql = "SELECT email, phone FROM members WHERE username = '$username'"; $res = mysql_query($sql);

审计过程：

  1. 找到SQL执行点mysql_query($sql)。
  2. 回溯$sql，发现由字符串"SELECT ... WHERE username = '$username'"拼接而成。
  3. 追踪$username来源，发现是$_SESSION['username']。
  4. 关键问题：$_SESSION数据是否绝对可信？username是否在用户登录时从数据库取出后未经过滤就存入了$_SESSION？如果注册或登录功能存在注入，攻击者就可以将一个恶意的用户名（如admin'--）写入数据库，进而当该用户登录后，这个恶意数据就从$_SESSION流入此处，造成存储型+二次注入。审计时绝不能忽视$_SESSION和$_COOKIE的数据源。

4.2 案例二：过滤不全与绕过

// file: admin/search.php $keyword = $_POST['keyword']; // 开发者试图过滤单引号 $keyword = str_replace("'", "", $keyword); // 以及一些SQL关键字 $keyword = preg_replace("/union|select|from|where|or|and/i", "", $keyword); $sql = "SELECT * FROM articles WHERE title LIKE '%$keyword%'";

审计与绕过思路：

  1. 过滤逻辑分析：先移除单引号，再用正则移除关键字。顺序有问题吗？有！如果输入'union，先移除单引号变成union，再被关键字过滤移除，最终为空，似乎安全。但这里存在双写绕过和注释绕过。
  2. 双写绕过：输入ununionion selselectect，经过preg_replace后，中间的union和select被移除，两边的字符重新组合，又形成了union select。
  3. 利用LIKE特性：LIKE子句的通配符_可以匹配单个字符。如果知道管理员用户叫admin，可以尝试输入a_m_n，可能匹配出来。这虽然不是典型的注入，但属于同一输入点引发的安全问题。
  4. 更隐蔽的注入：过滤了union和select，但没过滤updatexml，extractvalue等报错注入函数。可以尝试' and updatexml(1,concat(0x7e,(version())),1) and '1'='1。由于单引号被移除，注入payload需要重新构造，例如利用数字运算或直接注入到不需要引号的上下文（如果存在）。

4.3 案例三：框架下的意外注入

很多人认为用了现代框架（如Laravel）就绝对安全。未必。

// Laravel 中可能存在风险的写法 $orderField = Request::input('order', 'id'); $users = DB::table('users') ->orderByRaw($orderField . ' ' . Request::input('dir', 'asc')) ->get();

审计点：orderByRaw方法接收原生SQL字符串片段。这里将用户输入的order和dir直接拼接，是典型的ORDER BY注入。在Laravel中，orderBy()方法本身支持参数绑定，但orderByRaw()需要谨慎使用。审计框架代码时，重点就是找这些Raw（原生）表达式的方法：whereRaw，selectRaw，havingRaw等。

4.4 案例四：复杂业务逻辑中的隐性注入

这种漏洞藏得最深，需要理解业务。

// 一个文章评论审核功能 function approveComment($commentId) { global $db; // 先查出评论详情 $sql = "SELECT article_id, user_id FROM comments WHERE id = " . intval($commentId); $comment = $db->getRow($sql); // 根据文章ID，更新文章表的评论数 $updateSql = "UPDATE articles SET comment_count = comment_count + 1 WHERE id = " . $comment['article_id']; $db->query($updateSql); // 标记评论为已审核 $db->query("UPDATE comments SET approved = 1 WHERE id = " . intval($commentId)); }

表面看：$commentId用了intval，似乎安全。深入审计：$comment['article_id']来自第一次查询的数据库。如果攻击者能控制comments表中某条记录的article_id字段（例如通过另一个提交评论的、存在注入的功能点），他就可以将article_id设置为恶意的SQL片段，如1; DROP TABLE users --。那么，当管理员审核这条评论时，第二条UPDATE语句就会变成UPDATE articles ... WHERE id = 1; DROP TABLE users --，导致注入。这就是典型的二次注入，数据源不是直接的用户输入，而是从数据库取出的、曾被污染的数据。

5. 自动化辅助与手工验证

对于大型项目，纯手工审计效率太低。需要借助工具进行初步筛选。

  1. 静态代码分析工具（SAST）：

    • RIPS：老牌PHP静态分析工具，专挖漏洞，对SQL注入、XSS等模式识别很好。
    • SonarQube (with PHP Plugin)：更侧重代码质量，但安全规则也能发现很多问题。
    • Phan / Psalm：这些类型检查工具有时也能发现一些可疑的字符串拼接模式。
    • 局限性：工具会产生大量误报（把安全的代码也报出来）和漏报（找不到复杂的漏洞）。它只是一个“线索生成器”，绝不能替代人工分析。审计的核心永远是人的逻辑思维。

  2. 手工验证流程： 工具报出一个疑似点后，我们需要手动验证：

    • 确认数据流：是否真的存在从用户输入到SQL拼接的完整、可通达路径？中间是否有条件判断可能阻断？
    • 确认过滤有效性：过滤函数是否真的能阻挡所有攻击向量？是否存在绕过可能？
    • 构造PoC：在测试环境中，尝试构造真实的Payload，验证漏洞是否可被利用。这是最终确认环节。

6. 防御方案与审计中的修复建议

审计的最终目的不仅是找漏洞，更是为了修复。在审计报告中，给出具体、可操作的修复建议至关重要。

  1. 首选：参数化查询（预编译）

    • PDO示例：
      $stmt = $pdo->prepare("SELECT * FROM users WHERE email = :email AND status = :status"); $stmt->execute(['email' => $email, 'status' => $status]);
    • MySQLi示例：
      $stmt = $mysqli->prepare("SELECT * FROM users WHERE email = ?"); $stmt->bind_param("s", $email); $stmt->execute();
    • 审计修复点：找到所有拼接点，重写为预编译形式。注意LIKE查询的占位符处理：LIKE ?， 绑定参数时为"%{$keyword}%"。

  2. 次选：严格的白名单过滤对于无法使用参数绑定的场景，如ORDER BY字段名、表名、列名，必须使用白名单。

    $allowedOrders = ['id', 'name', 'created_at']; $orderField = in_array($_GET['order'], $allowedOrders) ? $_GET['order'] : 'id'; $sql = "SELECT * FROM table ORDER BY $orderField";

    绝对禁止使用黑名单过滤。

  3. 最小权限原则在审计报告中也应提及：连接数据库的账号不应具有DROP，FILE，GRANT等高级权限，以限制注入成功后的危害。

  4. 框架的最佳实践对于使用框架的项目，建议升级到最新稳定版，并检查其安全配置。例如，Laravel的查询构造器默认使用参数绑定，但需确保没有误用raw方法。

7. 建立持续的安全代码意识

代码审计不是一次性的任务，而应该融入开发流程。作为审计者，在完成项目后，可以推动一些长效措施：

  • 代码规范：制定团队SQL编写规范，强制要求使用预编译或ORM的安全方法。
  • 安全培训：针对审计中发现的共性错误，对开发团队进行培训。
  • 自动化扫描集成：将SAST工具集成到CI/CD流水线中，每次提交都自动进行基础扫描。
  • 定期人工审计：对核心业务模块、旧有代码，安排周期性的深度人工审计。

回过头看，PHP代码审计中的SQL注入挖掘，就像一场在逻辑迷宫中寻找设计缺陷的探险。它考验的不仅是你对PHP语法和SQL语法的熟悉程度，更是你对程序数据流、业务逻辑的理解深度，以及一种“攻击者思维”——永远假设输入是恶意的，永远质疑数据是否被充分净化。从一个个$_GET开始，追踪变量的一生，直到它消失在数据库引擎中，这其中的每一步，都可能藏着攻防的玄机。掌握了这套方法，你手里拿着的就不再是一份枯燥的源代码，而是一张布满线索的藏宝图，或者更确切地说，是一份需要你来修补的防御蓝图。