为什么我的函数参数化后 Veracode 仍然报告 CWE-89？答案

【问题标题】：Why does Veracode still report CWE-89 after my function has been parameterized?为什么我的函数参数化后 Veracode 仍然报告 CWE-89？
【发布时间】：2019-02-17 17:14:27
【问题描述】：

根据 CWE-89 的推荐，我下面的函数已经被参数化了，但是 Veracode 仍然报告 CWE-89 在该函数中可用。

如您所见，该函数用于根据输入参数生成动态 SQL 查询。而且，只有@PrimaryValue参数来自用户输入，而其他动态变量在SELECT、FROM、JOIN、ON和WHERE后面从数据库中查询（不是从用户输入）。

您如何看待这个案例？我可以为此提出缓解措施还是我必须更多地修改代码来解决问题？请给我建议。

【问题讨论】：

我知道您说要连接到查询中的变量来自配置数据库，但是 Veracode 怎么知道呢？它所看到的只是将代码变量连接到 SQL 查询中。它不能假设这些值是有效的 SQL 标识符。 SQL注入不仅来自用户输入，它可以是任何内容。 SQL 注入也不总是恶意的，它可能是一个简单的错误。此类事故更有可能导致无效的 SQL 查询，而不是数据泄露，但仍算作 SQL 注入。

标签： security sql-injection veracode

【解决方案1】：

您的代码存在 SQL 注入问题。例如用户可以传递给这个方法，参数“intofile”是这样的：

* FROM Table1; DROP TABLE table2; intofile

使用此代码，用户将您的查询转换为 3 个查询，运行后 table2 被删除。

首先，您必须在只读事务中运行查询。之后，您必须对所有输入使用 SQL 转义方法以从中删除 DROP 等关键字。

【讨论】：

是的，我知道 intofile 变量有这个问题。但是，正如我所说，SELECT、FROM、JOIN、ON 和 WHERE 后面的所有变量都是从数据库中查询的，而不是从用户输入中查询的。只有@PrimaryValue 参数来自用户输入。因此，在这种情况下，您的担忧不会发生。
@RDeveloper - 当你说他们是从数据库中查询出来的，那可能是也可能不是是保护。这取决于您是说它们是通过您自己设计的 元数据 查询检索到的，还是它们来自普通表中的普通列，在这种情况下，您仍然存在注入风险，这是只是一个存储的注入风险。不过，无论哪种情况，分析工具都可能无法推理您如何获得这些值，它所知道的只是您正在混合 data 和代码以存在误解风险的方式组合成一个字符串
这取决于您的项目，此方法在某些输入中具有 sql 注入，但如果您说除 @PrimaryValue 之外的所有输入都已从此方法中检出，因此调用此方法的方法可能是安全的，看来为了安全
@Damien_The_Unbeliever：我的应用程序中的 SQL 查询是根据存储在数据库中的配置动态生成的。而且，只有管理员可以添加/更新该配置。还有一件事，在管理员添加/更新该配置之前，它已经过验证以防止 SQL 注入。所以，是的，除了上面函数中的 PrimaryValue 参数之外，它们已经是保护了。
在管理员保存到数据库之前验证这些参数是个好主意，但我更喜欢在此方法中验证参数，因为可能这些参数在数据库中被某些代码或某些人更改，并且它您的设计存在风险，但如果您验证此方法中的参数，您可以处理风险