65.9K
CodeProject 正在变化。 阅读更多。
Home

SQL 注入攻击下的数据库安全测试

HARISHCHOWDHARY
starIconstarIconstarIconstarIcon
emptyStarIcon
starIcon

4.40/5 (9投票s)

2011 年 7 月 27 日

CPOL

6分钟阅读

viewsIcon

49047

本文解释了如何保护数据库免受 SQL 注入攻击。

引言

本文主要旨在为被测数据库应用程序提供清晰、简单、可操作的SQL注入漏洞防范指南。

“SQL注入”是未经验证/未经过滤的用户输入漏洞的一个子集，其原理是诱导应用程序执行非预期SQL代码，利用应用程序对非预期输入进行处理来构建和执行数据库中的SQL语句。

它提供了一套简单的技术来防范SQL注入漏洞。这些技术几乎可以用于任何类型的编程语言和任何类型的数据库，并且可以用来保护它们。在这里，我们将尝试阐明SQL注入攻击是什么，以及如何在您的公司中阻止它发生。在本文结束时，您将能够识别SQL注入攻击可能允许未经授权的个人渗透您的系统的场景，并学习如何修复现有代码以防止SQL注入攻击。

数据库是大多数Web应用程序的核心，它存储了网站和应用程序“生存”所需的数据。通过数据库和Web脚本语言的结合，我们作为开发者可以构建出能让客户满意、带来收益，并且最重要的是——能支撑我们业务运行的网站。

但是，当您意识到您的关键数据可能不安全时，会发生什么？当您意识到刚刚发现了一个新的安全漏洞时，会发生什么？数据库和编程语言中经常会发现安全漏洞和补丁，这些漏洞和补丁使得数据库容易受到攻击，任何未经授权的用户都可以通过SQL注入来攻击数据库，这可能会导致以下SQL注入的后果。

未经授权的用户可以以其他用户的身份（甚至是以管理员的身份）登录应用程序，并能够查看其他用户拥有的私人信息，例如：其他用户配置文件的详细信息、他们的交易详情等。恶意用户可以更改应用程序配置信息和其他用户的数据，修改数据库结构，甚至删除应用程序数据库中的表，并最终完全控制数据库服务器，随意执行其中的命令。

由于允许SQL注入技术可能导致严重的后果，因此在应用程序的安全测试中应该对其进行测试。现在，在对SQL注入技术有了大致了解之后，让我们来理解一些SQL注入的实际例子。

SQL注入问题应仅在测试环境中进行测试。

SQL注入是一种利用未经验证的输入漏洞，通过Web应用程序向后端数据库传递SQL命令进行执行的技术。攻击者利用程序员经常将SQL命令与用户提供的参数串联起来的事实，因此可以在这些参数中嵌入SQL命令。其结果是攻击者可以通过Web应用程序在后端数据库服务器上执行任意SQL查询和/或命令。SQL注入的严重性非常高，例如在2008年，包含数千名索尼用户信息的数据库被黑客入侵，索尼影业网站的一百万个密码、PlayStation Network的7700万个账户以及在线娱乐的近2500万用户账户被窃取。索尼因这些SQL注入攻击在以下国家/地区，在史上最大规模的数据泄露事件中位列第4位和第10位。

SONY BMG-GREECE
SONY MUSIC-JAPAN
SONY-CANADA
SONY PICTURES- FRANCE
SONY PICTURES- RUSSIA
SONY MUSIC- PORTUGAL

如果应用程序有一个登录页面，那么该应用程序可能使用了动态SQL，如以下语句。当SQL语句中存在与用户名和密码匹配的行时，此语句预计将至少返回一行包含用户详细信息的`Users`表作为结果集。

SELECT * FROM Users WHERE User_Name = ‘” & strUserName & _
	“‘ AND  Password = ‘” & strPassword & “’;”

如果测试人员在用户名“ textbox ”中输入 `John` 作为 `strUserName`，并在密码“ textbox ”中输入 `Smith` 作为 `strPassword`，则上述SQL语句将变成：

SELECT * FROM Users WHERE User_Name = ‘John’ AND Password = ‘Smith’;

如果测试人员在 `strUserName` 中输入 `John'`–，并且不输入 `strPassword`，则SQL语句将变成：

SELECT * FROM Users WHERE User_Name = ‘John’– AND Password = ‘Smith’;

请注意，SQL语句中`John`后面的部分被转换成了注释。如果`Users`表中存在用户名为`John`的用户，该应用程序可能会允许测试人员以用户`John`的身份登录。测试人员现在可以查看用户`John`的私人信息。

如果测试人员不知道应用程序中任何现有用户的姓名，该怎么办？在这种情况下，测试人员可以尝试诸如admin、administrator和sysadmin等常用用户名。如果这些用户都不存在于数据库中，测试人员可以输入 `John'` 或 `'x'='x` 作为 `strUserName`，并输入 `Smith'` 或 `'x'='x` 作为 `strPassword`。这将导致SQL语句变为如下所示：

SELECT * FROM Users WHERE User_Name = ‘John’ or _
	‘x’='x’ AND Password = ‘Smith’ or ‘x’=’x’;

由于`'x'='x'`条件始终为`true`，因此结果集将包含`Users`表中的所有行。该应用程序可能会允许测试人员以`Users`表中的第一个用户身份登录。

使用SSL的应用程序也可能存在SQL注入的风险。即使是防火墙也可能无法保护应用程序免受SQL注入技术的攻击。

有两种主要方法可以保护您的数据库免受SQL注入攻击。第一，确保应用程序通过阻止无效字符来验证用户输入。在许多情况下，只应接受字母数字字符。至少，应阻止单引号。第二，使用受保护的查询，这些查询绑定变量，而不是将SQL语句组合成“ string ”，例如存储过程。

这些建议也可能有帮助：

  1. 使用表的原始名称和列名，使名称更难猜测。
  2. 使用别名在数据和入侵者之间提供更多层的隔离。（例如，入侵者可能在深入挖掘后找到别名“ b ”。但“ b ”是“ book, ”的别名，并且执行正确的查询需要实际术语。）
  3. 对表单字段设置长度限制，并验证数据的长度和格式。
  4. 及时更新补丁。
  5. 使您的模式（schema）具有唯一性。
  6. 始终使用存储过程，它们使用参数。
  7. 避免使用查询字符串来构建Web页面。
  8. 使用 Post 和 Get 来处理HTML命令。
  9. 审计您的代码以暴露漏洞。
  10. 锁定您的服务器。
  11. 使用预编译语句（参数化查询）
  12. 转义所有用户提供的输入——每个DBMS都支持一种或多种特定于某些查询类型的字符转义方案。如果您使用您正在使用的数据库的适当转义方案来转义所有用户提供的输入，DBMS将不会将该输入与开发人员编写的SQL代码混淆，从而避免任何可能的SQL注入漏洞。

确保应用程序以完成任务所需的最低权限运行。删除任何不必要的帐户和任何不必要的信息，例如示例数据库和未使用的功能。还删除或禁用不必要的存储过程。

我们已经尝试以简单的方式解释了SQL注入技术。我们想重申，SQL注入应该只在测试环境中进行测试，而不能在开发环境、生产环境或任何其他环境中进行测试。与其手动测试应用程序是否易受SQL注入攻击，不如使用Web漏洞扫描器来检查SQL注入。

© . All rights reserved.