SQL 注入

 

• 1 什么是SQL 注入

SQL Injection：就是通过把SQL命令插入到Web表单递交或输入域名或页面请求的查询字符串，最终达到欺骗服务器执行恶意的SQL命令。

具体来说，它是利用现有应用程序，将（恶意）的SQL命令注入到后台数据库引擎执行的能力，它可以通过在Web表单中输入（恶意）SQL语句得到一个存在安全漏洞的网站上的数据库，而不是按照设计者意图去执行SQL语句。

根据相关技术原理，SQL注入可以分为平台层注入和代码层注入。前者由不安全的数据库配置或数据库平台的漏洞所致；后者主要是由于程序员对输入未进行细致地过滤，从而执行了非法的数据查询。基于此，SQL注入的产生原因通常表现在以下几方面：①不当的类型处理；②不安全的数据库配置；③不合理的查询集处理；④不当的错误处理；⑤转义字符处理不合适；⑥多个提交处理不当。

• 1.1 攻击

当应用程序使用输入内容来构造动态sql语句以访问数据库时，会发生sql注入攻击。如果代码使用存储过程，而这些存储过程作为包含未筛选的用户输入的字符串来传递，也会发生sql注入。sql注入可能导致攻击者使用应用程序登陆在数据库中执行命令。相关的SQL注入可以通过测试工具pangolin进行。如果应用程序使用特权过高的帐户连接到数据库，这种问题会变得很严重。在某些表单中，用户输入的内容直接用来构造动态sql命令，或者作为存储过程的输入参数，这些表单特别容易受到sql注入的攻击。而许多网站程序在编写时，没有对用户输入的合法性进行判断或者程序中本身的变量处理不当，使应用程序存在安全隐患。这样，用户就可以提交一段数据库查询的代码，根据程序返回的结果，获得一些敏感的信息或者控制整个服务器，于是sql注入就发生了。

• 1.2.SQL注入例子

下面通过一个例子说明什么时候可能发生SQL Injection。

假设我们在浏览器中输入URL www.sample.com，由于它只是对页面的简单请求无需对数据库动进行动态请求，所以它不存在SQL Injection，当我们输入www.sample.com?testid=23时，我们在URL中传递变量testid，并且提供值为23，由于它是对数据库进行动态查询的请求（其中?testid＝23表示数据库查询变量），所以我们可以该URL中嵌入恶意SQL语句。

现在我们知道SQL Injection适用场合，接下来我们将通过具体的例子来说明SQL Injection的应用，这里我们以pubs数据库作为例子。

我们通过Web页面查询job表中的招聘信息，job表的设计如下：

图1 jobs表

接着让我们实现Web程序，它根据工作Id（job_id）来查询相应的招聘信息，示意代码如下：

/// <summary>/// Handles the Load event of the Page control./// </summary>/// <param name="sender">The source of the event.</param>/// <param name="e">The <see cref="System.EventArgs"/> instance containing the event data.</param>protected void Page_Load(object sender, EventArgs e){    if (!IsPostBack)    {        // Gets departmentId from http request.        string queryString = Request.QueryString["departmentID"];        if (!string.IsNullOrEmpty(queryString))        {            // Gets data from database.            gdvData.DataSource = GetData(queryString.Trim());            // Binds data to gridview.            gdvData.DataBind();        }    }}

现在我们已经完成了Web程序，接下来让我们查询相应招聘信息吧。

图2 job表查询结果

如图所示，我们要查询数据库中工作Id值为1的工作信息，而且在页面显示了该工作的Id，Description，Min Lvl和Max Lvl等信息。

现在要求我们实现根据工作Id查询相应工作信息的功能，想必大家很快可以给出解决方案，SQL示意代码如下：

SELECT     job_id, job_desc, min_lvl, max_lvl  FROM      jobs WHERE     (job_id = 1)

假设现在要求我们获取Department表中的所有数据，而且必须保留WHERE语句，那我们只要确保WHERE恒真就OK了，SQL示意代码如下：

SELECT     job_id, job_desc, min_lvl, max_lvl  FROM         jobs WHERE     (job_id = 1) OR 1 = 1

上面我们使得WHERE恒真，所以该查询中WHERE已经不起作用了，其查询结果等同于以下SQL语句。

SELECT     job_id, job_desc, min_lvl, max_lvl  FROM      jobs

