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

[骄傲青蛙]

-- 一般来说, 都把传入的参数当字符串处理,

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连起来, 好像在执行一个字符串. .

[trainee]

可以注入

[骄傲青蛙]

是的, 我把参数里传 where 1=1 都成立了

怎么可能不注入,


看来别人说存储过程是防sql 注入在某种情况下不成立

[骄傲青蛙]

[Quote=引用 2 楼 nianzhang747 的回复:]

................

就是不知道mysql的concat在存储过程中能不能处理参数了

[/Quote]

concat存储过程中处理参数?

不明白, 能解释一下吗? 怎么处理?

[ACMAIN_CHM]

不需要处理了。

prepare 中只能包含一个正确的SQL语句，所以无法注入。 你已经限定了 select 开头。所以很难再执行什么 insert / update 之类的语句了。

当然如果你用于验证登录信息的话，则可能出现 select .. .where 1=1 or 这样情况。但你只是用用分页，则不必担心了。

[liangzzzzzzz]

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

[nianzhang747]

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

[ACMAIN_CHM]

应该不会了。

[nianzhang747]

你给_table传个参数

_table="tbname limit 1";

看看有没有注入不就知道了吗

目前看起来能侏儒
就是不知道mysql的concat在存储过程中能不能处理参数了

[骄傲青蛙]

[Quote=引用 10 楼 trainee 的回复:]
引用 4 楼 coolesting 的回复:
看来别人说存储过程是防sql 注入在某种情况下不成立


之前在MSSQL看到这个讨论，说存储过程能防SQL注入。
提出这论调的人，是以偏盖全，误导人家。

只要你的存储过程存在动态构造语句，就有可能注入的可能，你就要检测所输入的变量，以满足你的原来的设计需求
对象名（字段、表名）以参数形式传入，存储过程是不能直接引用的,必须构造动态语句，所以注入（或者认为违背了设计需求）是不可避免的。

但如果是以下形式，参数传入是可以防注入：
SQL codecreateprocedure ...in _abcvarchar(100),select*from xxxwhere id=_abc
即使不用存储过程，某些接口如ADO的参数化语句执行也是可以防入的。

[/Quote

存储过程本来就是这样用， 但有时写程序的人可能无意设计错误。

[trainee]

[Quote=引用 4 楼 coolesting 的回复:]
看来别人说存储过程是防sql 注入在某种情况下不成立
[/Quote]

之前在MSSQL看到这个讨论，说存储过程能防SQL注入。
提出这论调的人，是以偏盖全，误导人家。

只要你的存储过程存在动态构造语句，就有可能注入的可能，你就要检测所输入的变量，以满足你的原来的设计需求
对象名（字段、表名）以参数形式传入，存储过程是不能直接引用的,必须构造动态语句，所以注入（或者认为违背了设计需求）是不可避免的。

但如果是以下形式，参数传入是可以防注入：

create procedure ... 
  in _abc varchar(100), 

     select * from xxx where id=_abc

即使不用存储过程，某些接口如ADO的参数化语句执行也是可以防入的。