利用SqlCommand传参数的方法：
|
.NET防SQL注入方法 SQL语句 利用SqlCommand传参数的方法： 过滤禁止运行法： /// 存储过程 漏洞演示： 禁止后使用SQL 语句中就不能出现“exec, master, delete, truncate, declare, create, xp_”这些字符。 ::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::: Michael Sutton 最近发表了一篇非常发人深省的帖子，讲述在公共网上这问题是多么地普遍。他用Google的Search API建了一个C#的客户端程序，寻找那些易受SQL 注入攻击的网站。其步骤很简单： 寻找那些带查询字符串的网站(例如，查询那些在URL里带有 "id=" 的URL) 那么SQL注入攻击到底是什么玩意？ 有几种情形使得SQL注入攻击成为可能。最常见的原因是，你动态地构造了SQL语句，却没有使用正确地加了码(encoded)的参数。譬如，考虑这个SQL查询的编码，其目的是根据由查询字符串提供的社会保险号码(social security number)来查询作者(Authors)：
SSN = Request.QueryString("SSN") 如果你有象上面这个片断一样的SQL编码，那么你的整个数据库和应用可以远程地被黑掉。怎么会呢？在普通情形下，用户会使用一个社会保险号码来访问这个网站，编码是象这样执行的：
' SQL Query executed against the database 这是开发人员预期的做法，通过社会保险号码来查询数据库中作者的信息。但因为参数值没有被正确地加码，黑客可以很容易地修改查询字符串的值，在要执行的值后面嵌入附加的SQL语句 。譬如，
' SQL Query executed against the database 万一你认为匿名黑客删除你的数据库的结果很坏，但不幸的是，实际上，这在SQL注入攻击所涉及的情形中算是比较好的。一个黑客可以不单纯摧毁数据，而是使用上面这个编码的弱点，执行一个JOIN语句，来获取你数据库里的所有数据，显示在页面上，允许他们获取用户名，密码，信用卡号码等等。他们也可以添加 UPDATE/INSERT 语句改变产品的价格，添加新的管理员账号，真的搞砸你(screw up your life)呢。想象一下，到月底检查库存时，发现你库房里的实际产品数与你的帐目系统(accounting system)汇报的数目有所不同。。。 那该如何保护你自己？ SQL注入攻击是你需要担心的事情，不管你用什么web编程技术，再说所有的web框架都需要担心这个的。你需要遵循几条非常基本的规则： 1) 在构造动态SQL语句时，一定要使用类安全(type-safe)的参数加码机制。大多数的数据API，包括ADO和ADO.NET，有这样的支持，允许你指定所提供的参数的确切类型(譬如，字符串，整数，日期等)，可以保证这些参数被恰当地escaped/encoded了，来避免黑客利用它们。一定要从始到终地使用这些特性。 例如，在ADO.NET里对动态SQL，你可以象下面这样重写上述的语句，使之安全： Dim SSN as String = Request.QueryString("SSN") Dim cmd As new SqlCommand("SELECT au_lname, au_fname FROM authors WHERE au_id = @au_id") 一个常见的错误知觉(misperception)是，假如你使用了存储过程或ORM，你就完全不受SQL注入攻击之害了。这是不正确的，你还是需要确定在给存储过程传递数据时你很谨慎，或在用ORM来定制一个查询时，你的做法是安全的。 2) 在部署你的应用前，始终要做安全审评(security review)。建立一个正式的安全过程(formal security process)，在每次你做更新时，对所有的编码做审评。后面一点特别重要。很多次我听说开发队伍在正式上线(going live)前会做很详细的安全审评，然后在几周或几个月之后他们做一些很小的更新时，他们会跳过安全审评这关，推说，"就是一个小小的更新，我们以后再做编码审评好了"。请始终坚持做安全审评。 3) 千万别把敏感性数据在数据库里以明文存放。我个人的意见是，密码应该总是在单向(one-way )hashed过后再存放，我甚至不喜欢将它们在加密后存放。在默认设置下，ASP.NET 2.0 Membership API 自动为你这么做，还同时实现了安全的SALT 随机化行为(SALT randomization behavior)。如果你决定建立自己的成员数据库，我建议你查看一下我们在这里发表的我们自己的Membership provider的源码。同时也确定对你的数据库里的信用卡和其他的私有数据进行了加密。这样即使你的数据库被人入侵(compromised)了的话，起码你的客户的私有数据不会被人利用。 4) 确认你编写了自动化的单元测试，来特别校验你的数据访问层和应用程序不受SQL注入攻击。这么做是非常重要的，有助于捕捉住(catch)"就是一个小小的更新，所有不会有安全问题"的情形带来的疏忽，来提供额外的安全层以避免偶然地引进坏的安全缺陷到你的应用里去。 5) 锁定你的数据库的安全，只给访问数据库的web应用功能所需的最低的权限。如果web应用不需要访问某些表，那么确认它没有访问这些表的权限。如果web应用只需要只读的权限从你的account payables表来生成报表，那么确认你禁止它对此表的 insert/update/delete 的权限。 SQL注入式攻击 比如： 那么，如果我的用户名是：1 or 1=1 select * from admin where username=1 or 1=1 and password="&pwd&"" 这样你的查询语句就通过了，从而就可以进入你的管理界面。 所以防范的时候需要对用户的输入进行检查。特别式一些特殊字符，比如单引号，双引号，分号，逗号，冒号，连接号等进行转换或者过滤。 需要过滤的特殊字符及字符串有： net user : js版的防范SQL注入式攻击代码：
网友评论：
1 ztf704 -
2007年04月04日 13:18
-- 获得MS SQL的版本号
execute master..sp_msgetversion -- 得到硬盘文件信息 -- 参数说明:目录名,目录深度,是否显示文件 execute master..xp_dirtree c: execute master..xp_dirtree c:,1 execute master..xp_dirtree c:,1,1 -- 列出服务器上安装的所有OLEDB提供的程序 execute master..xp_enum_oledb_providers -- 列出服务器上安装的所有代码页 execute master..xp_enumcodepages -- 列出服务器上配置的dsn execute master..xp_enumdsn -- 列出sql server错误日志列表,最后更新时间 execute master..xp_enumerrorlogs -- 列出服务器上所有windows本地组 execute master..xp_enumgroups -- 检测文件存在性 execute master..xp_fileexist 'c:/a.bak' declare @flag int exec master..xp_fileexist 'c:/abc.bak',@flag out if @flag=1 begin print 'exist' end else begin print 'no exist' end -- 列出服务器上固定驱动器,以及每个驱动器的可用空间 execute master..xp_fixeddrives -- 得到当前sql server服务器的计算 你可能感兴趣的:(WEB,网络,sql,数据库,正则表达式,sql,server,string,sqlserver) |