如何修复Drupal模块中的SQL注入问题-SQL-PHP中文网

必须使用参数化查询并配合白名单校验，禁用字符串拼接sql；drupal核心漏洞cve-2026-9082要求升级补丁、关闭json接口，并严查自定义模块中绕过查询层的原生sql调用。

如何修复drupal模块中的sql注入问题

直接拼接用户输入进SQL语句，哪怕只在一处发生，就等于给攻击者留了后门——Drupal 7.x 的 expandArguments、11.x 的 PostgreSQL LOWER() 条件构造、甚至自定义模块里一个 db_query("SELECT * FROM {table} WHERE id = " . $_GET['id'])，都是现成的入口。

用参数化查询替代字符串拼接

Drupal 自带的查询 API 天然支持参数化，但必须显式传入占位符和参数数组，不能靠“看起来像”来蒙混过关。常见错误是把变量直接插进 SQL 字符串里，再套一层 db_query() 就以为安全了。

db_query("SELECT name FROM {users} WHERE uid = " . $uid) ❌ —— 无论 $uid 是否经过 intval()，都可能被绕过（如科学计数法、十六进制）
db_query("SELECT name FROM {users} WHERE uid = :uid", [':uid' => $uid]) ✅ —— 数据与语句彻底分离，数据库引擎不解析占位符内容
PostgreSQL 场景下注意：Drupal 11.x 的 IN 查询若用数组键名动态生成占位符（如 $key . '_' . $i），会触发 CVE-2026-9082 —— 必须改用 db_select() 或 EntityQuery，禁用原始 SQL 构造

白名单校验非值类动态内容

表名、字段名、排序方向（ASC/DESC）、JOIN 表别名等，无法用参数化处理，必须走白名单机制。硬编码或配置化比运行时拼接更可靠。

文心大模型

文心大模型是百度推出的知识增强大模型体系。

下载

避免：$query = "SELECT * FROM {" . $_GET['table'] . "}"; —— 即使过滤了 ; 和单引号，仍可能注入 users-- 或 users%00
推荐：$allowed_tables = ['node', 'users', 'taxonomy_term_data']; if (!in_array($_GET['table'], $allowed_tables)) { throw new \Exception('Invalid table'); }
排序字段同理：$sort_field = in_array($_GET['sort'], ['title', 'created', 'uid']) ? $_GET['sort'] : 'created';，再拼进 ORDER BY $sort_field

检查自定义模块是否绕过 Drupal 查询层

很多老模块为兼容旧版或图省事，直接调用 PHP 原生 mysqli_query() 或 PDO::query()，完全脱离 Drupal 的参数化保护机制。这类代码必须重写。

搜出所有 mysqli_、PDO::、pg_query(、mysql_query( 调用，逐行替换为 db_query() 或 db_select()
特别注意钩子函数（如 hook_node_load()）里嵌套的原始 SQL —— 这些地方常被忽略，却是攻击链关键一环
若必须用原生驱动（如对接外部库），至少强制使用 prepare() + execute()，且禁止拼接任何用户输入到 SQL 字符串中

升级补丁并验证 PostgreSQL 特定路径

CVE-2026-9082 暴露了一个残酷事实：即使你代码全用参数化，Drupal 核心抽象层本身也可能有漏洞。PostgreSQL 用户必须确认已升级到对应安全版本，并关闭非必要 JSON 接口。

检查 drush status 或后台“关于”页，确认 Drupal 版本 ≥ 对应修复版本（如 11.3.10、10.6.9）
禁用未使用的 JSON 入口：drush config-set system.performance cache.page.max_age 0 后，手动移除 /user/login?_format=json 路由权限（或通过 hook_menu_alter() 移除）
临时防御：在 settings.php 中添加 $databases['default']['default']['init_commands']['no_multi_statement'] = "SET session_replication_role = 'replica';";，可阻断多语句执行（但非根本解）

最易被忽略的是“信任数组键名”这个点——它不报错、不抛异常，却让 IN 查询变成注入温床。修复时别只盯着 WHERE 子句里的值，得翻到条件构建逻辑深处看键名来源。