2010-08-17 68 views
4

是否将SQL参数传递给存储过程本身确保SQL注入不会发生或类型检查也需要执行?参数类型未设置时SQL注入是否可能?

作为一个例子 -
ADO.NET代码:

Database DBObject = DataAccess.DAL.GetDataBase(); 
    DbCommand command = DBObject.GetStoredProcCommand("usp_UpdateDatabase"); 
    List<DbParameter> parameters = new List<DbParameter>(); 
    parameters.Add(new SqlParameter("@DbName", txtName.Text)); 
    parameters.Add(new SqlParameter("@DbDesc", txtDesc.Text)); 
    command.Parameters.AddRange(parameters.ToArray()); 
    rowsAffected = DBObject.ExecuteNonQuery(command); 

SP:

ALTER PROCEDURE [dbo].[usp_GetSearchResults] 
-- Add the parameters for the stored procedure here 
    @DbName NVARCHAR(50) = '' 
,@DbDesc NVARCHAR(50) = '' 

AS 
BEGIN 
    SET NOCOUNT ON; 
    SELECT  [RegionName] 
      ,[AppName] 
    FROM [ApplicationComponent] 
    WHERE [DBName] LIKE ('%' + @DbName+ '%') 
    OR [DBDesc] LIKE ('%' + @DbDesc+ '%') 
END 

在上面的代码中,我还没有提到的任何参数类型或验证逻辑。它仍然会抢占SQL注入?

感谢您的指导!

+0

+1对于一个重要的问题。 – Teekin 2010-08-17 13:48:06

+0

^^非常感谢..相信我,我很犹豫发表这个问题,觉得它太愚蠢了基本上要问这个问题.. :) – Dienekes 2010-08-17 13:50:07

回答

8

不,应该没问题。 LIKE子句中的值仍然作为字符串值构建,而不是被解释为SQL语句的一部分。它仍被视为数据而不是代码,这是避免SQL注入攻击的关键部分。

+0

=>我知道我不能问你,但不是像下面这样(在http://http.msdn.microsoft.com/en-us/library/ff648339.aspx提到)容易受到攻击 - 考虑当用户在SSN文本框中键入以下字符串时会发生什么情况,该文本框预计为nnn-nn-nnnn形式的社会安全号码。 '; DROP DATABASE pubs - 那么在like子句中给出'Drop Datatabase'? – Prashant 2010-08-17 14:15:43

+0

。所以这意味着,在使用SQL参数时,双引号会绕过输入的值,从而使其成为字符串文字,否则在动态SQL中,它将被用引号和SQL语句的一部分处理? – Dienekes 2010-08-17 14:15:44

+1

@Dienekes:不,这意味着SQL引擎完全独立于SQL接收数据,*保持独立。 – 2010-08-17 14:19:29

2

是的,这应该仍然可以保护您免受SQL注入。

您不是在.NET代码中动态构建SQL字符串,而是不使用sp_execute在存储过程中动态构建和执行SQL语句。

+0

+1为了区别你仍然可以做动态SQL SPs,因此它们不会从SQL注入中隐式安全。 – RedFilter 2010-08-17 14:32:49

0

默认DbTypeSQLParameterNVarChar(按照docs),所以这是你的参数将有类型。

无论如何,即使参数属于错误类型,最糟糕的情况是您需要的类型转换异常,而不是SQL注入。

0

我仍然建议使用键入的参数。 虽然实施方法能够立即捕获任何注入尝试,但并没有真正保证这种情况会出现这种情况 - 希望您的应用程序能够过上漫长而繁荣的一生...... =)

关于SQL Server,关于这个主题的MSDN文章可以在这里找到: http://msdn.microsoft.com/en-us/library/ff648339.aspx

相关问题