Sql server之sql注入篇

SQL Injection

关于sql注入的危害在这里就很少作介绍了，相信你们也知道其中的厉害关系。这里有一些sql注入的事件你们感兴趣能够看一下

 

防范sql注入的方法无非有如下几种：

1.使用类型安全的SQL参数
2.使用参数化输入存储过程
3.使用参数集合与动态SQL
4.输入滤波
5.过滤LIKE条款的特殊字符

...若是有遗漏的也欢迎园子的大大们指教。

Sample:

var Shipcity;
ShipCity = Request.form ("ShipCity");
var sql = "select * from OrdersTable where ShipCity = '" + ShipCity + "'";

上面是一个简单的sql注入示例

用户将被提示输入一个市县名称。若是用户输入 Redmond，则查询将由与下面内容类似的脚本组成：

SELECT * FROM OrdersTable WHERE ShipCity = 'Redmond'

可是，假定用户输入如下内容：

Redmond'; drop table OrdersTable--

此时，脚本将组成如下查询：

1 SELECT * FROM OrdersTable WHERE ShipCity = 'Redmond';drop table OrdersTable--'

 

分号 (;) 表示一个查询的结束和另外一个查询的开始。双连字符 (--) 指示当前行余下的部分是一个注释，应该忽略。若是修改后的代码语法正确，则服务器将执行该代码。SQL Server 处理该语句时，SQL Server 将首先选择 OrdersTable 中的全部记录（其中 ShipCity 为 Redmond）。而后，SQL Server 将删除 OrdersTable。

只要注入的 SQL 代码语法正确，便没法采用编程方式来检测篡改。所以，必须验证全部用户输入，并仔细检查在您所用的服务器中执行构造 SQL 命令的代码。本主题中的如下各部分说明了编写代码的最佳作法。

下面就介绍一下经常使用的几种防止sql注入的方法：

 

1. 验证全部输入

 

始终经过测试类型、长度、格式和范围来验证用户输入。实现对恶意输入的预防时，请注意应用程序的体系结构和部署方案。请注意，设计为在安全环境中运行的程序可能会被复制到不安全的环境中。如下建议应被视为最佳作法：

• 对应用程序接收的数据不作任何有关大小、类型或内容的假设。例如，您应该进行如下评估：

  • 若是一个用户在须要邮政编码的位置无心中或恶意地输入了一个 10 MB 的 MPEG 文件，应用程序会作出什么反应？

  • 若是在文本字段中嵌入了一个 DROP TABLE 语句，应用程序会作出什么反应？

• 测试输入的大小和数据类型，强制执行适当的限制。这有助于防止有意形成的缓冲区溢出。

• 测试字符串变量的内容，只接受所需的值。拒绝包含二进制数据、转义序列和注释字符的输入内容。这有助于防止脚本注入，防止某些缓冲区溢出攻击。

• 使用 XML 文档时，根据数据的架构对输入的全部数据进行验证。

• 毫不直接使用用户输入内容来生成 Transact-SQL 语句。

• 使用存储过程来验证用户输入。

• 在多层环境中，全部数据都应该在验证以后才容许进入可信区域。未经过验证过程的数据应被拒绝，并向前一层返回一个错误。

• 实现多层验证。对无目的的恶意用户采起的预防措施对坚决的攻击者可能无效。更好的作法是在用户界面和全部跨信任边界的后续点上验证输入。

  例如，在客户端应用程序中验证数据能够防止简单的脚本注入。可是，若是下一层认为其输入已经过验证，则任何能够绕过客户端的恶意用户就能够不受限制地访问系统。

• 毫不串联未验证的用户输入。字符串串联是脚本注入的主要输入点。

• 在可能据以构造文件名的字段中，不接受下列字符串：AUX、CLOCK$、COM1 到 COM八、CON、CONFIG$、LPT1 到 LPT八、NUL 以及 PRN。

若是可能，拒绝包含如下字符的输入。

 

输入字符	在 Transact-SQL 中的含义
;	查询分隔符。
'	字符数据字符串分隔符。
--	注释分隔符。
/* ... */	注释分隔符。服务器不对 /* 和 */ 之间的注释进行处理。
xp_	用于目录扩展存储过程的名称的开头，如 xp_cmdshell。

 

注：验证输入是最被经常使用和联想到的，可是我的感受这种方式不但代码显得肥胖，并且效率不是很好

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;

在此示例中，@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 FROM Authors WHERE au_id = @au_id", conn);
3 SQLParameter parm = myCommand.SelectCommand.Parameters.Add("@au_id", 
4                         SqlDbType.VarChar, 11);
5 Parm.Value = Login.Text;

注：和第二种雷同，这种方法是为了补充方法2存在，由于每每在不少时候业务简单不须要用proc的时候，能够用这种方法

4.筛选输入

筛选输入能够删除转义符，这也可能有助于防止 SQL 注入。但因为可引发问题的字符数量很大，所以这并非一种可靠的防御方法。如下示例可搜索字符串分隔符。

 

1 private string SafeSqlLiteral(string inputSQL)
2 {
3   return inputSQL.Replace("'", "''");
4 }

 

注：Filtering Input有种相似方法1

5.LIKE 子句

请注意，若是要使用 LIKE 子句，还必须对通配符字符进行转义：

 

1  
2 s = s.Replace("[", "[[]");
3 s = s.Replace("%", "[%]");
4 s = s.Replace("_", "[_]");

注：针对like子句，在使用时的效率这里就很少说了，总之要慎用了。

 

 

以上全部方法及其注释高亮显示部分，均为本人愚见，若是对方法有补充或者对高亮部分有不一样意见的，欢迎你们给出意见，共同进步.

本文是在借鉴MSDN的前提下加了一些本身的理解与意见， 转载请注入出处。 thx.

 

if您看了这篇博客。对您有所帮助，请不要吝啬您的“推荐”，您的推荐将是我最大的动力。有问题的话能够评论交流。