VeraCode 报告 ServiceStack OrmLite 对 SQL 命令中使用的特殊元素进行了不当中和（“SQL 注入”）（CWE ID 89）

Posted 2023-02-19

【中文标题】VeraCode 报告 ServiceStack OrmLite 对 SQL 命令中使用的特殊元素进行了不当中和（“SQL 注入”）（CWE ID 89）

【英文标题】：VeraCode Reports ServiceStack OrmLite with Improper Neutralization of Special Elements used in an SQL Command ('SQL Injection') (CWE ID 89)

【发布时间】：2014-12-25 11:58:16

【问题描述】：

好的，所以我在我的 Web API 中使用 ServiceStack OrmLite 来满足我的数据需求。当我将代码提交给 VeraCode 进行代码安全扫描和验证时，结果报告显示 OrmLite 显示了潜在的 SQL 注入攻击向量。

ServiceStack.OrmLite.dll       GridReader DapperMultiple(System.Data.IDbConnection, string, object, System.Data.IDbTransaction,System.Nullable<int>, System.Nullable<System.Data.CommandType>)

ServiceStack.OrmLite.dll       int ExecuteCommand(System.Data.IDbConnection, System.Data.IDbTransaction, string, System.Action<System.Data.IDbCommand,object>, object, System.Nullable<int>, System.Nullable<System.Data.CommandType>)

ServiceStack.OrmLite.dll       int ExecuteDapper(System.Data.IDbConnection, string, object, System.Data.IDbTransaction, System.Nullable<int>, System.Nullable<System.Data.CommandType>)

ServiceStack.OrmLite.dll       object Scalar(System.Data.IDbCommand, string)

ServiceStack.OrmLite.dll       System.Data.IDataReader ExecReader(System.Data.IDbCommand, string)

ServiceStack.OrmLite.dll       System.Data.IDataReader ExecReader(System.Data.IDbCommand, string, System.Collections.Generic.IEnumerable<System.Data.IDataParameter>)

我不确定如何分类。我应该用 EntityFramework 替换 OrmLite 吗？

【参考方案1】：

诶？所有这些节目都是 OrmLite API，让您执行原始 SQL 字符串？最后，每个 ORM 都会使用ADO.NET's underlying API's 来执行原始 SQL。

OrmLite API's are typed 的大部分值都被转义并受到 SQL 注入攻击的保护。但由于 OrmLite 是一个多功能的 ORM，它还提供了 let you execute Raw SQL 的自定义 API，但即使在这种情况下，您也可以通过使用参数化查询来保护自己免受 SQL 注入：

自定义 SQL API

List<Person> results = db.SqlList<Person>(
    "SELECT * FROM Person WHERE Age < @age", new  age=50);

List<Poco> results = db.SqlList<Poco>(
    "EXEC GetAnalyticsForWeek @weekNo", new  weekNo = 1 );

前几行看起来像是来自interned version of Dapper，这是另一个为了方便而嵌入在 OrmLite 中的 Micro ORM，但 OrmLite 本身并未使用。与 OrmLite 一样，它提供了自定义 SQL API，它还允许您使用参数化参数并且不受 SQL 注入攻击。

【讨论】：

所以基本上我需要删除 OrmLite 才能获得及格分数。生产环境中运行的代码不能包含允许执行 RAW SQL 的 API。

@Mr.Young ??所有 ORM 都编译为原始 SQL，即它们生成最终由具体 DB 提供程序执行的 SQL。在 Micro ORM 的情况下，大多数只是 ADO.NET 底层 IDb* 接口上的扩展方法。当然，他们可以执行原始 sql，这是 ADO.NET 提供的 API，也是每个 ORM 用来执行 SQL 的 API。这个想法是使用由 ORM 提供的类型化或参数化 API 来防止 SQL 注入。

这并不完全正确。 EntityFramework 解析为System.Data.Common.DbProviderFactory，它将提供（除其他外）IDbDataAdapter 和IDbCommand。这些代码路径使用SqlDataAdapter（不是DbDataAdapter）。在 EntityFramework 内部，EntityProviderFactory : DbProviderFactory 不使用 DbDataAdapter。 SqlDataAdapter 验证用户提供的输入以确保其符合预期的格式，并尽可能使用集中的数据验证例程。 public override DbDataAdapter CreateDataAdapter() throw new NotSupportedException();

出于多种原因，我删除了 OrmLite。 OP 在 VeraCode 中被评为高。此外，OrmLite 还存在熵不足 (CWE ID 331) 和使用损坏或有风险的密码算法 (CWE ID 327)。我要求 OrmLite 的作者将他们的框架提交给 VeraCode 进行测试，以帮助使用他们框架的其他人防止可能的攻击媒介。

@Mr.Young IDbCommand 是我指的执行 SQL 的 ADO.NET 命令。根据您的结论，您根本不应该使用 ADO.NET 或任何使用它的 ORM。其中 OrmLite 只是一个类型化的 API 包装器。也不确定您指的是 CWE - OrmLite 不使用任何加密库，为什么 ORM 需要？

【参考方案2】：

在使用 VeraCode 读取代码期间，建议的适当补救措施是将 ServiceStack ORM 替换为 EntityFramework 6.1。

这只是对当前存储库模式的一个小更新。