[轉(zhuǎn)載] 編寫安全的 Transact-SQL

2024-07-21 02:39:44

字體：大中小

來源：轉(zhuǎn)載

供稿：網(wǎng)友

編寫安全的 Transact-SQL

Bart Duncan
Microsoft Corporation本頁內(nèi)容 [轉(zhuǎn)載] 編寫安全的 Transact-SQL（圖一）

簡介

保護(hù)開發(fā) SQL Server 的安全 [轉(zhuǎn)載] 編寫安全的 Transact-SQL（圖一）

以最低權(quán)限帳戶身份進(jìn)行開發(fā) [轉(zhuǎn)載] 編寫安全的 Transact-SQL（圖一）

遵照保護(hù) T-SQL 的最佳方法 [轉(zhuǎn)載] 編寫安全的 Transact-SQL（圖一）

了解具有獨(dú)特安全考慮事項(xiàng)的 T-SQL 命令 [轉(zhuǎn)載] 編寫安全的 Transact-SQL（圖一）

小結(jié)

參考資料

簡介

關(guān)于如何以安全的方式部署 SQL Server，存在大量很好的信息源。但是，這些資源的目標(biāo)用戶通常都是那些對已經(jīng)開發(fā)好的應(yīng)用程序執(zhí)行保護(hù)任務(wù)的數(shù)據(jù)庫治理員。另外，還有很多內(nèi)容討論了如何編寫安全的 .NET 和 asp.net 代碼，其中包括訪問 SQL Server 的 .NET 代碼。然而，很多這樣的資源關(guān)注的是在應(yīng)用服務(wù)器上運(yùn)行的數(shù)據(jù)訪問代碼，而不是在 SQL Server 中執(zhí)行的 Transact-SQL (T-SQL) 代碼。本專欄則將注重力投射到如何開發(fā)在 SQL Server 上安全運(yùn)行的 T-SQL 代碼。 [轉(zhuǎn)載] 編寫安全的 Transact-SQL（圖二）

返回頁首

保護(hù)開發(fā) SQL Server 的安全

開發(fā)安全 T-SQL 的第一步是保護(hù)開發(fā) SQL Server 的安全。為什么要想方設(shè)法地鎖定一個(gè)不保存真實(shí)數(shù)據(jù)的 SQL Server 實(shí)例，而從不將它展示給最終用戶呢？這是因?yàn)椋@樣會(huì)強(qiáng)制您編寫更安全的 T-SQL，并且當(dāng)將您的應(yīng)用程序部署到生產(chǎn)中時(shí)，也會(huì)更加輕易地保護(hù)該應(yīng)用程序。下面是幾個(gè)具體的步驟，采用這些步驟您就可以快速保護(hù)開發(fā)服務(wù)器： •在開發(fā)或測試 SQL Server 中，至少應(yīng)該有一個(gè)正在運(yùn)行的、最新的 Service Pack 和 SQL 安全修補(bǔ)程序，這樣才能確保您的客戶能夠在此 SQL Server 版本上成功運(yùn)行您的應(yīng)用程序。 •默認(rèn)情況下，SQL Server 2000 Service Pack 3a 會(huì)禁用稱為“交叉數(shù)據(jù)庫所有權(quán)鏈接”的不安全功能。在開發(fā)服務(wù)器上安裝 SP3 時(shí)，假如讓該 Service Pack 禁用“交叉數(shù)據(jù)庫所有權(quán)鏈接”，則有助于驗(yàn)證您正在基于安全的服務(wù)器配置編寫 T-SQL 代碼。 •找出開發(fā) SQL Server 上常見的安全配置問題的一種簡便方法是針對該服務(wù)器運(yùn)行 Microsoft Baseline Security Analyzer。除了這種方法之外，還可以利用本專欄“參考資料”部分列出的資源；這些資源提供了一些附加步驟，可幫助您保護(hù)開發(fā) SQL Server 的安全。通常情況下，保護(hù)開發(fā)服務(wù)器安全的最佳方法，就好似它正在生產(chǎn)環(huán)境中運(yùn)行那樣對它進(jìn)行保護(hù)。您離這個(gè)目標(biāo)越接近，那么就可以越自信于您開發(fā)的代碼可以在一個(gè)安全的生產(chǎn)環(huán)境中正常運(yùn)行。 [轉(zhuǎn)載] 編寫安全的 Transact-SQL（圖二）

