存储过程不让拼接SQL语句

公司DBA不允许创建的存储过程中有拼接SQL语句的行为,请问,该怎么解决?说是这样做有风险,说我非要用的话,可以签一份风险协议,出了问题我负责之类的。请问:各位在多条件查询这种情况下,存储过程都是怎么写的?有不拼接又省事的办法吗?另外,这个风险难道微软没有提供解决方案吗?

8个回答

真正的风险, 不在于拼SQL, 而是输入值没有参数化。
比如:
delare @sql nvarchar(max), @name nvarchar(20)
set @name='小明'
set @sql = 'select * from user where username like ''%'+@name+'%'''
--下面有风险
exec (@sql)
--下面这种无风险
set @sql = 'select * from user where username like ''%@name%'''
exec sp_executesql
@stmt=@sql,
@params =N'@name as nvarchar(20)',
@name=@name

其实道理很简单, 如果都是sqlserver内部、数据库内部、你自己写的东西 比如 select , from , where 之类的肯定没有问题, 不用怕。
怕的是什么呢?怕的是外部传过来的东西——比如上面的@name, 这个是从网站的页面传过来的, 如果不用参数化, 绝对有sql注入风险!

sql注入

如果你还有疑问, 可以列出具体的例子来, 我可以为你尽力解答!

拼接sql是可能被注入的,所以尽量少用加号来拼接,可以用参数的形式进行参数化查询

存储过程参数化啊 我们公司都是这么做的 比拼接sql即方便又效率还易懂。

看你用的什么开发环境,拼接的解决方案 现在只有 oracle + java 可以实现 ,真正的实现 语句和参数的分离 。 现在市场所有的 orm 的最终 运行都是 拼接出来的 sql。
普通的 关系型数据库 例如 mysql mssql 等 只能是在 数据类型方面 和 符号转换方面做文章了。

可以拼接,使用参数或者直接拼接就而已了。

多搞几个参数吧,为了安全规范,总要牺牲点什么。忍了吧。

使用SQLiteDatabase,传参的形式查询
SQLiteDatabase db = helper.getReadableDatabase();
Cursor c = db.query("TableName", null, null, null, null, null, null);
具体参见http://www.cnblogs.com/maxinliang/archive/2013/01/22/2871474.html

Csdn user default icon
上传中...
上传图片
插入图片
抄袭、复制答案,以达到刷声望分或其他目的的行为,在CSDN问答是严格禁止的,一经发现立刻封号。是时候展现真正的技术了!
立即提问