通用分页存储过程真的有注入漏洞吗?

核心提示：今天看了两篇关于存储过程SQL注入漏洞的文章: 1):如此高效通用的分页存储过程是带有sql注入漏洞的2):防SQL注入：生成参数化的通用分页查询语句 怎么看怎么觉的别扭,在我印象中存储过程是不会存在注入漏洞的啊?起码我目前的水平还不了解如何注入存储过程，如果大家有注入的方法请指教，通用分页存储过程真的有注入漏洞吗?，

今天看了两篇关于存储过程SQL注入漏洞的文章:

1):如此高效通用的分页存储过程是带有sql注入漏洞的

2):防SQL注入：生成参数化的通用分页查询语句

怎么看怎么觉的别扭,在我印象中存储过程是不会存在注入漏洞的啊?起码我目前的水平还不了解如何注入存储过程。如果大家有注入的方法请指教。换句话说存储过程本身并无注入漏洞，只不过有漏洞大多都是因为程序漏洞导致。

我们来简化下之前两位园友讨论的分页存储过程,原代码太长,我这里呢写一个针对一个单表查询的存储过程。创建一个用户表,表结构如下:有三个字段，人员ID，姓名字段。

CREATE TABLE [dbo].[person](
　 [id] [int] NULL,
　 [last_name] [varchar](30) COLLATE Chinese_PRC_CI_AS NULL,
　 [first_name] [varchar](30) COLLATE Chinese_PRC_CI_AS NULL
) ON [PRIMARY]

然后写一个查询存储过程（getPerson）:作用，根据不同的条件读取用户信息。

IF ( EXISTS ( SELECT　　*
　　　　　　　FROM　　　sysobjects
　　　　　　　WHERE　　 id = OBJECT_ID(N'[dbo].[getPerson]')
　　　　　　　　　　　　AND OBJECTPROPERTY(id, N'IsProcedure') = 1 ) )
　　BEGIN
　　　　DROP PROCEDURE [dbo].[getPerson]
　　END
Go
CREATE PROC getPerson
　　@strWhere VARCHAR(100) = '' -- 查询条件 (注意: 不要加 where)
AS
　　BEGIN
　　　　DECLARE @strSQL VARCHAR(1000) -- 主语句
　　　　SET @strSQL = 'select top 10 * from person where 1=1 '
　 --如果存在条件,则加上
　　　　IF @strWhere != ''
　　　　　　BEGIN
　　　　　　　　SET @strSQL = @strSQL + @strWhere　 　　　
　　　　　　END
　　　　PRINT ( @strSQL )
　　　　EXEC ( @strSQL
　　　　　　)
　　END