常见的Web应用安全漏洞与分析.docVIP

严重性: 高 类型: 应用程序级别测试 WASC 威胁分类: 命令执行类型：SQL 注入 CVE 引用: 不适用 安全风险: 可能会查看、修改或删除数据库条目和表 可能原因 未对用户输入正确执行危险字符清理 技术描述 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。这是应用程序的基本认证机制。但攻击者可以用下列方式来更改此查询： 攻击者可以提供单引号字符（）所组成的输入，使数据库发出错误消息，其中通常包含关于 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。 * 盲目 SQL 注入技术： 降低 SQL 注入攻击风险的一般方式，是禁止详细的 SQL 错误消息，攻击者通常便利用这些消息（如上述示例所说明），轻易找出容易遭受“SQL 注入”的脚本。 这个（以遮盖获取安全）解决方案可以利用称为“盲目 SQL 注入”的技术来略过，黑客不需要依赖返回 SQL 错误消息，便能找出容易遭受“SQL 注入”的脚本。 这项技术需要发送易受攻击的参数（被嵌入在 SQL 查询中的参数）已被修改的请求，将参数修改成，使响应指出是否在 S