VeraCode сообщает о ServiceStack OrmLite с неправильной нейтрализацией специальных элементов, используемых в команде SQL («SQL-инъекция») (CWE ID 89)

Итак, я использую ServiceStack OrmLite для своих потребностей в данных в своем веб-API. Когда я отправил свой код в VeraCode для сканирования и проверки безопасности кода, отчет о результатах показал, что OrmLite показывает потенциальные векторы атаки SQL Injection.

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

Я не уверен, как это сортировать. Должен ли я заменить OrmLite на EntityFramework?


c# sql-server veracode sql-injection
person Mr. Young    schedule 29.10.2014    source источник

Ответы (2)


arrow_upward
1
arrow_downward

А? Все это показывает, что OrmLite API позволяет вам выполнять необработанную строку SQL? В конце концов, каждый ORM будет использовать базовый API ADO.NET для выполнения необработанного SQL.

Большинство OrmLite API типизированы, где его значения экранированы и защищены от атак SQL Injection. Но поскольку OrmLite — это универсальный ORM, он также предлагает пользовательские API, которые позволяет выполнять Raw SQL, но даже в этом случае вы можете защитить себя от SQL Injection с помощью параметризованных запросов:

Пользовательские API-интерфейсы SQL

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

Также первые несколько строк выглядят так, как будто они из интернированных версия Dapper, еще одного Micro ORM, встроенного в OrmLite для удобства, но не используемого самим OrmLite. Как и OrmLite, он предлагает пользовательский API SQL, который также позволяет вам использовать параметризованные аргументы и неуязвим для атак SQL Injection.

person mythz    schedule 29.10.2014
comment
Так что в основном мне нужно удалить OrmLite, чтобы получить проходной балл. Код, работающий в производственной среде, не может содержать API-интерфейсы, позволяющие выполнять RAW SQL. - person Mr. Young; 29.10.2014
comment
@ Мистер Янг ?? Все ORM компилируются в необработанный SQL, т. е. они генерируют SQL, который в конечном итоге выполняется конкретными поставщиками БД. В случае Micro ORM большинство из них являются просто методами расширения базовых интерфейсов IDb* ADO.NET. Конечно, они могут выполнять необработанный sql, это API, предоставляемый ADO.NET, и то, что каждый ORM использует для выполнения SQL. Идея состоит в том, чтобы использовать типизированные или параметризованные API, предоставляемые ORM, которые защищают от SQL-инъекций. - person mythz; 29.10.2014
comment
Это не совсем так. EntityFramework разрешается до System.Data.Common.DbProviderFactory, который предоставит (среди прочего) IDbDataAdapter и IDbCommand. Эти пути кода используют SqlDataAdapter (не DbDataAdapter). Внутри EntityFramework EntityProviderFactory : DbProviderFactory не использует DbDataAdapter. SqlDataAdapter проверяет введенные пользователем данные, чтобы убедиться, что они соответствуют ожидаемому формату, используя централизованные процедуры проверки данных, когда это возможно. public override DbDataAdapter CreateDataAdapter() { throw new NotSupportedException(); } - person Mr. Young; 29.10.2014
comment
Я удалил OrmLite по нескольким причинам. OP получил высокую оценку в VeraCode. Кроме того, у OrmLite также были ошибки «Недостаточная энтропия» (CWE ID 331) и «Использование сломанного или рискованного криптографического алгоритма» (CWE ID 327). Я прошу авторов OrmLite представить свой фреймворк VeraCode для тестирования, чтобы помочь другим, использующим их фреймворк, предотвратить возможные направления атак. - person Mr. Young; 29.10.2014
comment
@Mr.Young IDbCommand — это команда ADO.NET, о которой я говорю, которая выполняет SQL. Основываясь на ваших выводах, вы вообще не должны использовать ADO.NET или любую ORM, которая его использует. Из которых OrmLite — это просто типизированная оболочка API. Также не уверен, что вы имеете в виду с CWE - OrmLite не использует никаких библиотек шифрования, зачем это нужно ORM? - person mythz; 29.10.2014
comment
@Mr.Young И, чтобы повторить, пользовательский API SQL, показанный в ответе, использует параметризованные запросы, это рекомендуемая практика для выполнения SQL и проверки ввода. - person mythz; 30.10.2014
comment
Разница заключается в EF, контекст выполнения реализует IDbCommand, но CreateDataAdapter и другие API, которые могут позволить динамическому sql, были реализованы для создания исключений. В EF нет путей кода, которые разрешают динамический SQL без предварительного прохождения механизма фильтрации, подобного OWASP. Запустите сканирование VeraCode для большинства ORM, а затем запустите сканирование для EF, прежде чем отвечать снова. Также я призываю вас пройти пути кода EF в JustDecompile. - person Mr. Young; 19.02.2015

arrow_upward
0
arrow_downward

Во время считывания кода с помощью VeraCode было предложено правильное исправление: заменить ServiceStack ORM на EntityFramework 6.1.

Это было лишь незначительное обновление существующего в настоящее время шаблона репозиториев.

person Mr. Young    schedule 19.02.2015