SQL查询代码实现如下：

string sql1 = string.Format(    "SELECT job_id, job_desc, min_lvl, max_lvl FROM jobs WHERE job_id='{0}'", jobId);

现在我们要通过页面请求的方式，让数据库执行我们的SQL语句，我们要在URL中嵌入恶意表达式1=1（或2=2等等），如下URL所示：

http://localhost:3452/ExcelUsingXSLT/Default.aspx?jobid=1'or'1'='1

等效SQL语句如下：

SELECT     job_id, job_desc, min_lvl, max_lvl  FROM     jobs WHERE     job_id = '1' OR '1' = 1'

图3 job表查询结果

现在我们把job表中的所有数据都查询出来了，仅仅通过一个简单的恒真表达式就可以进行了一次简单的攻击。

虽然我们把job表的数据都查询出来了，但数据并没有太大的价值，由于我们把该表临时命名为job表，所以接着我们要找出该表真正表名。

首先我们假设表名就是job，然后输入以下URL：

http://localhost:3452/ExcelUsingXSLT/Default.aspx?jobid=1'or 1=(select count(*) from job)--

等效SQL语句如下：

SELECT       job_id, job_desc, min_lvl, max_lvl FROM         jobs WHERE      job_id='1'or 1=(select count(*) from job) --'

图4 job表查询结果

当我们输入了以上URL后，结果服务器返回我们错误信息，这证明了我们的假设是错误的，那我们该感觉到挫败吗？不，其实这里返回了很多信息，首先它证明了该表名不是job，而且它还告诉我们后台数据库是SQL Server，不是MySQL或Oracle，这也设计一个漏洞把错误信息直接返回给了用户。

假定表名是jobs，然后输入以下URL：

http://localhost:3452/ExcelUsingXSLT/Default.aspx?jobid=1'or1=(select count(*) from jobs) --

等效SQL语句如下：

SELECT       job_id, job_desc, min_lvl, max_lvl FROM         jobs WHERE      job_id='1'or 1=(select count(*) from jobs) --'

图5 job表查询结果

现在证明了该表名是jobs，这可以迈向成功的一大步，由于我们知道了表名就可以对该表进行增删改操作了，而且我们还可以猜测出更多的表对它们作出修改，一旦修改成功那么这将是一场灾难。

现在大家已经对SQL Injection的攻击有了初步的了解了，接下让我们学习如何防止SQL Injection。

• 1.3 SQL注入技术

强制产生错误

对数据库类型、版本等信息进行识别是此类型攻击的动机所在。它的目的是收集数据库的类型、结构等信息为其他类型的攻击做准备，可谓是攻击的一个预备步骤。利用应用程序服务器返回的默认错误信息而取得漏洞信息。

采用非主流通道技术

除HTTP响应外，能通过通道获取数据，然而，通道大都依赖与数据库支持的功能而存在，所以这项技术不完全适用于所有的数据库平台。SQL注入的非主流通道主要有E-mail、DNS以及数据库连接，基本思想为：先对SQL查询打包，然后借助非主流通道将信息反馈至攻击者。

使用特殊的字符

不同的SQL数据库有许多不同是特殊字符和变量，通过某些配置不安全或过滤不细致的应用系统能够取得某些有用的信息，从而对进一步攻击提供方向。

使用条件语句

此方式具体可分为基于内容、基于时间、基于错误三种形式。一般在经过常规访问后加上条件语句，根据信息反馈来判定被攻击的目标。

利用存储过程

通过某些标准存储过程，数据库厂商对数据库的功能进行扩展的同时，系统也可与进行交互。部分存储过程可以让用户自行定义。通过其他类型的攻击收集到数据库的类型、结构等信息后，便能够建构执行存储过程的命令。这种攻击类型往往能达到远程命令执行、特权扩张、拒绝服务的目的。

避开输入过滤技术

虽然对于通常的编码都可利用某些过滤技术进行SQL注入防范，但是鉴于此种情况下也有许多方法避开过滤，一般可达到此目的的技术手段包括SQL注释和动态查询的使用，利用截断，URL编码与空字节的使用，大小写变种的使用以及嵌套剥离后的表达式等等。借助于此些手段，输入构思后的查询可以避开输入过滤，从而攻击者能获得想要的查询结果。

推断技术