返回頁首

以最低權(quán)限帳戶身份進(jìn)行開發(fā)

在開發(fā)過程中，大家都著迷于使用具有 sysadmin 或 dbo SQL Server 權(quán)限的帳戶，直到部署之前才轉(zhuǎn)換為一個(gè)權(quán)限更低的帳戶。使用這種方法存在著一個(gè)問題：將設(shè)計(jì)人員的權(quán)限集還原為最低的所需權(quán)限集與在開發(fā)應(yīng)用程序過程中編寫這些權(quán)限集相比，前者要困難得多。鑒于部署應(yīng)用程序之前您要決定可以取消哪些權(quán)限，所以請不要使用 SQL sysadmin 帳戶開發(fā) T-SQL 代碼。假如使用 SQL sysadmin 帳戶，可能會(huì)造成這樣的結(jié)果，即應(yīng)用程序會(huì)以比所需權(quán)限更多的特權(quán)帳戶運(yùn)行。因此，開發(fā)時(shí)請改為使用具有最低權(quán)限的帳戶。
使用這樣的帳戶進(jìn)行開發(fā)時(shí)，您會(huì)逐漸地升高授予的特定權(quán)限，以 EXEC（執(zhí)行）一些必需的存儲(chǔ)過程、從某些表進(jìn)行 SELECT（選擇）等。請編寫這些 GRANT 語句，以便可以將同樣的最低權(quán)限輕松部署到生產(chǎn)環(huán)境中，而不會(huì)出現(xiàn)任何基于猜測的操作。這種理念同樣適用于測試。執(zhí)行臨時(shí)測試以及結(jié)構(gòu)更加復(fù)雜的測試時(shí)，所使用帳戶擁有的權(quán)限集和用戶權(quán)限應(yīng)該與在生產(chǎn)環(huán)境中所使用帳戶擁有的權(quán)限集和用戶權(quán)限完全相同。在開發(fā)過程中使用最低權(quán)限帳戶的另一個(gè)優(yōu)點(diǎn)在于，您可以避免不小心編寫出需要危險(xiǎn)權(quán)限或過高權(quán)限的代碼。例如，假設(shè)您需要在 T-SQL 中與第三方 COM 組件進(jìn)行交互。為此，一種方法是發(fā)送一個(gè) SQL 批處理命令，它直接調(diào)用 sp_OACreate 和 sp_OAMethod 來操縱該 COM 對象。在應(yīng)用程序使用 sysadmin 帳戶連接 SQL Server 的開發(fā)環(huán)境中，上述方法效果很好。但是，當(dāng)您嘗試將已經(jīng)開發(fā)完成的應(yīng)用程序預(yù)備用于生產(chǎn)部署時(shí)，您就會(huì)發(fā)現(xiàn)假如使用權(quán)限較低的帳戶，那么該方法不會(huì)奏效。為了讓該應(yīng)用程序能夠使用非 sysadmin 帳戶在生產(chǎn)環(huán)境中正常運(yùn)行，您必須針對 sp_OACreate 顯式授予 EXECUTE 權(quán)限。請考慮一下，假如某個(gè)用戶最終找到了一個(gè)方法，可以使用該應(yīng)用程序登錄執(zhí)行任意代碼，并利用此權(quán)限針對 SQL Server 實(shí)例化一個(gè)類似 Scripting.FileSystemObject 的 COM 對象，將會(huì)產(chǎn)生怎樣的安全隱患？ [轉(zhuǎn)載] 編寫安全的 Transact-SQL（圖二）

返回頁首

遵照保護(hù) T-SQL 的最佳方法

