SQL Server应用程序高级SQL注入(下)(7)

[审计]

SQL SERVER包含了丰富的允许记录数据库中的各种事件的审计接口，它包含在sp_traceXXX类的函数中。特别有意思的是能够记录所有SQL语句，然后在服务器上执行的T-SQL的事件。如果这种审计是被激活的，我们讨论的所有注入的SQL查询都将被记录在数据库中，一个熟练的数据库管理员将能够知道发生了什么事。不幸地，如果攻击者追加以下字符串：

Sp_password

到一个Transact-SQL语句中，这个审计机制记录日志如下：

--''sp_password'' was found in the text of this event. 
-- The text has been replaced with this comment for security reasons.

这种行为发生在所有的T-SQL日记记录中，即使''sp_password''发生在一个注释中。这个过程打算通过sp_password隐藏用户的密码，但这对于一个攻击者来说是非常有用的方法。因此，为了隐藏所有注入，攻击者需要简单地在''—''注释字符后追加sp_password，例如：

Username：admin''—sp_password事实上一些被执行的SQL将被记录，但是查询本身将顺利地从日志中消失。

[防范]

这部分讨论针对记述的攻击的一些防范。我们将讨论输入确认和提供一些简单的代码，然后我们将从事SQL SERVER锁定。

[输入验证]

输入验证是一个复杂的题目。比较有代表性的是，自从过于严密地确认倾向于引起部分应用程序的暂停，输入确认问题很难被解决，在项目开发中投入很少的注意力在输入确认上。输入确认不是倾向于将它加入到应用程序的功能当中，因此它一般会被忽视。

下面是一个含有简单代码的讨论输入确认的大纲。这个简单的代码不能直接用于应用程序中，但是它十分清晰地阐明了不同的策略。

不同的数据确认方法可以按以下分类：

1） 努力修改数据使它成为正确的；

2） 拒绝被认为是错误的输入；

3） 只接收被认为是正确的输入。

第一种情况有一些概念上的问题；首先，开发人员没必要知道那些是错误数据，因为新的错误数据的形式始终被发现。其次，修改数据会引起上面描述过的数据的长度问题。最后，二次使用的问题包括系统中已经存在数据的重新使用。

第二种情况也存在第一种情况中的问题；已知的错误输入随着攻击技术的发展变化。

第三种情况可能是三种中最好的，但是很难实现。