sql注入攻击仅对具有表单的页面构成威胁吗？

Question

我知道这是一个简单的问题，但在我读过的所有内容中，我从未见过具体阐明的内容。

如果在页面上进行查询，是否需要担心SQL注入攻击？或者只是当您要求用户输入时才会出现问题？

谢谢！

Answer 1

您不必拥有用户输入即可遭受 SQL 注入攻击。

假设您有一个使用如下 URL 调用的产品页面：

product.aspx?ID=123

在您的代码中，您构建了如下查询：

string sql = "SELECT * FROM Products WHERE ID = " + Request.Querystring["ID"];

有人可以使用此 url 调用您的页面：

product.aspx?ID=123;DROP Table Students;

嘭，您已经被骗了。

除了可以通过用户、查询字符串、帖子、cookie、浏览器变量等传递的任何内容之外，我认为始终使用参数是一个很好的做法，即使您的代码中有文字。例如：

if(SomeCondition)
{
    sql = "Select * from myTable where someCol = 'foo'";
}
else
{
    sql = "Select * from myTable where someCol = 'bar'";
}

这可能是注入安全的，但您的 RDBMS 会将它们缓存为两个不同的查询。
如果您将其修改为：

sql = "Select * from myTable where someCol = @myParam";
if(SomeCondition)
{
   myCommand.Parameters.Add("@myParam").value = "foo";
}
else
{
   myCommand.Parameters.Add("@myParam").value = "bar";
}

您将获得相同的结果，但 RDBMS 只会将其缓存为一个查询，并在运行时替换参数。我将其用作始终使用参数化查询的经验法则，只是为了保持一致，更不用说稍微改进缓存了。

Answer 2

SQL注入是由未经净化的数据引起的。您应该始终清理进入数据库的数据。不仅可以用于 SQL 注入，还可以使您的应用程序正常运行。

例如，某些系统不会使用我的名字，因为其中包含 ' 字符，并且它们的数据库未经过清理。我没有输入我的名字，我的名字是从另一个数据库中获取的。没关系——数据应该被清理。

Answer 3

SQL 注入片段也可以来自通过 GET 方法传入的查询字符串（也称为“URL 参数”）。

正如 Billy O'Neal [单引号的意思;-)] 所暗示的，任何不是程序（或其非常值得信赖的后端）固有的数据都应该被“清理”。 消毒一词似乎暗示着一个复杂的过程，但实际上它通常意味着：
[可能因您的特定 SQL 服务器品牌而异]

• 从字符串中删除（或转义）字符串
• 监视中嵌入的单引号字符超出了基础 SQL 列的长度（特别是如果这样的长度很长）

这种想法的可能原因是HTTP 表单将成为 SQL 注入片段的唯一来源，因为一项有效的建议是确保仅从请求表单中获取用户提供的提交文本。一些 Web 应用程序框架将 HTTP 请求公开为一个对象，默认情况下，该对象公开来自 QueryString、表单甚至 cookie 的所有键值对，可通过单个哈希进行访问。虽然这对于有时从表单获取信息有时从查询字符串获取信息的应用程序来说很实用，但这可以促进潜在注入者的工作，因为制作 URL 比制作表单更容易。 （但是使用适当的工具，也可以伪造 POST 请求......）

Answer 4

不，还有其他几种情况。例如，您可能将一些变量作为查询字符串传递到 php 页面。 “用户”可以修改该字符串以包含一些狡猾的脚本。

http://en.wikipedia .org/wiki/SQL_injection 包含大量有关漏洞类型以及如何有效应对这些漏洞的章节。

Answer 5

总结一下 - SQL 查询中使用的任何类型的用户输入都是 SQL 注入的潜在目标

Answer 6

另请考虑防止跨站点脚本攻击 (" XSS”）。

Answer 7

如果您使用来自浏览器的任何类型的数据，则 SQL 注入是可能的。它可以是表单数据、查询字符串数据、cookie 值，甚至是请求标头中的数据。

最明显且简单的方法是表单数据和查询字符串数据，但来自浏览器的任何内容都可能被欺骗。

Answer 8

代码从 HTTP 请求中获取的任何内容都可以是 SQL 注入向量：

• POST/PUT 内容
• GET URL 参数
• Cookies

在更高级别上，这些显示为 $_REQUEST 或 Page.Request 值、会话变量，这一切都取决于无数的因素。但最终，不仅仅是 POST 表单。尽管最流行的向量可能是表单 POST 内容和 GET URL 变量。

Answer 9

当用户可以修改查询参数的值时，它就可能成为威胁。

Answer 10

在这种情况下，如果数据您在页面上显示的数据来自用户提交的数据。

转义输入，过滤输出

Answer 11

正如我所担心的，你永远不应该相信这些变量：$_POST、$_GET、$_REQUEST、$_COOKIE 甚至 $_SERVER 都可能包含恶意代码。因此，请务必确保插入的数据符合您的期望。
例如，作为验证电子邮件地址的额外偏执措施，您可以使用 md5 加密电子邮件地址，如下所示：

"SELECT username FROM users WHERE MD5(email)='" . md5($_POST['email']) . "' AND active=1"

Answer 12

作为一般规则，应始终使用参数化查询。

1. 它可以防止针对您的数据库执行恶意用户输入（SQL 注入攻击）。 [您还应该进行用户输入验证，以确保页面上不会呈现恶意代码，并且 JavaScript 可以针对您的服务器运行。]
2. 它使您能够重复使用查询。
3. 您可以预编译您的查询。
4. 它会组织您的输入并使其更具可读性。您可能希望在多个位置使用相同的参数。
5. 它对日期、字符串等不同数据类型有更好的支持。当您使用参数化查询时，您不会遇到奇怪字符的问题。

在我的用例中，我总是生成基于参数的查询。我有一个包装器，它总是会编译它们，这样如果在同一请求路径中执行第二个查询，它将在同一连接上运行得更快。这需要相当多的工作来设置，但在任何中型到企业级系统中的性能提升都是值得的。

Answer 13

我同意参数化是最好的方法。

作为替代方案（至少在最初可能更容易重新适应您的代码），在字符串中加倍单引号将防止 SQL 注入。

以 Neil N 的例子为例：

sql = "Select * From Products Where ID = " + Request.Querystring["ID"]; 

将变量包装在双引号的函数中，并用单引号包装变量。

sql = "Select * From Products Where ID = " 
    + fnSQLSafeParam(Request.Querystring["ID"]);

该函数类似于（VBscript 示例）：

Function fnSQLSafeParam(ByVal strStr)
  If IsNull(strStr) or IsEmpty(strStr) then strStr = ""
  fnSQLSafeParam = "'" & replace(Trim(CStr(strStr)), "'", "''") & "'"
End Function