防御一系列稱為“SQL 注入式”的安全漏洞是至關(guān)重要的。通常情況下，您會(huì)使用多層防護(hù)來抵御 SQL 注入式攻擊： •執(zhí)行用戶提供輸入的驗(yàn)證（例如，強(qiáng)制數(shù)據(jù)類型和最大字符串長度）。 •轉(zhuǎn)義對數(shù)據(jù)庫引擎可能具有非凡意義的字符序列。在 T-SQL 中，注入式攻擊中最常用的兩個(gè)字符串為單引號(hào)字符 (') 和注釋字符序列 (--)。 •在 T-SQL 語句中，請不要將用戶提供的值進(jìn)行內(nèi)聯(lián)。請改為使用預(yù)處理語句和參數(shù)化。 SQL 注入式攻擊在其他一些地方有具體的說明，所以在此我就不花大量時(shí)間來討論這個(gè)問題的細(xì)節(jié)了。但是要強(qiáng)調(diào)一點(diǎn)，SQL 注入式問題并不只限于在應(yīng)用層構(gòu)建的 T-SQL 查詢。只要執(zhí)行一個(gè)部分由用戶提供值構(gòu)建的 T-SQL 查詢，就可能會(huì)發(fā)生 SQL 注入式問題。這就是說，一個(gè)在內(nèi)部構(gòu)建查詢字符串、并通過 EXEC() 命令或 sp_executesql 存儲(chǔ)過程執(zhí)行該查詢的存儲(chǔ)過程也可能會(huì)受到攻擊。請參閱“參考資料”部分獲得一些資源鏈接，這些資源提供了各種 SQL 注入式攻擊類型的示例，還提供了一些保護(hù)代碼免受這些攻擊的技巧。另一個(gè)最佳方法是避免針對基表授予權(quán)限。對于您希望用戶能夠執(zhí)行的查詢，您應(yīng)該將其打包在存儲(chǔ)過程中，并只對這些存儲(chǔ)過程授予 EXECUTE 權(quán)限。假如您按照本指南進(jìn)行操作，即使用戶設(shè)法跳過了您的應(yīng)用程序，直接登錄到數(shù)據(jù)庫，他們也無法回避您已經(jīng)在存儲(chǔ)過程中構(gòu)建的任何數(shù)據(jù)驗(yàn)證、審核、業(yè)務(wù)規(guī)則或者行級(jí)安全限制。 [轉(zhuǎn)載] 編寫安全的 Transact-SQL（圖二）

返回頁首

了解具有獨(dú)特安全考慮事項(xiàng)的 T-SQL 命令

有一些 T-SQL 命令和擴(kuò)展，它們具有自己獨(dú)特的安全考慮事項(xiàng)。其中一個(gè)是 sp_OACreate 及其相關(guān)的系統(tǒng)過程系列（例如 sp_OAMethod、sp_OAPRoperty 等）。以前，我們曾經(jīng)研究過一個(gè)潛在的安全問題，通過授予應(yīng)用程序登錄直接訪問這些過程的權(quán)限，會(huì)帶來該安全問題。為了避免此問題的發(fā)生，請絕對不要編寫直接調(diào)用 sp_OA 過程的應(yīng)用程序代碼，而要將對這些過程的所有引用都打包在您自己的 T-SQL 存儲(chǔ)過程中，并只授予訪問這些包裝存儲(chǔ)過程的權(quán)限。另外，請不要答應(yīng)應(yīng)用程序代碼將 COM 對象或方法的名稱作為可由包裝過程無條件調(diào)用的字符串進(jìn)行傳遞。另一個(gè)具有獨(dú)特安全風(fēng)險(xiǎn)集的內(nèi)置 SQL Server 擴(kuò)展為 XP_cmdshell。這個(gè)系統(tǒng)存儲(chǔ)過程可以運(yùn)行任何可執(zhí)行文件或系統(tǒng)命令。由于一些很顯然的原因，xp_cmdshell 上的 EXEC 權(quán)限默認(rèn)情況下僅為 sysadmin 用戶，必須顯示地為其他用戶授予該權(quán)限。假如您需要應(yīng)用程序在 SQL Server 上運(yùn)行某個(gè)特定的命令或?qū)嵱贸绦颍瑒t請注重，不要在應(yīng)用程序中構(gòu)建一個(gè) xp_cmdshell 直接訪問的相關(guān)內(nèi)容。這樣的風(fēng)險(xiǎn)與直接訪問 sp_OACreate 的風(fēng)險(xiǎn)相似。一旦為某個(gè)帳戶授予了 xp_cmdshell 的 EXEC 權(quán)限，該帳戶不但能夠執(zhí)行您希望其訪問的特定命令，而且能夠執(zhí)行成百上千個(gè)操作系統(tǒng)命令和其他可執(zhí)行文件。與 sp_OACreate 相似，始終將 xp_cmdshell 調(diào)用打包在另一個(gè)存儲(chǔ)過程中，避免直接在 xp_cmdshell 上授予 EXECUTE 權(quán)限。您還應(yīng)該避免將任何用戶提供的字符串參數(shù)或者應(yīng)用程序提供的字符串參數(shù)與將要通過 xp_cmdshell 執(zhí)行的命令進(jìn)行串聯(lián)。假如無法達(dá)到上述要求，則必須了解，有一個(gè)專門針對 xp_cmdshell 的潛在的代碼注入式攻擊（至少在 SQL Server 中）。以下面的存儲(chǔ)過程為例： CREATE PROCEDURE usp_DoFileCopy @filename varchar(255) ASDECLARE @cmd varchar (8000)SET @cmd = 'copy //src/share/' + @filename + ' //dest/share/'EXEC master.dbo.xp_cmdshell @cmdGOGRANT EXEC ON usp_DoFileCopy TO myapplogin
通過將 xp_cmdshell 調(diào)用打包在您自己的存儲(chǔ)過程中并只針對該 usp_DoFileCopy 存儲(chǔ)過程授予 EXEC 權(quán)限，您已經(jīng)阻止了用戶直接調(diào)用 xp_cmdshell 以執(zhí)行任意命令。然而，以下面的 shell 命令插入為例： EXEC usp_DoFileCopy @filename = ' & del /S /Q //dest/share/ & '使用這個(gè) @filename 參數(shù)，將要執(zhí)行的字符串為 copy //src/share/ & del /S /Q //dest/share/ & //dest/share。和號(hào) (&) 被操作系統(tǒng)命令解釋器處理為命令分隔符，因此該字符串將被 CMD.EXE 視為三個(gè)互不相關(guān)的命令。其中第二個(gè)命令 (del /S /Q //dest/share/) 將嘗試刪除 //dest/share 中的所有文件。通過利用該存儲(chǔ)過程中某個(gè) shell 命令插入漏洞，用戶仍然可以執(zhí)行任意操作系統(tǒng)命令。針對此類攻擊進(jìn)行防御的一種方法是將命令字符串打包在一個(gè) T-SQL 函數(shù)中，如下所示。這個(gè)用戶定義的函數(shù)會(huì)添加 shell 轉(zhuǎn)義符 (^)，對出現(xiàn)的任何 & 字符或其他具有非凡意義的字符進(jìn)行轉(zhuǎn)義。 -- Function: fn_escapecmdshellstring-- Description: Returns an escaped version of a given string-- with carets ('^') added in front of all the special -- command shell symbols. -- Parameter: @command_string nvarchar(4000)--CREATE FUNCTION dbo.fn_escapecmdshellstring ( @command_string nvarchar(4000)) RETURNS nvarchar(4000) ASBEGIN DECLARE @escaped_command_string nvarchar(4000), @curr_char nvarchar(1), @curr_char_index int SELECT @escaped_command_string = N'', @curr_char = N'', @curr_char_index = 1 WHILE @curr_char_index <= LEN (@command_string) BEGIN SELECT @curr_char = SUBSTRING (@command_string, @curr_char_index, 1) IF @curr_char IN ('%', '<', '>', '', '&', '(', ')', '^', '"') BEGIN SELECT @escaped_command_string = @escaped_command_string + N'^' END SELECT @escaped_command_string = @escaped_command_string + @curr_char SELECT @curr_char_index = @curr_char_index + 1 END RETURN @escaped_command_stringEND下面是消除了命令 shell 插入漏洞之后的存儲(chǔ)過程： CREATE PROCEDURE usp_DoFileCopy @filename varchar(255) ASDECLARE @cmd varchar (8000)SET @cmd = 'copy //src/share/' + dbo.fn_escapecmdshellstring (@filename) + ' //dest/share/'EXEC master.dbo.xp_cmdshell @cmd第三個(gè)具有獨(dú)特安全考慮事項(xiàng)的 T-SQL 命令集為那些答應(yīng)執(zhí)行動(dòng)態(tài)構(gòu)建的查詢的命令：EXEC() 和 sp_executesql。SQL 注入式攻擊的風(fēng)險(xiǎn)并不是避免動(dòng)態(tài) SQL 的唯一理由。任何通過這些命令動(dòng)態(tài)執(zhí)行的查詢都將在當(dāng)前用戶的安全上下文中運(yùn)行，而不是在該存儲(chǔ)過程所有者的上下文中運(yùn)行。這就意味著，使用動(dòng)態(tài) SQL 可能會(huì)強(qiáng)制您授予用戶直接訪問基表的權(quán)限。以下面的存儲(chǔ)過程為例： CREATE PROC dbo.usp_RetrieveMyUserInfo AS SELECT * FROM UserInfo WHERE UserName = USER_NAME()此過程會(huì)限制當(dāng)前用戶，使其無法查看其他任何用戶的數(shù)據(jù)。但是，假如此過程中的 SELECT 語句是通過動(dòng)態(tài) EXEC() 或通過 sp_executesql 執(zhí)行的，您則必須授予用戶對 UserInfo 表的直接 SELECT 權(quán)限，這是因?yàn)檫@個(gè)動(dòng)態(tài)執(zhí)行的查詢是在當(dāng)前用戶的安全上下文中運(yùn)行的。假如用戶能夠直接登錄服務(wù)器，他們則可以使用此權(quán)限跳過該存儲(chǔ)過程提供的行級(jí)安全，查看所有用戶的數(shù)據(jù)。 [轉(zhuǎn)載] 編寫安全的 Transact-SQL（圖二）

