Безопасный способ доступа к хранимым процедурам SQL из Entity Framework Core

Question

Я нахожусь в середине «Pen Test» и пытаюсь найти «самый безопасный» способ использования Entity Framework Core для хранимых процедур.Вы могли бы подумать, что это будет очевидно, но, пожалуйста, продолжайте читать.

Фон

Использование этого документа при использовании Raw SQL и прочтении Что нового в .NET Core 2.0 мой начальныйВ коде использовалась интерполяция строк (показанная как безопасная в документе «что нового»).

Однако Pen Test успешно справился с атакой SQL-инъекций против него.

Пример кода-нарушителя:

dbResults = _datacontext.Blogs.FromSql($"myStoredProcedure @parmeter1 = {parmeter1String}");

Итак, я изменил код для использования параметров, но они также прорвались через это:

dbResults = _datacontext.Blogs.FromSql("myStoredProcedure @parmeter1 = {0}", parmeter1String);

, и они сломали это (хотя, может быть, я недостаточно чистил - по крайней мере, я остановилсяexec):

dbResults = _datacontext.Blogs.FromSql("myStoredProcedure @parmeter1 = {0}", parmeter1String.ToCleanedSqlString());

Так есть ли ответ на использование SqlParameter (не показан ни в одном из приведенных выше документов / примеров)?

dbResults = _datacontext.Blogs.FromSql("myStoredProcedure @parmeter1 = {0}", new SqlParameter("@parmeter1", parmeter1String));

или есть лучший способ?

Буду признателен за определенные указания.

РЕДАКТИРОВАТЬ Следующий комментарий:

Важное дополнение: хранимая процедура выполняет динамический sql, но эта процедуране находится в моем заявлении, и я не могу контролировать его.Я должен позвонить.

Answer 1

После комментариев я подумал, что должен добавить заключение (спасибо @AlexK через комментарий).

Если хранимая процедура написана с использованием не параметризованного динамического SQL, Entity Framework не сможет защитить ее.Это не является ошибкой Entity Framework (который, как правило, очень хорош в защите SQL).

Если вы окажетесь в подобной ситуации, хранимая процедура должна быть переписана с использованием параметризованного динамического SQL.Очень хорошее объяснение можно найти здесь .

Для разработки.

У Entity Framework нет способа защитить sql следующим образом:

CREATE PROCEDURE search_orders @custid   nchar(5)     = NULL,
                               @shipname nvarchar(40) = NULL AS
DECLARE @sql nvarchar(4000)
SELECT @sql = ' SELECT OrderID, OrderDate, CustomerID, ShipName ' +
              ' FROM dbo.Orders WHERE 1 = 1 '
IF @custid IS NOT NULL
   SELECT @sql = @sql + ' AND CustomerID LIKE ''' + @custid + ''''
IF @shipname IS NOT NULL
   SELECT @sql = @sql + ' AND ShipName LIKE ''' + @shipname + ''''
EXEC(@sql)

Но это будет безопасно:

CREATE PROCEDURE search_orders @custid   nchar(5) = NULL,
                               @shipname nvarchar(40) = NULL AS
DECLARE @sql nvarchar(4000)
SELECT @sql = ' SELECT OrderID, OrderDate, CustomerID, ShipName ' +
              ' FROM dbo.Orders WHERE 1 = 1 '
IF @custid IS NOT NULL
   SELECT @sql = @sql + ' AND CustomerID LIKE @custid '
IF @shipname IS NOT NULL
   SELECT @sql = @sql + ' AND ShipName LIKE @shipname '
EXEC sp_executesql @sql, N'@custid nchar(5), @shipname nvarchar(40)',
                   @custid, @shipname

Насколько я могу судить, любой из примеров кода из этого вопроса будет правильным "безопасным" кодом EF (хотя дополнительная работа над методом расширения будетбыли излишки требований).

Обновление

После этого я связался с Microsoft и создал PR , основа которого была принята,Предупреждающее сообщение в официальной документации теперь более подробно , возможно, уменьшит вероятность того, что у кого-то возникнут такие же проблемы.