存储过程在这样的情况下还能防sql注入吗?

Question

  -- 一般来说, 都把传入的参数当字符串处理, create procedure ...
  in _field varchar(100),
  in _table varchar(100),
  ...
  ...   SET @strSql = CONCAT('SELECT ',_field,' FROM ',_table);
   
   PREPARE stmt FROM @strSql;
   EXECUTE stmt;
   DEALLOCATE PREPARE stmt;... 
  -- 这样的情况下还能防注入吗? 
  -- 用CONCAT连起来, 好像在执行一个字符串. .

Answer 1

你给_table传个参数_table="tbname limit 1";看看有没有注入不就知道了吗目前看起来能侏儒
就是不知道mysql的concat在存储过程中能不能处理参数了

Answer 2

是的, 我把参数里传 where 1=1 都成立了怎么可能不注入, 
看来别人说存储过程是防sql 注入在某种情况下不成立

Answer 3

concat存储过程中处理参数?  不明白, 能解释一下吗?  怎么处理?  

Answer 4

不需要处理了。prepare 中只能包含一个正确的SQL语句，所以无法注入。 你已经限定了 select 开头。所以很难再执行什么 insert / update 之类的语句了。当然如果你用于验证登录信息的话，则可能出现 select .. .where 1=1 or 这样情况。但你只是用用分页，则不必担心了。

Answer 5

学习，原来prepare只能包含一个正确的语句，之前还以为只是预处理不检查。

Answer 6

prepare
对 防止注入 你想啊 mysql存储过程让你注入 mysql傻啊

Answer 7

之前在MSSQL看到这个讨论，说存储过程能防SQL注入。
提出这论调的人，是以偏盖全，误导人家。只要你的存储过程存在动态构造语句，就有可能注入的可能，你就要检测所输入的变量，以满足你的原来的设计需求
对象名（字段、表名）以参数形式传入，存储过程是不能直接引用的,必须构造动态语句，所以注入（或者认为违背了设计需求）是不可避免的。但如果是以下形式，参数传入是可以防注入：
create procedure ... 
  in _abc varchar(100),      select * from xxx where id=_abc
即使不用存储过程，某些接口如ADO的参数化语句执行也是可以防入的。

Answer 8

[Quote=引用 10 楼 trainee 的回复:]
引用 4 楼 coolesting 的回复:
 看来别人说存储过程是防sql 注入在某种情况下不成立
 之前在MSSQL看到这个讨论，说存储过程能防SQL注入。
 提出这论调的人，是以偏盖全，误导人家。 只要你的存储过程存在动态构造语句，就有可能注入的可能，你就要检测所输入的变量，以满足你的原来的设计需求
 对象名（字段、表名）以参数形式传入，存储过程是不能直接引用的,必须构造动态语句，所以注入（或者认为违背了设计需求）是不可避免的。 但如果是以下形式，参数传入是可以防注入：
SQL codecreateprocedure ...in _abcvarchar(100),select*from xxxwhere id=_abc
 即使不用存储过程，某些接口如ADO的参数化语句执行也是可以防入的。[/Quote存储过程本来就是这样用， 但有时写程序的人可能无意设计错误。