从Entity Framework Core访问SQL存储过程的安全方法

Question

我处于“笔测试”中，并试图找到将“ Entity Framework Core用于存储过程的“最安全”方式。 你会认为这很明显，但请继续阅读。

背景

使用本文档使用Raw SQL并阅读了.NET Core 2.0中的Whats，我的初始代码使用了字符串插值（在'what's new'文档中显示为安全）。

但是，Pen Test成功管理了针对它的SQL注入攻击。

违规代码示例：

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

所以，我改变了代码使用params，但他们也突破了这个：

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无法保护它。 这不是实体框架的错（通常，它非常擅长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 ，其基础已被接受。 官方文档上的警告消息现在更详细 ，希望减少有人遇到同样问题的机会。