SQLServer 2008中的代码安全（一） 存储过程加密与安全上下文

最近对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

未加密的存储过程：

加密的存储过程：

此时，至少，存储过程的内容不会被轻易看到（虽然解密也是有可能的）。应用这个，我们可以对某些关键的存储过程进行加密。但此时，存储过程仍然能被。

除了加密sql文本的内容，我们还可以使用EXECUTE AS 子句设定存储过程的安全上下文，以满足不同的安全级别需求。

(关于EXECUTE AS 子句的详细用法，请参看MSDN:

此处，我们需要了解的是：

针对函数、过程、队列和触发器，对应的参数也不同。存储过程对应的参数包括（CALLER | SELF | OWNER | 'user_name'）。

指定模块内的语句在模块调用方的上下文中执行。执行模块的用户不仅必须对模块本身拥有适当的权限，还要对模块引用的任何数据库对象拥有适当权限。 CALLER 是除队列外的所有模块的默认值，与 SQL Server 2005 行为相同。 CALLER 不能在 CREATE QUEUE 或 ALTER QUEUE 语句中指定。