CVE-2023-25813 漏洞

自己使用Nestjs 搭配 Sequelize ，在安装新包的时候提示有Critical 风险。有漏洞嘛，要第一时间处理，要处理，除了升级，还要看一下这个漏洞如何复现。

粗略得到结果如下：

CVE-2023-25813

I、漏洞复现：

https://github.com/advisories/GHSA-wrh9-cjv3-2hpw

开发代码：

User.findAll({
  where: or(
    literal('soundex("firstName") = soundex(:firstName)'),
    { lastName: lastName },
  ),
  replacements: { firstName },
})

用户输入：

{
  "firstName": "OR true; DROP TABLE users;",
  "lastName": ":firstName"
}

Sequelize预编译出SQL：

SELECT * FROM users WHERE soundex("firstName") = (:firstName) OR "lastName" = ':firstName'

占位符替换，最终会得到如下SQL：

SELECT * FROM users WHERE soundex("firstName") = soundex('OR true; DROP TABLE users;') OR "lastName" = ''OR true; DROP TABLE users;''

妥妥的SQL注入，高危风险。

II、漏洞预防

Do not use the replacements and the where option in the same query if you are not using Sequelize >= 6.19.1

• 升级sequelize版本。
• where 与replacements 不要同时出现。

CVE-2023-22578

不算漏洞的漏洞，不要将用户输入作为列名。

https://github.com/advisories/GHSA-8mwq-mj73-qv68

https://github.com/sequelize/sequelize/discussions/15694

ephys解释如下：

Hi!

At the present time I do not know.

The problem is that, while I did make the changes to remove a footgun in v7, that behavior was not a bug but a deliberate feature implemented by one of the previous teams that worked on Sequelize, and there are codebases relying on it.

Backporting #15374 would introduce a breaking change in a minor release. We've exceptionally done that in the past when we fixed a major issue (#14519), but I am not convinced that it's warranted for this one.

The reason I think releasing this breaking change in a minor release is unwarranted is that it can only be a problem if you use user-provided values as the name of a column to select. Even without the fix, you should make sure that input is safe as the query will crash if the input is not a valid attribute name.

We're stuck between a rock and a hard place. We can either introduce a breaking change in a minor release, or have a critically vulnerability warning.

We need to check with the people that published that vulnerability if they would consider a big bold warning that that property accepts arbitrary SQL (and therefore that user data should not be used in it) to be sufficient to dismiss the audit warning