对象关系映射框架为何仍会允许SQL注入攻击的发生（以及如何弥补这些安全漏洞）

问题就出在开发人员将这种“逃生通道”视为普通的ORM工具，并直接将用户输入插入到他们生成的SQL字符串中。

如何在代码中识别这一漏洞

以下是一个典型的过滤报告接口示例：

// Express.js - 存在漏洞
app.get('/reports', async (req, res) => {
  const { region } = req.query;
  const results = await sequelize.query(
    `SELECT * FROM sales WHERE region = '${region}'`,
    { type: QueryTypes.SELECT }
  );
  res.json(results);
});

查询构建器根本看不到这条字符串；它只是原封不动地将其传递给了数据库驱动程序。

为什么这很重要

像?region=' OR '1'='1'这样的请求会将SQL语句变成SELECT * FROM sales WHERE region = '' OR '1'='1'，而这种条件永远都是成立的。因此，无论区域字段的值是什么，数据库都会返回表中的所有记录。

更糟糕的是，由于这段代码存在于基于ORM的项目中，它往往不会像在非ORM代码环境中那样受到严格的审查。审阅人员会认为ORM已经处理好了这些问题。

如何修复这一漏洞

应该使用原始查询API所提供的替换/绑定机制来传递参数值，而不是自己手动构建SQL字符串：

// Express.js - 安全版本
app.get('/reports', async (req, res) => {
  const { region } = req.query;
  const results = await sequelize.query(
    'SELECT * FROM sales WHERE region = :region',
    {
      replacements: { region },
      type: QueryTypes.SELECT
    }
  );
  res.json(results);
});

这种修复方法并不是完全避免使用原始查询语句，因为有时确实需要这样做。但当有现成的绑定机制可用时，就绝对不应该再手动构建SQL字符串。

切勿将用户输入直接拼接到原始查询字符串中。请使用原始查询方法所提供的替换/绑定接口。

2. 无法参数化的标识符

参数化查询能够保护数值，但无法保护标识符，比如表名、列名或ORDER BY方向等。这些内容必须直接包含在SQL字符串中。

正因如此，在那些编写得相当规范的ORM代码中，动态排序功能往往会成为注入攻击最容易趁虚而入的地方之一。

如何在代码中识别这一漏洞

以下是一个典型的可排序列表接口示例：

// Express.js - 存在漏洞
app.get('/users', async (req, res) => {
  const { sortBy = 'created_at' } = req.query;
  const users = await sequelize.query(
    `SELECT * FROM users ORDER BY ${sortBy}`,
    { type: QueryTypes.SELECT }
  );
  res.json(users);
});

为什么这很重要

在有人没有恶意的情况下，sortBy 看起来只是一种方便的 UI 功能而已。然而，当有人发送类似 created_at; DROP TABLE users; -- 这样的代码时，情况就会发生变化。这种代码是否真的会被执行，取决于你使用的数据库驱动程序：Postgres 的 pg 驱动程序会默认执行这类复合查询语句，而 MySQL 的 mysql2 驱动程序则会在没有明确设置 multipleStatements: true 选项的情况下阻止这种行为的发生。

无论哪种情况，根本问题都是一样的：有人将任意的 SQL 代码放在了本应仅用于存放列名的位置上。

如何修复这一漏洞

由于标识符不能被作为参数传递，因此唯一的安全做法就是使用允许列表：

// Express.js - 安全版本
const ALLOWEDSORT_COLUMNS = ['created_at', 'name', 'email'];

app.get('/users', async (req, res) => {
  const { sortBy = 'created_at' } = req.query;
  const column = ALLOWED_sort_columns.includes(sortBy) ?sortBy : 'created_at';

  const users = await sequelize.query(
    `SELECT * FROM users ORDER BY ${column}`,
    { type: QueryTypes.SELECT }
  );
  res.json(users);
});

千万不要将用户输入直接传递给那些本应用于存放标识符的位置，即使事先对输入进行了“清洗”处理。对于标识符来说，进行正确的清洗操作其实非常困难，很容易出错。

标识符不能被参数化。如果用户输入决定了列名或表名，那么应该使用允许列表来控制哪些输入是合法的，而不要对其进行清洗处理。

3. 通过存储的数据进行二次注入攻击

这种漏洞往往会让开发团队措手不及，因为最初将数据写入数据库时，这些输入确实是被参数化处理的……

然而，真正的注入攻击发生在之后，当那些已经被存储在数据库中的值被重新用于另一个没有使用参数化的查询语句中时。

如何在代码中识别这一漏洞

以下是一个注册流程的示例，以及代码库中另一个管理员搜索功能的示例：

// Express.js - 存在漏洞的版本

// 第一步：用户注册，输入数据被正确地参数化了
app.post('/register', async (req, res) => {
  await User.create({ username: req.body.username });
  res.json({ success: true });
});

// 第二步：代码库中的另一个地方，管理员搜索功能
app.get('/admin/search', async (req, res) => {
  const user = await User.findByPk(req.params.id);
  const results = await sequelize.query(
    `SELECT * FROM audit_log WHERE actor = '${user.username}'`,
    { type: QueryTypes.SELECT }
  );
  res.json(results);
});

第一步本身是完全安全的，问题出在第二步。

为什么这很重要

// Express.js - 安全编码示例

// 第1步（注册流程）没有变化，因为这些参数本来就是通过参数化方式传递的

app.get('/admin/search', async (req, res) => {
  const user = await User.findByPk(req.params.id);
  const results = await sequelize.query(
    'SELECT * FROM audit_log WHERE actor = :actor',
    {
      replacements: { actor: user.username },
      type: QueryTypes.SELECT
    }
  );
  res.json(results);
});

// Express.js - 存在漏洞的代码示例

app.get('/products', async (req, res) => {
  const { minPrice } = req.query;
  const products = await Product.findAll({
    where: sequelize.literal(`price > ${minPrice`)
  });
  res.json(products);
});

// Express.js – 安全性配置
app.get('/products', async (req, res) => {
  const minPrice = Number(req.query.minPrice);

  if (!Number.isFinite(minPrice)) {
    return res.status(400).json({ error: 'minPrice必须是一个数值' });
  }

  const products = await Product.findAll({
    where: { price: { [Op.gt]: minPrice } }
  });
  res.json(products);
});