2010-03-30 50 views
1

當使用SqlCommand通過RPC調用存儲過程時,看起來可以調用除當前數據庫之外的數據庫中的存儲過程。SqlCommand - 防止其他數據庫中的存儲過程調用

例如:

string storedProcName = "SomeOtherDatabase.dbo.SomeStoredProc";  
SqlCommand cmd = new SqlCommand(storedProcName); 
cmd.CommandType = CommandType.StoredProcedure; 

我想通過禁止對另一個數據庫的潛在調用來限制我的DAL代碼。一種方法可能是檢查上面storedProcName中是否有兩個句點(點),如果是,則拋出異常。任何其他想法/方法?

謝謝。

+2

爲什麼不限制它數據庫服務器端? – hallie 2010-03-30 06:21:41

+0

是一個好主意,我們可能會做到這一點(由於存在許多數據庫,在我們的案例中設置這項工作會有點麻煩)。但我也喜歡將支票放入DAL的想法,因爲我認爲它應該相對容易檢查。 – 2010-03-30 06:30:27

回答

3

通常這樣的限制是在服務器端配置的。
SQL Server有一個非常廣泛的安全模型,通過爲特定的數據庫對象(表,數據庫,數據庫)授予特定的「Principals」(用戶或組)特定權限(「讀取」,「寫入」等)視圖,存儲過程,模式...)

您建議讓DAL層應用一些限制來防止在與ADO連接關聯的默認數據庫之外使用存儲過程,這表明了積極態度什麼是「發送到SQL」。一般來說,這是一種有價值的態度(例如防止SQL注入),但在這種情況下,我建議不要這樣做:
如果在將來的某個時間需要特定的「外部」存儲過程,該怎麼辦?另外,如果當前數據庫中有多個存儲過程應該對應用程序取消限制(因爲它們僅用於維護/數據加載/審計/其他任何操作)呢?通過引入一些DAL級別的限制,您可能會在以後自行設置困難,並且您可能會被引導認爲訪問控制是足夠的,可能不是這種情況...

1

有可能是在你的數據庫在其名稱中帶點程序:

create procedure dbo.[Dots.In.Name] 
as 

隨着海莉說,你有充分的保護服務器安全(不授予其它數據庫中的任何帳戶任何權限更好被SqlConnection使用)。另外,如果你正在處理2005或2008數據庫,那麼當前數據庫中可能有一個實際引用另一個數據庫的同義詞,或者當然,當前數據庫中的任何存儲過程都可能會調用存儲過程另一服務器/數據庫。所以基本上,控制你的數據庫服務器(控制什麼對象被創建,以及授予了什麼權限),並且編寫更少的代碼來試圖覆蓋服務器現在可以充分響應的情況。

+0

我們可以完全控制存儲的proc名稱,因此您可以假定不會有任何存儲的proc名稱帶有點。 (如果我們發現任何問題,我們將不得不對開發者負責做一些討厭的事情)。話雖如此,看起來像確保服務器似乎是普遍的共識。 – 2010-03-30 06:40:29

+0

@Moe - 呃,你必須保證服務器的安全,這個選項對你來說意味着更少的工作:-) – 2010-03-30 06:44:00

相關問題