2013-04-22 61 views
0

我有執行一個SQL查詢的問題,下面是我的存儲過程演員在SQL Server查詢

查詢

ALTER PROCEDURE ProcName 
(
    @iID VARCHAR(50), 
    @AccountID INT 
) 
AS 
SET NOCOUNT ON 

DECLARE @Sql VARCHAR(MAX) 

SET @Sql = 'DELETE FROM ReferringPhysician WHERE iID IN(' + @iID + ') AND AccountID = '+ @AccountID + '' 
EXEC (@Sql) 

我試圖執行這個查詢,但它給了我錯誤因爲我正在使用exec(),在這裏我在哪裏條件下我正在處理string,而在另一種情況下我正在處理int,所以在第二種情況下我得到了鑄造錯誤!我怎麼能通過這個?

任何幫助,非常感謝!

感謝

+1

這看起來像這將是容易受到SQL注入式攻擊。您應該使用sp_executesql – 2013-04-22 15:56:30

+0

@JoelCoehoorn yes,但不能將逗號分隔列表傳遞到sp_executesql,並根據需要正確解析它。 – 2013-04-22 16:04:49

回答

4

您的查詢是容易受到SQL注入。爲了避免您遇到的數據類型問題

一種方式是通過在那裏你可以不使用EXEC()more details here)適當的數據類型:

DECLARE @sql NVARCHAR(MAX) = N'DELETE dbo.referringPhysician 
    WHERE iID IN (' + @iID + ') AND AccountID = @AccountID;'; 

EXEC sp_executesql @sql, N'@AccountID INT', @AccountID; 

您可以通過使用表完全保護這從SQL注入評估參數並使用正確類型而不是逗號分隔字符串傳入DataTable或其他集合。例如: -

CREATE TYPE dbo.iIDs TABLE(iID INT PRIMARY KEY); 

現在你的存儲過程可以完全避免動態SQL:

ALTER PROCEDURE dbo.ProcName -- always use schema prefix! 
    @iIDs dbo.iIDs READONLY, 
    @AccountID INT 
AS 
BEGIN 
    SET NOCOUNT ON; 

    DELETE r 
    FROM dbo.ReferringPhysician AS r 
    INNER JOIN @iIDs AS i 
    ON r.iID = i.iID 
    WHERE r.AccountID = @AccountID; 
END 
GO 
+0

AccountID是一個INT類型。它實際上是最容易受到攻擊的@iID參數(varchar(50)) – 2013-04-22 15:57:45

+0

@JoelCoehoorn yes true但是你不能用sp_executesql修復:-) – 2013-04-22 15:59:58

+0

@AaronBertrand所以,你想說我不必須將逗號分隔的字符串傳遞給我的存儲過程。對? – 2013-04-22 16:05:49

0

試試這個:

ALTER PROCEDURE ProcName 
(
    @iID VARCHAR(50), 
    @AccountID INT 
) 
AS 
SET NOCOUNT ON 

DECLARE @Sql VARCHAR(MAX) 

SET @Sql = 'DELETE FROM ReferringPhysician WHERE iID IN(' + CAST(@iID AS VARCHAR) + ') AND AccountID = '+ CAST(@AccountID AS VARCHAR) + '' 
EXEC (@Sql) 
+1

請[不要使用無長度的varchar](http://sqlblog.com/blogs/aaron_bertrand/archive/2009/10/09/bad-habits-to-kick-declaring-varchar-without-length.aspx) 。 – 2013-04-22 15:54:55

+0

由於它已被定義爲「VARCHAR」,因此無需將'@ iID'強制轉換爲'VARCHAR'。並且請使用'VARCHAR'長度(如'VARCHAR(50)' – Lamak 2013-04-22 15:55:15

+0

不知道爲什麼這是低調投票。它解決了問題,即使它不是最優解。 – 2013-04-22 16:04:11