Sql server之sql注入篇_sql注入怎么弄

SQL Injection关于sql注入的危害在这里就不多做介绍了，相信大家也知道其中的厉害关系 防范sql注入的方法无非有以下几种：1.使用类型安全的SQL参数2.使用参数化输入存储过程3.使用参数集合与动态SQL。

4.输入滤波5.过滤LIKE条款的特殊字符...如果有遗漏的也欢迎大家指教Sample:var Shipcity; ; G8 N& r8 K( @8 h" Q+ l: z/ Z ShipCity = Request.form ("ShipCity");var sql = 。

"select * from OrdersTable where ShipCity = " + ShipCity + "";$ _* P$ A4 e6 y" J; s 上面是一个简单的sql注入示例用户将被提示输入一个市县名称如果用户输入 Redmond，则查询将由与下面内容相似的脚本组成：。

SELECT * FROM OrdersTable WHERE ShipCity = Redmond但是，假定用户输入以下内容：Redmond; drop table OrdersTable--此时，脚本将组成以下查询：

1 SELECT * FROM OrdersTable WHERE ShipCity = Redmond;droptable OrdersTable--分号 (;) 表示一个查询的结束和另一个查询的开始。

双连字符 (--) 指示当前行余下的部分是一个注释，应该忽略如果修改后的代码语法正确，则服务器将执行该代码SQL Server 处理该语句时，SQL Server 将首先选择 OrdersTable 中的所有记录（其中 ShipCity 为 Redmond）。

然后，SQL Server 将删除 OrdersTable只要注入的 SQL 代码语法正确，便无法采用编程方式来检测篡改因此，必须验证所有用户输入，并仔细检查在您所用的服务器中执行构造 SQL 命令的代码。

本主题中的以下各部分说明了编写代码的最佳做法①　200多本网络安全系列电子书②　网络安全标准题库资料③　项目源码④　网络安全基础入门、Linux、web安全、攻防方面的视频⑤　网络安全学习路线图 私信“安全”免费领取

下面就介绍一下常用的几种防止sql注入的方法：1. 验证所有输入始终通过测试类型、长度、格式和范围来验证用户输入实现对恶意输入的预防时，请注意应用程序的体系结构和部署方案请注意，设计为在安全环境中运行的程序可能会被复制到不安全的环境中。

以下建议应被视为最佳做法：对应用程序接收的数据不做任何有关大小、类型或内容的假设例如，您应该进行以下评估：如果一个用户在需要邮政编码的位置无意中或恶意地输入了一个 10 MB 的 MPEG 文件，应用程序会做出什么反应？。

如果在文本字段中嵌入了一个 DROP TABLE 语句，应用程序会做出什么反应？测试输入的大小和数据类型，强制执行适当的限制这有助于防止有意造成的缓冲区溢出测试字符串变量的内容，只接受所需的值拒绝包含二进制数据、转义序列和注释字符的输入内容。

这有助于防止脚本注入，防止某些缓冲区溢出攻击使用 XML 文档时，根据数据的架构对输入的所有数据进行验证绝不直接使用用户输入内容来生成 Transact-SQL 语句使用存储过程来验证用户输入在多层环境中，所有数据都应该在验证之后才允许进入可信区域。

未通过验证过程的数据应被拒绝，并向前一层返回一个错误实现多层验证对无目的的恶意用户采取的预防措施对坚定的攻击者可能无效更好的做法是在用户界面和所有跨信任边界的后续点上验证输入例如，在客户端应用程序中验证数据可以防止简单的脚本注入。

但是，如果下一层认为其输入已通过验证，则任何可以绕过客户端的恶意用户就可以不受限制地访问系统绝不串联未验证的用户输入字符串串联是脚本注入的主要输入点在可能据以构造文件名的字段中，不接受下列字符串：AUX、CLOCK$、COM1 到 COM8、CON、CONFIG$、LPT1 到 LPT8、NUL 以及 PRN。

如果可能，拒绝包含以下字符的输入。

注：验证输入是最被常用和联想到的，但是个人感觉这种方式不但代码显得肥胖，而且效率不是很好2.使用类型安全的 SQL 参数SQL Server 中的 Parameters 集合提供了类型检查和长度验证如果使用 。

Parameters 集合，则输入将被视为文字值而不是可执行代码使用 Parameters 集合的另一个好处是可以强制执行类型和长度检查范围以外的值将触发异常以下代码段显示了如何使用 Parameters。

集合：1 SqlDataAdapter myCommand = new SqlDataAdapter("AuthorLogin", conn);2 myCommand.SelectCommand.CommandType = CommandType.StoredProcedure;

3 SqlParameter parm = myCommand.SelectCommand.Parameters.Add("@au_id",4 SqlDbType.VarChar, 11);5

parm.Value = Login.Text; ' {9 F$ O+ D! Q4 ], w$ r" i 在此示例中，@au_id 参数被视为文字值而不是可执行代码将对此值进行类型和长度检查如果 @au_id 值不符合指定的类型和长度约束，则将引发异常存储过程如果使用未筛选的输入，则可能容易受 SQL Injection 攻击。

例如，以下代码容易受到攻击：SqlDataAdapter myCommand = new SqlDataAdapter("LoginStoredProcedure " + Login.Text + "", conn);

如果使用存储过程，则应使用参数作为存储过程的输入注：在鄙人现在的项目中，这种方法应用最为广泛3.在动态 SQL 中使用参数集合如果不能使用存储过程，您仍可使用参数，如以下代码示例所示：1 SqlDataAdapter myCommand = new SqlDataAdapter(2 "。

SELECT au\_lname, au\_fname FROMAuthorsWHERE au\_id = @au\_id", conn);3 SQLParameter parm = myCommand.SelectCommand.Parameters.Add("

@au_id",) k3 k4 c# W G( g4 f$ }* B4 j 4 SqlDbType.VarChar, 11);5 Parm.Value = Login.Text; ' f- q) @; @& O$ W0 @" y 注：和第二种雷同，这种方法是为了补充方法2存在，因为往往在很多时候业务简单不需要用proc的时候，可以用这种方法

4.筛选输入筛选输入可以删除转义符，这也可能有助于防止 SQL 注入但由于可引起问题的字符数量很大，因此这并不是一种可靠的防护方法以下示例可搜索字符串分隔符1privatestringSafeSqlLiteral。

(string inputSQL)2 {3return inputSQL.Replace("", "");4 } 7 A/ k! \2 f/ v/ i, c7 `1 c1 c 注：Filtering Input有种类似方法15.LIKE 子句请注意，如果要使用 LIKE 子句，还必须对通配符字符进行转义：

1 2 s = s.Replace("\[", "\[\[\]");3 s = s.Replace("%", "\[%\]");4 s = s.Replace("_", "\[_\]");6 F* s2 d" _ C9 v0 B0 ?9 V/ D% g 注：针对like子句，在使用时的效率这里就不多说了，总之要慎用了。

以上所有方法及其注释高亮显示部分，均为本人愚见，如果对方法有补充或者对高亮部分有不同意见的，欢迎大家给出意见，共同进步.本文是在借鉴MSDN的前提下加了一些自己的理解与意见， 转载请注入出处 thx.if您看了这篇博客。

对您有所帮助，请不要吝啬您的“推荐”，您的推荐将是我最大的动力有问题的话可以评论交流