为啥我的函数参数化后 Veracode 仍然报告 CWE-89?
Posted
技术标签:
【中文标题】为啥我的函数参数化后 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 注入。 【参考方案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 参数之外,它们已经是保护了。 在管理员保存到数据库之前验证这些参数是个好主意,但我更喜欢在此方法中验证参数,因为可能这些参数在数据库中被某些代码或某些人更改,并且它您的设计存在风险,但如果您验证此方法中的参数,您可以处理风险以上是关于为啥我的函数参数化后 Veracode 仍然报告 CWE-89?的主要内容,如果未能解决你的问题,请参考以下文章
VeraCode 报告 ServiceStack OrmLite 对 SQL 命令中使用的特殊元素进行了不当中和(“SQL 注入”)(CWE ID 89)
如何修复 Veracode - 跨站点脚本 - CWE ID 80 - 基本 XSS - 在 .each 函数中使用 $(item)