0

Ok, so I am using ServiceStack OrmLite for my data needs in my Web API. When I submitted my code to VeraCode for code security scanning and verification the result report showed that OrmLite shows potential SQL Injection attack vectors.

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>)

I'm not sure how to triage this. Should I replace OrmLite with EntityFramework?

Mr. Young
  • 2,364
  • 3
  • 25
  • 41

2 Answers2

1

Eh? All this shows are OrmLite API's that let you execute a raw SQL String? In the end every ORM is going to use ADO.NET's underlying API's in order to execute Raw SQL.

Most of OrmLite API's are typed where its values are escaped and protected from SQL Injection attacks. But as OrmLite is a versatile ORM it also offers custom API's that let you execute Raw SQL, but even in this case you can protect yourself from SQL Injection by using parameterized queries:

Custom SQL APIs

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 });

Also the first few lines looks like they're from the interned version of Dapper, which is another Micro ORM that's embedded in OrmLite for convenience, but not used by OrmLite itself. Like OrmLite it offers Custom SQL API's, that also lets you use parameterized arguments and invulnerable from SQL Injection attacks.

mythz
  • 141,670
  • 29
  • 246
  • 390
  • So basically I need to remove OrmLite in order to get a passing score. The code running in the production environment cannot contain APIs that allow execution of RAW SQL. – Mr. Young Oct 29 '14 at 17:56
  • @Mr.Young ?? All ORM's compiles down to Raw SQL, i.e. they generate SQL that eventually gets executed by concrete DB Providers. In the case of Micro ORM's most are just extension methods over ADO.NET's underlying `IDb*` interfaces. Of course they can execute raw sql, that's the API provided by ADO.NET and what every ORM uses to execute SQL. The idea is to use the Typed or parameterized API's provided by ORM's which protect against SQL Injections. – mythz Oct 29 '14 at 18:36
  • That isn't entirely true. EntityFramework resolves down to `System.Data.Common.DbProviderFactory` that will provide (amongst other things) `IDbDataAdapter` and `IDbCommand`. These code path's use `SqlDataAdapter` (not `DbDataAdapter`). Internal to EntityFramework the `EntityProviderFactory : DbProviderFactory` does not use `DbDataAdapter`. `SqlDataAdapter` validates user-supplied input to ensure that it conforms to the expected format, using centralized data validation routines when possible. `public override DbDataAdapter CreateDataAdapter()` `{ throw new NotSupportedException(); }` – Mr. Young Oct 29 '14 at 20:22
  • I removed OrmLite for multiple reasons. The OP was rated as a High in VeraCode. Additioanlly OrmLite also had a Insufficient Entropy (CWE ID 331) and Use of a Broken or Risky Cryptographic Algorithm (CWE ID 327). I ask the authors of OrmLite to submit their framework to VeraCode for testing to help others that use their framework prevent possible attack vectors. – Mr. Young Oct 29 '14 at 20:28
  • @Mr.Young [IDbCommand](http://msdn.microsoft.com/en-us/library/system.data.idbcommand(v=vs.110).aspx) is the ADO.NET command I am referring to which executes SQL. Based on your conclusions you shouldn't be using ADO.NET or any ORM that uses it, at all. Of which OrmLite is just a typed API wrapper around. Also not sure what you're referring to with CWE - OrmLite doesn't use any encryption libraries, why would and ORM ever need to? – mythz Oct 29 '14 at 20:56
  • @Mr.Young And to reiterate the Custom SQL API shown in the answer uses **parameterized queries**, this is the recommended practice to execute SQL and validate input. – mythz Oct 29 '14 at 21:08
  • The difference is in EF, the executing context implements IDbCommand but the CreateDataAdapter and other api's that can allow dynamic sql have been implemented to throw exceptions. There are no code paths in EF that allow dynamic sql without first going through a filtering mechanism similar to OWASP. Run a VeraCode scan against most ORMs, and then run one against EF before answering again. Also I challenge you to walk the EF code paths in JustDecompile. – Mr. Young Feb 19 '15 at 20:59
0

During a code-readout with VeraCode the suggested proper remediation was to replace ServiceStack ORM with EntityFramework 6.1.

This was only a minor update to the repositories pattern currently in place.

Mr. Young
  • 2,364
  • 3
  • 25
  • 41