能够明确数据库模式、提取数据以及识别可注入参数。此种方式的攻击通过网站对用户输入的反馈信息，对可注入参数、数据库模式推断，这种攻击构造的查询执行后获得的答案只有真、假两种。基于推断的注入方式主要分为时间测定注入与盲注入两种。前者是在注入语句里加入语句诸如“waitfor 100”，按照此查询结果出现的时间对注入能否成功和数据值范围的推导进行判定；后者主要是“and l=l”、“and l=2”两种经典注入方法。这些方式均是对一些间接关联且能取得回应的问题进行提问，进而通过响应信息推断出想要信息，然后进行攻击。

• 1.4 SQL注入防范

归纳一下，主要有以下几点：

(1) 输入验证

    永远不要信任用户的输入，要对用户的输入进行校验，可以通过正则表达式，或限制长度，对单引号和双"-"进行转换等。  检查用户输入的合法性，确信输入的内容只包含合法的数据。数据检查应当在客户端和服务器端都执行之所以要执行服务器端验证，是为了弥补客户端验证机制脆弱的安全性。

     在客户端，攻击者完全有可能获得网页的源代码，修改验证合法性的脚本（或者直接删除脚本），然后将非法内容通过修改后的表单提交给服务器。因此，要保证验证操作确实已经执行，唯一的办法就是在服务器端也执行验证。你可以使用许多内建的验证对象，例如Regular Expression Validator，它们能够自动生成验证用的客户端脚本，当然你也可以插入服务器端的方法调用。如果找不到现成的验证对象，你可以通过Custom Validator自己创建一个。

(2) 使用参数化的过滤性语句

    永远不要使用动态拼装SQL，可以使用参数化的SQL或者直接使用存储过程进行数据查询存取。 要防御SQL注入，用户的输入就绝对不能直接被嵌入到SQL语句中。恰恰相反，用户的输入必须进行过滤，或者使用参数化的语句。参数化的语句使用参数而不是将用户输入嵌入到语句中。在多数情况中，SQL语句就得以修正。然后，用户输入就被限于一个参数。

 

(3) 确保数据库安全

    锁定你的数据库的安全，永远不要使用管理员权限的数据库连接，为每个应用使用单独的权限有限的数据库连接。只给访问数据库的web应用功能所需的最低的权限，撤销不必要的公共许可，使用强大的加密技术来保护敏感数据并维护审查跟踪。如果web应用不需要访问某些表，那么确认它没有访问这些表的权限。如果web应用只需要只读的权限，那么就禁止它对此表的 drop 、insert、update、delete 的权限，并确保数据库打了最新补丁。

(4)加密处理

     将用户登录名称、密码等数据加密保存。加密用户输入的数据，然后再将它与数据库中保存的数据比较，这相当于对用户输入的数据进行了“消毒”处理，用户输入的数据不再对数据库有任何特殊的意义，从而也就防止了攻击者注入SQL命令。
存储过程来执行所有的查询

     SQL参数的传递方式将防止攻击者利用单引号和连字符实施攻击。此外，它还使得数据库权限可以限制到只允许特定的存储过程执行，所有的用户输入必须遵从被调用的存储过程的安全上下文，这样就很难再发生注入式攻击了。
使用专业的漏洞扫描工具

     攻击者们目前正在自动搜索攻击目标并实施攻击，其技术甚至可以轻易地被应用于其它的Web架构中的漏洞。企业应当投资于一些专业的漏洞扫描工具，如大名鼎鼎的Acunetix的Web漏洞扫描程序等。一个完善的漏洞扫描程序不同于网络扫描程序，它专门查找网站上的SQL注入式漏洞。最新的漏洞扫描程序可以查找最新发现的漏洞。

 

(5)错误消息处理

      防范SQL注入，还要避免出现一些详细的错误消息，因为黑客们可以利用这些消息。要使用一种标准的输入确认机制来验证所有的输入数据的长度、类型、语句、企业规则等。应用的异常信息应该给出尽可能少的提示，最好使用自定义的错误信息对原始错误信息进行包装，把异常信息存放在独立的表中。

(6)SQL注入检测

    sql注入的检测方法一般采取辅助软件或网站平台来检测，软件一般采用sql注入检测工具jsky，网站平台就有亿思网站安全平台检测工具。MDCSOFT SCAN等。采用MDCSOFT-IPS可以有效的防御SQL注入，XSS攻击等。

