【问题标题】:VeraCode Reports ServiceStack OrmLite with Improper Neutralization of Special Elements used in an SQL Command ('SQL Injection') (CWE ID 89)VeraCode 报告 ServiceStack OrmLite 对 SQL 命令中使用的特殊元素进行了不当中和(“SQL 注入”)(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 吗?

【问题讨论】:

    标签: c# sql-server sql-injection ormlite-servicestack veracode


    【解决方案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,它将提供(除其他外)IDbDataAdapterIDbCommand。这些代码路径使用SqlDataAdapter(不是DbDataAdapter)。在 EntityFramework 内部,EntityProviderFactory : DbProviderFactory 不使用 DbDataAdapterSqlDataAdapter 验证用户提供的输入以确保其符合预期的格式,并尽可能使用集中的数据验证例程。 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。

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

    【讨论】:

      猜你喜欢
      • 1970-01-01
      • 2017-05-14
      • 2019-02-17
      • 1970-01-01
      • 2019-05-01
      • 1970-01-01
      • 2021-11-04
      • 1970-01-01
      • 1970-01-01
      相关资源
      最近更新 更多