declare @p1 varchar(1000)
declare @sql varchar(1000)
set @p1="a';select 123 -- or 1=1"
set @sql="select * from sysobjects where name='"+@p1+"'"
exec(@sql)
go

------解决方案--------------------
我把代码写的更复杂一点看得更清楚：
SQL code
declare @p1 varchar(1000)
declare @sql varchar(1000)
set @p1="a';select 123 --"
set @sql="select * from sysobjects where name='"+@p1+"' and id=-103"
exec(@sql)
go

------解决方案--------------------
关键是parameter 和存储过程就根本没有关系 不妨写几个注入语句 亲身体验之后就知道了

------解决方案--------------------
LZ这个问题就好比杀毒软件和病毒.目前还没有哪款杀毒软件能真正做到把病毒拘之系统之外.MS几乎每个月都有补丁.但是还是有那么多的攻击/
存储过程+参数不是万能的.但相对于你的拼接SQL是要安全的很多..


------解决方案--------------------
首先 单纯的存储过程根本就不能防SQL注入！
倒是 参数可以过滤SQL注入。

------解决方案--------------------
额，参数也要看什么参数的,楼主说的有一定道理
但是传参不是这么拼凑sql啊

cmd.Parameters.Add("@Tags", System.Data.SqlDbType.NVarChar, 255).Value = xxx;
实际上类似这样的都可以过滤，'被替换成''等等．．
不过不要以为这样就安全了　

create proc xxxx
...
  @SearchSQL NText,
....
AS
....

Insert  into #IDs(PhotoID) exec(@SearchSQL)


像这种参数，在存储过程中执行sql，可以被注入．．不信试试

------解决方案--------------------
恩，参数化查询不应该这么拼接sql
@p1="a' or 1=1" 
set @sql="select * from table where name='"+[@p1]+"'"  
exec(@sql)


正确的方法应该是
sql = "select * from table where name=@name"
cmd.Parameters("@name" ........)

如果是用存储过程，应该在存储过程里面执行 select * from table where name=@name
而不是exec(@sql)，这样和普通拼接sql没有什么区别

实际应用根据要求来定，比如模糊搜索功能，用LIKE '%words%'，这种时候应该进行安全过滤

------解决方案--------------------