(7) 安全审评
     在部署应用系统前，始终要做安全审评。建立一个正式的安全过程，并且每次做更新时，要对所有的编码做审评。开发队伍在正式上线前会做很详细的安全审评，然后在几周或几个月之后他们做一些很小的更新时，他们会跳过安全审评这关，"就是一个小小的更新，我们以后再做编码审评好了”。请始终坚持做安全审评。

• 2 通过正则表达校验用户输入

首先我们可以通过正则表达式校验用户输入数据中是包含：对单引号和双"-"进行转换等字符。

然后继续校验输入数据中是否包含SQL语句的保留字，如：WHERE，EXEC，DROP等。

现在让我们编写正则表达式来校验用户的输入吧，正则表达式定义如下：

private static readonly Regex RegSystemThreats =        new Regex(@"\s?or\s*|\s?;\s?|\s?drop\s|\s?grant\s|^'|\s?--|\s?union\s|\s?delete\s|\s?truncate\s|" +            @"\s?sysobjects\s?|\s?xp_.*?|\s?syslogins\s?|\s?sysremote\s?|\s?sysusers\s?|\s?sysxlogins\s?|\s?sysdatabases\s?|\s?aspnet_.*?|\s?exec\s?",            RegexOptions.Compiled | RegexOptions.IgnoreCase);

上面我们定义了一个正则表达式对象RegSystemThreats，并且给它传递了校验用户输入的正则表达式。

由于我们已经完成了对用户输入校验的正则表达式了，接下来就是通过该正则表达式来校验用户输入是否合法了，由于.NET已经帮我们实现了判断字符串是否匹配正则表达式的方法——IsMatch()，所以我们这里只需给传递要匹配的字符串就OK了。

示意代码如下：

/// <summary>/// A helper method to attempt to discover [known] SqlInjection attacks.  /// </summary>/// <param name="whereClause">string of the whereClause to check</param>/// <returns>true if found, false if not found </returns>public static bool DetectSqlInjection(string whereClause){    return RegSystemThreats.IsMatch(whereClause);}/// <summary>/// A helper method to attempt to discover [known] SqlInjection attacks.  /// </summary>/// <param name="whereClause">string of the whereClause to check</param>/// <param name="orderBy">string of the orderBy clause to check</param>/// <returns>true if found, false if not found </returns>public static bool DetectSqlInjection(string whereClause, string orderBy){    return RegSystemThreats.IsMatch(whereClause) || RegSystemThreats.IsMatch(orderBy);}

现在我们完成了校验用的正则表达式，接下来让我们需要在页面中添加校验功能。

/// <summary>/// Handles the Load event of the Page control./// </summary>/// <param name="sender">The source of the event.</param>/// <param name="e">The <see cref="System.EventArgs"/> instance containing the event data.</param>protected void Page_Load(object sender, EventArgs e){    if (!IsPostBack)    {        // Gets departmentId from http request.        string queryString = Request.QueryString["jobId"];        if (!string.IsNullOrEmpty(queryString))        {            if (!DetectSqlInjection(queryString) && !DetectSqlInjection(queryString, queryString))            {                // Gets data from database.                gdvData.DataSource = GetData(queryString.Trim());                // Binds data to gridview.                gdvData.DataBind();            }            else            {                throw new Exception("Please enter correct field");            }        }    }}

当我们再次执行以下URL时，被嵌入的恶意语句被校验出来了，从而在一定程度上防止了SQL Injection。

http://localhost:3452/ExcelUsingXSLT/Default.aspx?jobid=1'or'1'='1

图6 添加校验查询结果

但使用正则表达式只能防范一些常见或已知SQL Injection方式，而且每当发现有新的攻击方式时，都要对正则表达式进行修改，这可是吃力不讨好的工作。

• 3 通过参数化存储过程进行数据查询存取

首先我们定义一个存储过程根据jobId来查找jobs表中的数据。

-- =============================================-- Author:        JKhuang-- Create date: 12/31/2011-- Description:    Get data from jobs table by specified jobId.-- =============================================ALTER PROCEDURE [dbo].[GetJobs]    -- ensure that the id type is int    @jobId INTASBEGIN--    SET NOCOUNT ON;    SELECT job_id, job_desc, min_lvl, max_lvl    FROM dbo.jobs    WHERE job_id = @jobId    GRANT EXECUTE ON GetJobs TO pubs END

