如何修复Express查询接口的SQL注入漏洞-SQL-PHP中文网

参数化查询必须用数组传参，哪怕只有一个值；表名、字段名、order by等结构部分需白名单校验；入口校验应强制类型转换与长度限制；所有分支路径包括日志和错误响应均需过滤敏感内容。

如何修复express查询接口的sql注入漏洞

参数化查询必须用数组传参，哪怕只有一个值

Express里最常见的错误是把req.query.id直接拼进SQL字符串，比如query(`SELECT * FROM users WHERE id = ${req.query.id}`)。这种写法只要输入1 OR 1=1，就变成全表扫描。正确做法是用mysql2或pg驱动的参数化接口，且参数必须是数组。

mysql2：占位符用?，参数必须是数组，哪怕只有一个值——db.query('SELECT * FROM users WHERE id = ?', [req.query.id])
pg：占位符用$1、$2，顺序严格对应数组元素——client.query('SELECT * FROM logs WHERE level = $1', ['error'])
别信“我只传数字，不会出问题”：req.query.id永远是字符串，parseInt(req.query.id)后没校验NaN，攻击者可传1%00或1.5绕过

表名、字段名、ORDER BY不能参数化，得靠白名单硬控制

占位符只接受值，不接受结构部分。你没法写SELECT * FROM ? WHERE id = ?——mysql2和pg都会报错。这些地方必须提前定义合法范围，运行时做精确匹配。

字段名白名单示例：const validFields = ['name', 'email', 'status']; if (!validFields.includes(req.query.sort)) throw new Error('Invalid sort field');
表名同理，别试图用配置项动态拼接，直接switch (req.query.type) { case 'user': table = 'users'; break; }
ORDER BY子句尤其危险：有人用ORDER BY ${req.query.sort}，结果被注入成ORDER BY id; DROP TABLE users;——分号在MySQL里允许多语句，mysql2默认开启multipleStatements: false，但别依赖它

所有分支路径都得覆盖，包括日志和错误响应

修复一个query()调用不等于修复漏洞。真正漏掉的地方往往在if/else分支、异常处理、甚至打点日志里。

Tome

Tome是一款面向叙事型页面和演示内容创作的 AI storytelling 工具。

下载

别在catch块里原样输出error.sql或error.sqlState——这些字段可能含原始恶意SQL，直接透出到HTTP响应体或前端控制台
日志记录前过滤敏感内容：logger.info(`DB query on ${sanitizedPath}`, { params: cleanParams })，而不是logger.info('Query failed', { sql: rawSql, params: req.query })
注意框架封装层：Express中间件、ORM（如Sequelize）的raw()方法、findAndCountAll({ where: sequelize.literal(...) })，这些都绕过参数化，得单独审计

应急补救优先做入口校验，别等重写DAO层

上线前没做预编译？现在没时间重构整个数据访问层。最有效动作是在路由handler之前加一层轻量校验，把90%的恶意payload拦住。

对ID类参数：强制转整数并检查范围——const id = parseInt(req.query.id, 10); if (!Number.isInteger(id) || id 1e6) return res.status(400).end();
对搜索关键词：限制长度+禁止特殊字符——if (req.query.q.length > 50 || /['";\/-()]/.test(req.query.q)) return res.status(400).end();
别用正则模糊匹配“SQL关键字”，攻击者早有绕过方案（如uni%00on、sel/**/ect）；用硬规则卡死业务边界更可靠

真正难的不是写对一行db.query()，而是确保if分支里的SQL、错误日志里的sql字段、导出功能的raw查询、甚至监控埋点里的SQL模板，全都走同一套参数化路径。漏掉任意一处，漏洞就还在。