以最低权限帐户身份进行开发
在开发过程中，大家都着迷于使用具有 sysadmin 或 dbo SQL Server 权限的帐户，直到部署之前才转换为一个权限更低的帐户。使用这种方法存在着一个问题：将设计人员的权限集还原为最低的所需权限集与在开发应用程序过程中编写这些权限集相比，前者要困难得多。
鉴于部署应用程序之前您要决定可以取消哪些权限，所以请不要使用 SQL sysadmin 帐户开发 T-SQL 代码。如果使用 SQL sysadmin 帐户，可能会造成这样的结果，即应用程序会以比所需权限更多的特权帐户运行。因此，开发时请改为使用具有最低权限的帐户。
使用这样的帐户进行开发时，您会逐渐地升高授予的特定权限，以 EXEC（执行）一些必需的存储过程、从某些表进行 SELECT（选择）等。请编写这些 GRANT 语句，以便可以将同样的最低权限轻松部署到生产环境中，而不会出现任何基于猜测的操作。
这种理念同样适用于测试。执行临时测试以及结构更加复杂的测试时，所使用帐户拥有的权限集和用户权限应该与在生产环境中所使用帐户拥有的权限集和用户权限完全相同。
在开发过程中使用最低权限帐户的另一个优点在于，您可以避免不小心编写出需要危险权限或过高权限的代码。例如，假设您需要在 T-SQL 中与第三方 COM 组件进行交互。为此，一种方法是发送一个 SQL 批处理命令，它直接调用 sp_OACreate 和 sp_OAMethod 来操纵该 COM 对象。在应用程序使用 sysadmin 帐户连接 SQL Server 的开发环境中，上述方法效果很好。但是，当您尝试将已经开发完成的应用程序准备用于生产部署时，您就会发现如果使用权限较低的帐户，那么该方法不会奏效。为了让该应用程序能够使用非 sysadmin 帐户在生产环境中正常运行，您必须针对 sp_OACreate 显式授予 EXECUTE 权限。请考虑一下，如果某个用户最终找到了一个方法，可以使用该应用程序登录执行任意代码，并利用此权限针对 SQL Server 实例化一个类似 Scripting.FileSystemObject 的 COM 对象，将会产生怎样的安全隐患？
了解具有独特安全考虑事项的 T-SQL 命令
有一些 T-SQL 命令和扩展，它们具有自己独特的安全考虑事项。其中一个是 sp_OACreate 及其相关的系统过程系列（例如 sp_OAMethod、sp_OAProperty 等）。以前，我们曾经研究过一个潜在的安全问题，通过授予应用程序登录直接访问这些过程的权限，会带来该安全问题。为了避免此问题的发生，请绝对不要编写直接调用 sp_OA 过程的应用程序代码，而要将对这些过程的所有引用都打包在您自己的 T-SQL 存储过程中，并只授予访问这些包装存储过程的权限。另外，请不要允许应用程序代码将 COM 对象或方法的名称作为可由包装过程无条件调用的字符串进行传递。
另一个具有独特安全风险集的内置 SQL Server 扩展为 xp_cmdshell。这个系统存储过程可以运行任何可执行文件或系统命令。由于一些很显然的原因，xp_cmdshell 上的 EXEC 权限默认情况下仅为 sysadmin 用户，必须显示地为其他用户授予该权限。如果您需要应用程序在 SQL Server 上运行某个特定的命令或实用程序，则请注意，不要在应用程序中构建一个 xp_cmdshell 直接访问的相关内容。这样的风险与直接访问 sp_OACreate 的风险相似。一旦为某个帐户授予了 xp_cmdshell 的 EXEC 权限，该帐户不但能够执行您希望其访问的特定命令，而且能够执行成百上千个操作系统命令和其他可执行文件。与 sp_OACreate 相似，始终将 xp_cmdshell 调用打包在另一个存储过程中，避免直接在 xp_cmdshell 上授予 EXECUTE 权限。
您还应该避免将任何用户提供的字符串参数或者应用程序提供的字符串参数与将要通过 xp_cmdshell 执行的命令进行串联。如果无法达到上述要求，则必须了解，有一个专门针对 xp_cmdshell 的潜在的代码注入式攻击（至少在 SQL Server 中）。以下面的存储过程为例：
CREATE PROCEDURE usp_DoFileCopy @filename varchar(255) AS
DECLARE @cmd varchar (8000)
SET @cmd = 'copy \\src\share\' + @filename + ' \\dest\share\'
EXEC master.dbo.xp_cmdshell @cmd
GO
GRANT EXEC ON usp_DoFileCopy TO myapplogin
通过将 xp_cmdshell 调用打包在您自己的存储过程中并只针对该 usp_DoFileCopy 存储过程授予 EXEC 权限，您已经阻止了用户直接调用 xp_cmdshell 以执行任意命令。然而，以下面的 shell 命令插入为例：
EXEC usp_DoFileCopy @filename = ' & del /S /Q \\dest\share\ & '
使用这个 @filename 参数，将要执行的字符串为 copy \\src\share\ & del /S /Q \\dest\share\ & \\dest\share。和号 (&) 被操作系统命令解释器处理为命令分隔符，因此该字符串将被 CMD.EXE 视为三个互不相关的命令。其中第二个命令 (del /S /Q \\dest\share\) 将尝试删除 \\dest\share 中的所有文件。通过利用该存储过程中某个 shell 命令插入漏洞，用户仍然可以执行任意操作系统命令。针对此类攻击进行防御的一种方法是将命令字符串打包在一个 T-SQL 函数中，如下所示。这个用户定义的函数会添加 shell 转义符 (^)，对出现的任何 & 字符或其他具有特殊意义的字符进行转义。
-- 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) AS
BEGIN
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_string
END
下面是消除了命令 shell 插入漏洞之后的存储过程：
CREATE PROCEDURE usp_DoFileCopy @filename varchar(255) AS
DECLARE @cmd varchar (8000)
SET @cmd = 'copy \\src\share\'
+ dbo.fn_escapecmdshellstring (@filename)
+ ' \\dest\share\'
EXEC master.dbo.xp_cmdshell @cmd
第三个具有独特安全考虑事项的 T-SQL 命令集为那些允许执行动态构建的查询的命令：EXEC() 和 sp_executesql。SQL 注入式攻击的风险并不是避免动态 SQL 的唯一理由。任何通过这些命令动态执行的查询都将在当前用户的安全上下文中运行，而不是在该存储过程所有者的上下文中运行。这就意味着，使用动态 SQL 可能会强制您授予用户直接访问基表的权限。以下面的存储过程为例：
CREATE PROC dbo.usp_RetrieveMyUserInfo AS
SELECT * FROM UserInfo WHERE UserName = USER_NAME()
此过程会限制当前用户，使其无法查看其他任何用户的数据。但是，如果此过程中的 SELECT 语句是通过动态 EXEC() 或通过 sp_executesql 执行的，您则必须授予用户对 UserInfo 表的直接 SELECT 权限，这是因为这个动态执行的查询是在当前用户的安全上下文中运行的。如果用户能够直接登录服务器，他们则可以使用此权限跳过该存储过程提供的行级安全，查看所有用户的数据。