接着修改我们的Web程序使用参数化的存储过程进行数据查询。

using (var com = new SqlCommand("GetJobs", con)){    // Uses store procedure.    com.CommandType = CommandType.StoredProcedure;    // Pass jobId to store procedure.    com.Parameters.Add("@jobId", SqlDbType.Int).Value = jobId;    com.Connection.Open();    gdvData.DataSource = com.ExecuteScalar();    gdvData.DataBind(); }

现在我们通过参数化存储过程进行数据库查询，这里我们把之前添加的正则表达式校验注释掉。

图7 存储过程查询结果

大家看到当我们试图在URL中嵌入恶意的SQL语句时，参数化存储过程已经帮我们校验出传递给数据库的变量不是整形，而且使用存储过程的好处是我们还可以很方便地控制用户权限，我们可以给用户分配只读或可读写权限。

但我们想想真的有必要每个数据库操作都定义成存储过程吗？而且那么多的存储过程也不利于日常的维护。

• 4 参数化SQL语句(绑定变量)

还是回到之前动态拼接SQL基础上，我们知道一旦有恶意SQL代码传递过来，而且被拼接到SQL语句中就会被数据库执行，那么我们是否可以在拼接之前进行判断呢？——命名SQL参数。

string sql1 = string.Format("SELECT job_id, job_desc, min_lvl, max_lvl FROM jobs WHERE job_id = @jobId");using (var con = new SqlConnection(ConfigurationManager.ConnectionStrings["SQLCONN1"].ToString()))using (var com = new SqlCommand(sql1, con)){    // Pass jobId to sql statement.    com.Parameters.Add("@jobId", SqlDbType.Int).Value = jobId;    com.Connection.Open();    gdvData.DataSource = com.ExecuteReader();    gdvData.DataBind(); }

图8 参数化SQL查询结果

这样我们就可以避免每个数据库操作（尤其一些简单数据库操作）都编写存储过程了，而且当用户具有数据库中jobs表的读权限才可以执行该SQL语句。

• 5 添加新schema

数据库schema是一个独立于数据库用户的非重复命名空间，您可以将架构视为对象的容器（类似于.NET中的命名空间）。

首先我们右击schema文件夹，然后新建schema。

图9 添加HumanResource架构

上面我们完成了在pubs数据库中添加HumanResource schema，接着把jobs表放到HumanResource schema中。

图 10 修改jobs表所属的架构

当我们再次执行以下SQL语句时，SQL Server提示jobs无效，这是究竟什么原因呢？之前还运行的好好的。

SELECT job_id, job_desc, min_lvl, max_lvl FROM jobs

图 11 查询输出

当我们输入完整的表名“schema名.对象名”（HumanResource.jobs）时，SQL语句执行成功。

SELECT job_id, job_desc, min_lvl, max_lvl FROM HumanResource.jobs

为什么之前我们执行SQL语句时不用输入完整表名dbo.jobs也可以执行呢？

这是因为默认的schema（default schema）是dbo，当只输入表名时，Sql Server会自动加上当前登录用户的默认的schema（default schema）——dbo。

由于我们使用自定义schema，这也降低了数据库表名被猜测出来的可能性。

• 6 LINQ to SQL

前面使用了存储过程和参数化查询，这两种方法都是非常常用的，而针对于.NET Framework的ORM框架也有很多，如：NHibernate,NIbatis，Castle和Entity Framework，这里我们使用比较简单LINQ to SQL。

图 12 添加jobs.dbml文件

var dc = new pubsDataContext();int result;// Validates jobId is int or not.if (int.TryParse(jobId, out result)){    gdvData.DataSource = dc.jobs.Where(p => p.job_id == result);    gdvData.DataBind();}

相比存储过程和参数化查询，LINQ to SQL我们只需添加jobs.dbml，然后使用LINQ对表进行查询就OK了。

• 7 总结

我们在本文中介绍了SQL Injection的基本原理，通过介绍什么是SQL Injection，怎样进行SQL Injection和如何防范SQL Injection。通过一些程序源码对SQL的攻击进行了细致的分析，使我们对SQL Injection机理有了一个深入的认识，作为一名Web应用开发人员，一定不要盲目相信用户的输入，而要对用户输入的数据进行严格的校验处理，否则的话，SQL Injection将会不期而至。