微软的LINQ to SQL技术为.net开发人员提供了一种机会，使其可以清除所开发的Web应用程序中SQL注入式安全漏洞的可能性。

随着对Web安全破坏的与日俱增，开发人员越来越深刻地认识到需要为其开发的应用程序的安全性承担更大的责任，而且应用程序框架的厂商们也将更坚实的安全特性构建到其应用软件中去。许多开发人员已经认识到构建安全应用程序和防止破坏性攻击的最有效的方法就是从一开始就要安全地设计和实施应用程序。不幸的是，开发团队往往缺乏训练和资源来做出关于应用程序安全的科学设计决策。

在开发人员承受越来越多的安全责任之时，许多开发人员了解到的第一个Web应用安全漏洞，是一个被称为“SQL注入”的极危险的命令注入形式。命令注入的原始的形式本是指这样一种漏洞：攻击者通过提供一个正常使用者意料之外的输入，改变你的Web应用程序的运行方式，从而允许攻击者运行服务器上的非授权的命令。无疑，SQL注入式攻击是很常见的、被广泛使用的攻击形式。幸运的是，一旦我们理解了这个问题，就可以很容易地防止SQL注入式攻击。更妙的是，现在微软的数据访问技术向.net开发人员提供了彻底地清除SQL注入漏洞的机会，当然前提是能够正确使用。这种技术称为“语言级集成查询”（Language Integrated Query (LINQ)），并随Visual Studio "Orcas" 和 .NET Framework 3.5一起发布。本文将讨论如何通过LINQ强化Web应用程序的数据访问代码，从而解决通过SQL注入进行攻击的问题。

概述

SQL注入是一种Web应用程序的安全漏洞，通过它攻击者可以将恶意数据提交给应用程序，欺骗应用程序在服务器上执行恶意的SQL命令。理论上讲，这种攻击是容易预防的，不过由于其允许攻击者直接运行针对用户关键数据的数据库命令，从而成为一种常见的、危害性大的攻击形式。在非常极端的情况下，攻击者不但能够自由地控制用户的数据，还可以删除数据表和数据库，甚至控制整个数据库服务器。

如果这种攻击容易预防，那么为什么还如此危险呢？首先，由于众所周知的经济上的原因，你的应用数据库是非常诱人的，可以引起攻击者的极大注意。如果SQL注入漏洞在Web应用程序中可能存在着，那么对于一个攻击者来说是很容易检测到的，然后就可以利用它。很显然，即使SQL注入错误并不是开发人员最经常犯的错误，它们也很容易被发现和利用。

检测SQL注入漏洞的一个简单方法是在一次输入中插入一个元字符(meta-character)，一个应用程序会用这个字符生成一个数据库访问语句。例如，在任何包含一个搜索输入栏的Web站点上，一个攻击者可以输入一个数据库元字符，例如一个核对符号（），然后单击“搜索”按钮提交输入。如果应用程序返回一个数据库错误消息，攻击者不但会知道他已经发现了一个应用程序的数据库驱动部分，而且他还能注入更加有意义的命令，让你的服务器执行它们。应用程序安全研究员Michael Sutton近来强调，发现那些易于受到SQL攻击的站点是很容易的。他说，使用Google搜索API这种方法只需几分钟就可以确定大量的潜在的易受攻击的站点。

对SQL注入的剖析

这里我们给出一个SQL注入的例子来说明两个问题，一是SQL注入这种错误是很容易犯的，二是只要进行严格的程序设计，这种错误是很容易预防的。

这个示例用的Web应用程序包含一个名为SQLInjection.aspx简单的客户搜索页面，这个页面易于受到SQL注入攻击。此页面包含一个CompanyName的输入服务器控件，还有一个数据表格控件，用于显示从微软的示例数据库Northwind的搜索结果（这个数据库可从SQL Server 2005中找到）。在搜索期间执行的这个查询包含一个应用程序设计中很普通的错误：它动态地从用户提供的输入中生成查询。这是Web应用程序数据访问中的一个主要的错误，因为这样实际上潜在地相信了用户输入，并直接将其发送给你的服务器。在从“搜索”的单击事件启动时，这个查询看起来是这个样子：

protected void btnSearch_Click(object sender, EventArgs e)

   {      String cmd = "SELECT [CustomerID], [CompanyName], [ContactName]

         FROM [Customers] WHERE CompanyName ='" + txtCompanyName.Text

         + "'";

         SqlDataSource1.SelectCommand = cmd;

         GridView1.Visible = true;

   }

在这种情况下，如果一个用户输入“Ernst Handel”作为公司名，并单击“搜索”按钮，作为响应屏幕会向用户显示那个公司的记录，这正是我们所期望的理想情况。不过一个攻击者可以轻易地操纵这个动态查询。例如，攻击者通过插入一个UNION子句，并用一个注释符号终止这个语句的剩余部分。换句话说，攻击者不是输入“Ernst Handel”，而是输入如下的内容：

Ernst Handel' UNION SELECT CustomerID, ShipName, ShipAddress 

   FROM ORDERS--

其结果是这个SQL语句在服务器端执行，由于添加了这个恶意的请求。它会将这个动态的SQL查询转换为下面的样子：

SELECT [CustomerID], [CompanyName], 

    [ContactName]

   FROM [Customers] 

   WHERE CompanyName ='Ernst Handel' 

   UNION SELECT CustomerID, ShipName, 

   ShipAddress 

   FROM ORDERS--'

这是一个相当合法的SQL语句，它可以在应用程序数据库上执行，返回order表中所有的客户，这些客户通过应用程序已经处理了定单。

典型的SQL防护

可以看出，在你的应用程序中创造并利用一个SQL注入漏洞是多么容易。幸运的是，如前所述，只需要采取几项简单的对策通常就可以预防SQL注入攻击。最常用的、成本效率最高的预防SQL注入攻击的方法是验证应用程序中所有的最终用于数据访问的数据输入。用户发出的任何输入，不管是通过Web应用程序输入的或者是常驻于数据存储设备的，都要在服务器处理你的数据访问命令之前在服务器端验证其类型、长度、格式和范围。不幸的是，基于代码的对策并不十分安全，而且有可能失败，特别是当发生如下情况时：

验证程序设计不当

验证仅在客户层面执行

在应用程序中，验证时遗漏了字段（有时即使是一个字段）。

防止SQL注入的另外一层涉及正确地确定应用程序中所有SQL查询的参数，不管是在动态SQL语句中还是在存储过程中。例如，如果代码像下面这样构建查询，就比较安全：

SELECT [CustomerID], [CompanyName], [ContactName]

   FROM [Customers] 

   WHERE CompanyName = @CompanyName

当作为SQL语句的一部分执行时，参数化查询将输入作为一个字面值，因此服务器就可能将带参数的输入作为可执行代码。即使你使用了存储过程，你仍然必须采取另外一步来确定输入的参数，因为存储过程并不对嵌入式查询中的SQL注入提供保护。

即使采取这上述的简单修正措施，SQL注入对许多公司来说仍然是一个大问题。对开发团队的挑战是要教育每一个开发人员谨慎对待这些类型的漏洞，采取有目的的和有效的安全标准来防止攻击，增强标准和操作安全的评估， 确认无任何疏漏。这样就会需要引入许多变量去保证应用程序安全，因此如果你选择一项能够使SQL注入式攻击成为不可能的数据访问技术，你的效率将会更高。这正是LINQ发挥作用之所在。

[1] [2] 下一页