34,594
社区成员
发帖
与我相关
我的任务
分享请发表友善的回复…
发表回复
mlxwl2013 2013-12-13
- 打赏
- 举报
你这话等于没说，要搞清楚了‘’原理‘’，我还就不问这个了。[/quote]
那我给你说下结果吧， 结果是不能。
关于SQL注入的源理，百度搜，先学学吧， 弄不懂的地方再来问。[/quote]
现在我问的不就是弄不懂的地方吗？sql注入的原理，百度有很多篇了，难辨真伪，关于能否完全防止注入，有些说能，有些说不能。你说不能，最好说下原因，举个简单易懂的反例。
發糞塗牆 2013-12-13
- 打赏
- 举报
攻击永远比防御强，而且不存在没有漏洞的系统，“完全”防止是不可能的，只能说把现有出现过和能预估的风险降低而已
fcuandy 2013-12-13
- 打赏
- 举报
你这话等于没说，要搞清楚了‘’原理‘’，我还就不问这个了。[/quote]
那我给你说下结果吧， 结果是不能。
关于SQL注入的源理，百度搜，先学学吧， 弄不懂的地方再来问。
LongRui888 2013-12-13
- 打赏
- 举报
我觉得参数化应该能完全解决注入问题，至少一般的增删查改用参数化是非常安全的
[/quote]
对了，你看了上面版主贴的连接不，里面说参数化也不能完全防止sql注入，他说只有重用执行计划，才能防止sql注入，你觉得说的对吗？[/quote]我觉得那篇写得有些问题，下面的评论质疑的也很多，我个人赞同45，46楼的说法[/quote]
嗯，我看了一下，也觉得这个文章写的不太对，觉得这个参数化查询是否能解决 sql注入，和这个执行计划重用，一点关系也没有。
不过，他里面的sp_executesql 确实能防止参数注入，而且这个很exec 拼接的动态语句，还不太一样。
[/quote]
对了，你看了上面版主贴的连接不，里面说参数化也不能完全防止sql注入，他说只有重用执行计划，才能防止sql注入，你觉得说的对吗？[/quote]我觉得那篇写得有些问题，下面的评论质疑的也很多，我个人赞同45，46楼的说法[/quote]
嗯，我看了一下，也觉得这个文章写的不太对，觉得这个参数化查询是否能解决 sql注入，和这个执行计划重用，一点关系也没有。
不过，他里面的sp_executesql 确实能防止参数注入，而且这个很exec 拼接的动态语句，还不太一样。mlxwl2013 2013-12-13
- 打赏
- 举报
我觉得参数化应该能完全解决注入问题，至少一般的增删查改用参数化是非常安全的[/quote]
对了，你看了上面版主贴的连接不，里面说参数化也不能完全防止sql注入，他说只有重用执行计划，才能防止sql注入，你觉得说的对吗？[/quote]我觉得那篇写得有些问题，下面的评论质疑的也很多，我个人赞同45，46楼的说法
[/quote]
对了，你看了上面版主贴的连接不，里面说参数化也不能完全防止sql注入，他说只有重用执行计划，才能防止sql注入，你觉得说的对吗？[/quote]我觉得那篇写得有些问题，下面的评论质疑的也很多，我个人赞同45，46楼的说法LongRui888 2013-12-13
- 打赏
- 举报
我觉得参数化应该能完全解决注入问题，至少一般的增删查改用参数化是非常安全的[/quote]
对了，你看了上面版主贴的连接不，里面说参数化也不能完全防止sql注入，他说只有重用执行计划，才能防止sql注入，你觉得说的对吗？
[/quote]
对了，你看了上面版主贴的连接不，里面说参数化也不能完全防止sql注入，他说只有重用执行计划，才能防止sql注入，你觉得说的对吗？mlxwl2013 2013-12-13
- 打赏
- 举报
我觉得参数化应该能完全解决注入问题，至少一般的增删查改用参数化是非常安全的
mlxwl2013 2013-12-13
- 打赏
- 举报
你这话等于没说，要搞清楚了‘’原理‘’，我还就不问这个了。
fcuandy 2013-12-13
- 打赏
- 举报
你先了解下什么是SQL注入的原理， 然后就知道参数化怎么防注入，到底能不能完全防注入。
LongRui888 2013-12-13
- 打赏
- 举报
参数化也不能完全解决 sql注入问题，还是建议你使用其他的，比如 正则表达式等过滤特殊字符：
如何防止sql注入
http://www.blogjava.net/GavinMiao/archive/2011/08/24/357182.html
mlxwl2013 2013-12-13
- 打赏
- 举报
不在sql里执行execute这种动态执行的东东，用参数化应该不会有问题了吧。
或者说只在.net里执行比较简单的增删查改语句，并且用参数化，应该不会被注入？是这样吗？
[/quote] 一般来说是的。[/quote]
本贴加到了88分，感谢大家解答。
mlxwl2013 2013-12-13
- 打赏
- 举报
不在sql里执行execute这种动态执行的东东，用参数化应该不会有问题了吧。
或者说只在.net里执行比较简单的增删查改语句，并且用参数化，应该不会被注入？是这样吗？
[/quote] 一般来说是的。[/quote]
明白了，多谢大牛指点。
fcuandy 2013-12-13
- 打赏
- 举报
不在sql里执行execute这种动态执行的东东，用参数化应该不会有问题了吧。
或者说只在.net里执行比较简单的增删查改语句，并且用参数化，应该不会被注入？是这样吗？
[/quote] 一般来说是的。
mlxwl2013 2013-12-13
- 打赏
- 举报
不在sql里执行execute这种动态执行的东东，用参数化应该不会有问题了吧。
或者说只在.net里执行比较简单的增删查改语句，并且用参数化，应该不会被注入？是这样吗？
fcuandy 2013-12-13
- 打赏
- 举报
execute('select * from tb where id=' + @id + ' and name=''' + @name + '''')
上面有手误，更正一下。
mlxwl2013 2013-12-13
- 打赏
- 举报
嗯，麻烦您打了那么多，谢谢了。
fcuandy 2013-12-13
- 打赏
- 举报
补充一点上贴，
实际注入中，并不是我上面写的那么简单，因为一般情况，你不知道别人的库结构是如何的，
这时候其实要靠注入经验、猜测、还要看当前的数据库帐号权限有多大等等。
当然， 即便当前帐号只有对业务表的操作权 不能威胁到服务器，那么你想想， 一条update 金额已经有足够大的损失了。
最直观的反例是sql_excutesql里面还在拼SQL，这个是最容易表述也是最简单的， 这样的方式就完全没有用。 这个告诉我们， 不要以为别人说怎么样就可以怎么样了， 你懂了原理，就知道这些东西不能道听途说。 区分真伪的能力在于你掌握了多少。
create proc p
(@id int,
@name varchar(10))
as
begin
execute('select * from tb where id=' + @id + ' and name=''' + @name + ''')
end
go
fcuandy 2013-12-13
- 打赏
- 举报
你这话等于没说，要搞清楚了‘’原理‘’，我还就不问这个了。[/quote]
那我给你说下结果吧， 结果是不能。
关于SQL注入的源理，百度搜，先学学吧， 弄不懂的地方再来问。[/quote]
现在我问的不就是弄不懂的地方吗？sql注入的原理，百度有很多篇了，难辨真伪，关于能否完全防止注入，有些说能，有些说不能。你说不能，最好说下原因，举个简单易懂的反例。
[/quote]
你这话等于没说，要搞清楚了‘’原理‘’，我还就不问这个了。[/quote]
那我给你说下结果吧， 结果是不能。
关于SQL注入的源理，百度搜，先学学吧， 弄不懂的地方再来问。[/quote]
现在我问的不就是弄不懂的地方吗？sql注入的原理，百度有很多篇了，难辨真伪，关于能否完全防止注入，有些说能，有些说不能。你说不能，最好说下原因，举个简单易懂的反例。
[/quote]
这么说吧.
注入的思想就是构造非法的sql语句。
string sql="select * from tb where username='" + username + "'";
现在如果，我大概知道你的管理员表的表名是 admins, 我要往里面加一条记录，或者清空你的管理员表, 针对于上面一条语句， 我需要构造的sql语句原型是:
select * from tb where username='xxx'; truncate table admins
然后，注入的本质，就是通过构造字串， 让string sql这个变量的值成为我们想要构造的那条语句
当username的值为 aa';truncate table admins --
拼接的结果就成了
string sql = "select * from tb where username='aa';truncate table admins --'";
那么目的就达到了。
这种是最简单和基础的注入。
我们知道， .net或者其它语言里，在使用sqlserver为数据库， 以传参的方式执行的时候，在数据库端实际上是以 sp_executelsql 的方式实现的（关于这一点，你通过事件探查器就可以看到).
当给 string sql= "select ...where username=@username"
@username已经在param里被定义为了字串类型, 即便 字串里有单引号，分号，SQL里的注释号， 这些都会被当作字串来处理，而不会当作sql里的定界符、指定符等等
当给@username传值为 "aa';truncate table admins --" 时
单引号被转义了， 用SQL来描述的话
相当于
declare @username varchar(xxx)
@username='aa'';truncate table admins --'
整条SQL语句的作用实际上把 'aa'';truncate table admins --' 当作name值代入表中进行检索， 避免了注入的问题.
这样说应该可以理解吗？
同理，像 string sql="select ... where id=" + id.tostring();
像c#这样的语言，因为id强类型为int, 这里一般情况下.net代码会报错，也能避免这种问题
像vb这类弱类型的语言， where id=" + id, 就经常出现这种问题, 对于这类语言，一种是强制要求变量及类型定义， 一种是用类似于isnumeric之类的函数去检测.
好了， 基本的注入方式我讲了一下，
现在举个反例， 倒底参数方式能不能防注入, 先回贴，下贴继续
發糞塗牆 2013-12-13
- 打赏
- 举报
找不到那本书了，自己找找吧
mlxwl2013 2013-12-13
- 打赏
- 举报
要有具体的例子就好。
加载更多回复（3）