返回頁首

小結(jié)

總而言之，下面的建議將有助于您開發(fā)在 SQL Server 中安全運(yùn)行的 T-SQL 代碼： •保護(hù)您的開發(fā) SQL Server 的安全，就似乎它是一個(gè)生產(chǎn)服務(wù)器一樣。這樣有助于確保您開發(fā)安全的代碼，還可以幫助您定義應(yīng)用程序正常運(yùn)行所需的最低權(quán)限集。 •進(jìn)行 T-SQL 開發(fā)和測試時(shí)請使用具有最低權(quán)限的 SQL Server 帳戶。不要使用 sysadmin 或 dbo 帳戶。 •對于答應(yīng) T-SQL 執(zhí)行任意外部代碼的存儲(chǔ)過程，要非常注重，如 sp_OACreate 和 xp_cmdshell。假如必須使用這些擴(kuò)展，則一定要考慮它們獨(dú)特的安全隱患。 •請遵照保護(hù) T-SQL 開發(fā)的最佳方法，其中包括：將用戶提供的數(shù)據(jù)以顯式參數(shù)進(jìn)行傳遞、編寫可避免 SQL 注入式攻擊的代碼、避免使用不必要的動(dòng)態(tài) SQL、授予訪問存儲(chǔ)過程的權(quán)限而不要授予直接訪問基表的權(quán)限。 •
安全的 T-SQL 才能構(gòu)成安全的應(yīng)用程序。利用下面的資源可以確保您的服務(wù)器進(jìn)行了安全配置，并確保您擁有一個(gè)安全的數(shù)據(jù)庫客戶端應(yīng)用程序。 [轉(zhuǎn)載] 編寫安全的 Transact-SQL（圖二）

返回頁首

參考資料

SQL Server Security Resource PageBuilding Secure ASP.NET applications: Authentication, Authorization, and Secure CommunicationSQL Server 2000 SP3 Security Features and Best Practices: Secure Multi-tier Deployment

上一篇：如何獲得當(dāng)前數(shù)據(jù)庫的SCN值

下一篇：數(shù)據(jù)庫Identity+Primarykey字段強(qiáng)行插入的處理