MS Sql Server中存储过程与触发器的安全隐患

MS Sql Server中存储过程与触发器的安全隐患

       存储过程与触发器是Sql Server进行数据库开发与管理经常使用的两个对象，但是如果对存储过程与触发器的权限设置不当，则会给数据库带来巨大的安全隐患，抑或是MS就是这么设计的，是本人杞人忧天。本文测试环境：sql server2005。鉴于本人水平有限，欢迎大家进行讨论，如果不对之处，请大家手下留情，轻些拍砖。下面分别进行说明。

首先，建立测试环境

建立测试数据库 create database test

在测试数据库中建立两张表

create table t1(id int ,name varchar(10))

create table t2(id int ,name varchar(10))

向t2表中插入一行数据

insert into t2

select 1,'trieagle'

建立sql身份验证的登陆账号 trieagle ，同时test数据库中建立用trieagle

       一、存储过程

情景说明：如果某用户拥有创建和执行存储过程的权限，则该用户可以建立一个存储过程，在该存储过程操作其他表中的数据。那么即使该用户对其他表没有操作权限，则调用该存储过程，可以对其他表中的数据进行操作。

1、为trieagle用户授予创建存储过程的权限以及执行存储过程的权限

grant create proc to trieagle

注意：trieagle用户要创建存储过程的话，可能还需要修改schema的权限

grant alter on schema :: dbo to trieagle

2、trieagle建立存储过程

Create proc p1

as

select * from t2    

3、向trieagle用户赋予执行p1存储过程的权限

grant exec on p1 to trieagle

4、trieagle执行p1存储过程

   Exec P1

结果

Id    name

1     trieagle

成功的查看到t2表中的数据。

安全隐患在于：如果用户能够执行、修改存储过程的话，那么实际上你的数据库中的数据是出于一种既不安全的状态。

解决方法：如果该允许某个用户创建存储过程的话，让该用户在其自己的schema上来创建，这样可以避免上述问题。即：

管理员：grant create schema to trieagle

用户：create schema trieagle

Go

Create proc trieagle.p1

as

select * from t2

              go

Exec trieagle.P1

结果：

消息229，级别14，状态5，过程p1，第3 行

拒绝了对对象't2' (数据库'test'，架构'dbo')的SELECT 权限。

同样的情况在oracle上也存在，oracle的解释是：执行者执行存储过程时，会使用存储过程设计者所具有的权限，但是可以使用authid current_user指定用户运行存储过程时使用的权限。Sql server中有类似的语句是在execute as ，但使用方法还未学习，例如：

create proc p1

with execute as 'trieagle'

as

select * from t2 

二、触发器

  情景说明：如果某用户拥有修改表的权限以及向表中有（insert、update、delete）权限之一的话，则该用户即可创建触发器。那么该用户在触发器中可以查看其他表的数据，甚至插入、修改、删除其他表的数据，即使该用户对其他表没有任何的操作权限。

一、建立测试环境

为trieagle用户授予向t1插入数据的权限，以及修改t1的权限

     grant alter on t1 to trieagle

     grant insert on t1 to trieagle

     注意，在此并没有为trieagle用户赋予t2表的任何权限

二、trieagle用户创建触发器

create trigger t_query_t2

on t1

for insert

as

select * from t2

三、trieagle向t1表中插入数据

insert into t1  select 2,'wang'

观察结果，你会发现，会成功显示t2表中的数据。结果：

Id    name

trieagle

安全隐患在于：如果用户能够创建触发器，并且在该表上有insert、update、delete权限之一的话，则实际上你的数据库中的数据是出于一种不安全的状态。