程序師世界是廣大編程愛好者互助、分享、學習的平台,程序師世界有你更精彩!
首頁
編程語言
C語言|JAVA編程
Python編程
網頁編程
ASP編程|PHP編程
JSP編程
數據庫知識
MYSQL數據庫|SqlServer數據庫
Oracle數據庫|DB2數據庫
 程式師世界 >> 數據庫知識 >> SqlServer數據庫 >> 關於SqlServer >> SQL Server 2008代碼安全(1):存儲過程加密與安全上下文(1)

SQL Server 2008代碼安全(1):存儲過程加密與安全上下文(1)

編輯:關於SqlServer

最近對SQL Server 2008的安全入門略作小結,以作備忘。本文涉及兩個應用:存儲過程加密和安全上下文。

<一>存儲過程加密

其實,用了這十多年的SQL Server,我已經成了存儲過程的忠實擁趸。在直接使用SQL語句還是存儲過程來處理業務邏輯時,我基本會毫不猶豫地選擇後者。

理由如下:

1、使用存儲過程,至少在防非法注入(inject)方面提供更好的保護。至少,存儲過程在執行前,首先會執行預編譯,(如果由於非法參數的原因)編譯出錯則不會執行,這在某種程度上提供一層天然的屏障。

我至今還記得大約八、九年前采用的一個權限控制系統就是通過拼湊一個SQL語句,最終得到了一個形如“ where 1=1 and dataID in (1,2) and ModelID in (2,455) And ShopID in (111) and departID in ( 1,3) and ([Name] like %myWord%) ”的where條件子句來獲取符合條件的結果集。

注意:這個參數是通過地址欄web應用的地址欄或Winform的UI界面來輸入的,所以對惡意注入需要花費一定的成本來維護。因為一些常用的關鍵字(或敏感詞)很難區分是惡意或非惡意。

2、使用存儲過程而不是直接訪問基表,可以提供更好的安全性。你可以在行級或列級控制數據如何被修改。相對於表 的訪問,你可以確認有執行權限許可的用戶執行相應的存儲過程。這也是訪問數據服務器的惟一調用途徑。因此,任何偷窺者將無法看到你的SELECT語句。換 句話說,每個應用只能擁有相應的存儲過程來訪問基表,而不是“SLEECT *”。

3、存儲過程可以加密。(這點非常實用,設想一下,您的數據庫服務器是托管的或租用的,你是否能心安理得的每天 睡個安穩覺。如果競爭對手“一不小心”登上你的SQL Server,或通過注入得到了你的存儲過程,然後相應的注入惡意的SQL,將您的業務邏輯亂改一通,而恰巧您五分鐘前又沒做備份,那會怎麼樣?)

(注意:加密存儲過程前應該備份原始存儲過程,且加密應該在部署到生產環境前完成。)

存儲過程的加密非常簡單,我們看一個例子:

插入測試表

use testDb2
go

/**********測試表*****************/
SET ANSI_PADDING ON
GO
CREATE TABLE [dbo].[tb_demo](
[id] [int] NOT NULL,
[submitdate] [datetime] NULL,
[commment] [nvarchar](200) NULL,
)
GO
SET ANSI_PADDING OFF
GO
Insert into [tb_demo]
select 1024, getdate(),REPLICATE('A',100);
WAITFOR DELAY '00:00:04';
Insert into [tb_demo]
select 1024, getdate(),REPLICATE('B',50);
go

插入存儲過程:

/***************創建未加密的存儲過程*******************/
Create Procedure CPP_test_Original
AS
select * from [tb_demo]
go
/***************創建加密的存儲過程*******************/
Create Procedure CPP_test_Encryption
with encryption
AS
----可以換成任意的邏輯
execute CPP_test_Original
go

未加密的存儲過程:

邀月工作室

加密的存儲過程:

邀月工作室

此時,至少,存儲過程的內容不會被輕易看到(雖然解密也是有可能的)。應用這個,我們可以對某些關鍵的存儲過程進行加密。但此時,存儲過程仍然能被execute、alter和drop。

<二>安全上下文


除了加密sql文本的內容,我們還可以使用EXECUTE AS 子句設定存儲過程的安全上下文,以滿足不同的安全級別需求。

如果你對這些不感興趣,請直接路過帶下劃線的段落。

(關於EXECUTE AS 子句的詳細用法,請參看MSDN:http://msdn.microsoft.com/zh-cn/library/ms188354.ASPx)

此處,我們需要了解的是:

1、在 SQL Server 中,可以定義以下用戶定義模塊的執行上下文:函數(內聯表值函數除外)、過程、隊列和觸發器。

通過指定執行模塊的上下文,可以控制數據庫引擎使用哪一個 用戶帳戶來驗證對模塊引用的對象的權限。這有助於人們更靈活、有力地管理用戶定義的模塊及其所引用對象所形成的對象鏈中的權限。必須而且只需授予用戶對模 塊自身的權限,而無需授予用戶對被引用對象的顯式權限。只有運行模塊的用戶必須對模塊訪問的對象擁有權限。

針對函數、過程、隊列和觸發器,對應的參數也不同。存儲過程對應的參數包括(CALLER | SELF | OWNER | 'user_name')。

CALLER 指定模塊內的語句在模塊調用方的上下文中執行。執行模塊的用戶不僅必須對模塊本身擁有適當的權限,還要對模塊引用的任何數據庫對象擁有適當權限。 CALLER 是除隊列外的所有模塊的默認值,與 SQL Server 2005 行為相同。 CALLER 不能在 CREATE QUEUE 或 ALTER QUEUE 語句中指定。
SELF EXECUTE AS SELF 與 EXECUTE AS user_name 等價,其中指定用戶是創建或更改模塊的用戶。創建或更改模塊的用戶的實際用戶 ID 存儲在 sys.sql_modulessys.service_queues 目錄視圖的 execute_as_principal_id 列中。SELF 是隊列的默認值。
OWNER 指定模塊內的語句在模塊的當前所有者上下文中執行。如果模塊沒有指定的所有者,則使用模塊架構的所有者。不能為 DDL 或登錄觸發器指定 OWNER。注意:OWNER 必須映射到單獨帳戶,不能是角色或組。
'user_name' 指定模塊內的語句在 user_name 指定的用戶的上下文中執行。將根據 user_name 來驗證對模塊內任意對象的權限。不能為具有服務器作用域的 DDL 觸發器或登錄觸發器指定 user_name。請改用 login_name。user_name 必須存在於當前數據庫中,並且必須是單獨帳戶。user_name 不能是組、角色、證書、密鑰或內置帳戶,如 NT AUTHORITY\LocalService、NT AUTHORITY\NetworkService 或 NT AUTHORITY\LocalSystem。執行上下文的用戶 ID 存儲在元數據中,可以在 sys.sql_modules 或 sys.assembly_modules 目錄視圖的 execute_as_principal_id 列查看。

2、所有權鏈具有以下限制:
僅適用於 DML 語句:SELECT、INSERT、UPDATE 和 DELETE。
調用和被調用對象的所有者必須相同。
不適用於模塊內的動態查詢。
  1. 上一頁:
  2. 下一頁:
Copyright © 程式師世界 All Rights Reserved