編寫安全的 Transact-SQL

簡介 保護開發 SQL Server 的安全 以最低權限帳戶身份進行開發 遵照保護 T-SQL 的最佳方法 了解具有獨特安全考慮事項的 T-SQL 命令 小結 參考資料

簡介

關於如何以安全的方式部署 sql server，存在大量很好的信息源。但是，這些資源的目標用戶通常都是那些對已經開發好的應用程序執行保護任務的數據庫管理員。另外，還有很多內容討論了如何編寫安全的 .NET 和 ASP.NET 代碼，其中包括訪問 SQL Server 的 .NET 代碼。然而，很多這樣的資源關注的是在應用服務器上運行的數據訪問代碼，而不是在 SQL Server 中執行的 Transact-SQL (T-SQL) 代碼。本專欄則將注意力投射到如何開發在 SQL Server 上安全運行的 T-SQL 代碼。 www.iTbulo.comsXXIepA

返回頁首

保護開發 SQL Server 的安全

開發安全 T-SQL 的第一步是保護開發 SQL Server 的安全。為什麼要想方設法地鎖定一個不保存真實數據的 SQL Server 實例，而從不將它展示給最終用戶呢？這是因為，這樣會強制您編寫更安全的 T-SQL，並且當將您的應用程序部署到生產中時，也會更加容易地保護該應用程序。下面是幾個具體的步驟，采用這些步驟您就可以快速保護開發服務器： www.iTbulo.comsXXIepA

•

在開發或測試 SQL Server 中，至少應該有一個正在運行的、最新的 Service Pack 和 SQL 安全修補程序，這樣才能確保您的客戶能夠在此 SQL Server 版本上成功運行您的應用程序。 www.iTbulo.comsXXIepA

•

默認情況下，SQL Server 2000 Service Pack 3a 會禁用稱為“交叉數據庫所有權鏈接”的不安全功能。在開發服務器上安裝 SP3 時，如果讓該 Service Pack 禁用“交叉數據庫所有權鏈接”，則有助於驗證您正在基於安全的服務器配置編寫 T-SQL 代碼。 www.iTbulo.comsXXIepA

•

找出開發 SQL Server 上常見的安全配置問題的一種簡便方法是針對該服務器運行 Microsoft Baseline Security Analyzer。除了這種方法之外，還可以利用本專欄“參考資料”部分列出的資源；這些資源提供了一些附加步驟，可幫助您保護開發 SQL Server 的安全。 www.iTbulo.comsXXIepA

通常情況下，保護開發服務器安全的最佳方法，就好似它正在生產環境中運行那樣對它進行保護。您離這個目標越接近，那麼就可以越自信於您開發的代碼可以在一個安全的生產環境中正常運行。 www.iTbulo.comsXXIepA

返回頁首

以最低權限帳戶身份進行開發

在開發過程中，大家都著迷於使用具有 sysadmin 或 dbo SQL Server 權限的帳戶，直到部署之前才轉換為一個權限更低的帳戶。使用這種方法存在著一個問題：將設計人員的權限集還原為最低的所需權限集與在開發應用程序過程中編寫這些權限集相比，前者要困難得多。 www.iTbulo.comsXXIepA

鑒於部署應用程序之前您要決定可以取消哪些權限，所以請不要使用 SQL sysadmin 帳戶開發 T-SQL 代碼。如果使用 SQL sysadmin 帳戶，可能會造成這樣的結果，即應用程序會以比所需權限更多的特權帳戶運行。因此，開發時請改為使用具有最低權限的帳戶。 www.iTbulo.comsXXIepA

使用這樣的帳戶進行開發時，您會逐漸地升高授予的特定權限，以 EXEC（執行）一些必需的存儲過程、從某些表進行 SELECT（選擇）等。請編寫這些 GRANT 語句，以便可以將同樣的最低權限輕松部署到生產環境中，而不會出現任何基於猜測的操作。 www.iTbulo.comsXXIepA

這種理念同樣適用於測試。執行臨時測試以及結構更加復雜的測試時，所使用帳戶擁有的權限集和用戶權限應該與在生產環境中所使用帳戶擁有的權限集和用戶權限完全相同。 www.iTbulo.comsXXIepA

在開發過程中使用最低權限帳戶的另一個優點在於，您可以避免不小心編寫出需要危險權限或過高權限的代碼。例如，假設您需要在 T-SQL 中與第三方 COM 組件進行交互。為此，一種方法是發送一個 SQL 批處理命令，它直接調用 sp_OACreate 和 sp_OAMethod 來操縱該 COM 對象。在應用程序使用 sysadmin 帳戶連接 SQL Server 的開發環境中，上述方法效果很好。但是，當您嘗試將已經開發完成的應用程序准備用於生產部署時，您就會發現如果使用權限較低的帳戶，那麼該方法不會奏效。為了讓該應用程序能夠使用非 sysadmin 帳戶在生產環境中正常運行，您必須針對 sp_OACreate 顯式授予 EXECUTE 權限。請考慮一下，如果某個用戶最終找到了一個方法，可以使用該應用程序登錄執行任意代碼，並利用此權限針對 SQL Server 實例化一個類似 Scripting.FileSystemObject 的 COM 對象，將會產生怎樣的安全隱患？ www.iTbulo.comsXXIepA

返回頁首

遵照保護 T-SQL 的最佳方法

防御一系列稱為“SQL 注入式”的安全漏洞是至關重要的。通常情況下，您會使用多層防護來抵御 SQL 注入式攻擊： www.iTbulo.comsXXIepA

•

執行用戶提供輸入的驗證（例如，強制數據類型和最大字符串長度）。 www.iTbulo.comsXXIepA

•

轉義對數據庫引擎可能具有特殊意義的字符序列。在 T-SQL 中，注入式攻擊中最常用的兩個字符串為單引號字符 (') 和注釋字符序列 (--)。 www.iTbulo.comsXXIepA

•

在 T-SQL 語句中，請不要將用戶提供的值進行內聯。請改為使用預處理語句和參數化。 www.iTbulo.comsXXIepA

SQL 注入式攻擊在其他一些地方有詳細的說明，所以在此我就不花大量時間來討論這個問題的細節了。但是要強調一點，SQL 注入式問題並不只限於在應用層構建的 T-SQL 查詢。只要執行一個部分由用戶提供值構建的 T-SQL 查詢，就可能會發生 SQL 注入式問題。這就是說，一個在內部構建查詢字符串、並通過 EXEC() 命令或 sp_executesql 存儲過程執行該查詢的存儲過程也可能會受到攻擊。請參閱“參考資料&rdqu