SQL注入或Server.HTMLEncode或两者兼而有之？经典ASP

Question

人们说为防止SQL注入，您可以执行以下操作之一（其中包括）：

1. 准备陈述（参数化）
2. 存储过程
3. 转发用户输入

我已完成第1项，准备我的陈述，但我现在想知道是否应该逃避所有用户输入。这是浪费时间，因为我准备好了陈述，还是这会增加我预防的机会？

Answer 1

在使用参数化语句的基础上，通常是浪费时间来逃避输入。如果您正在使用数据库＆＃34; driver＆＃34;来自数据库供应商，您只使用参数化  如果语句不执行SQL字符串连接或尝试参数化实际的SQL语法，而不是仅仅提供变量值，那么您已经尽可能安全了。

总而言之，您最好的选择是相信数据库供应商知道如何在他们自己的SQL实现中转义值，而不是尝试滚动自己的编码器，这对于很多数据库来说可能会有很多你想的就是工作。

如果您需要额外的保护，可以尝试使用SQL监控解决方案。有一些可以发现异常的SQL查询并阻止/标记它们，或者只是尝试了解您的默认应用程序行为并阻止其他所有内容。显然，根据您的设置和使用情况，您的里程可能会有所不同。

Answer 2

在我不得不做经典ASP的那天，我使用了方法2和3.我更喜欢存储过程的性能，它有助于防止SQL注入。我还使用了一组标准包来过滤（转义）用户输入。为了真正安全，不要使用经典ASP，但如果必须，我会做三个。

Answer 3

当然，防止SQL注入攻击的第一步是始终使用参数化查询，永远不要将客户端提供的文本连接到SQL字符串中。一旦您采取了参数化步骤，就无法使用存储过程。

然而，SQL注入的第二个来源是SQL代码本身（通常在SP中）必须编写一些SQL，然后执行EXEC。因此，即使你的ASP代码总是使用参数化查询，它仍然可以被注入。如果你可以确定你的SQL没有那么做而且永远不会那么那么你就可以安全地使用SQL注入。根据您正在执行的操作以及您使用的SQL Server版本，有时SQL合成SQL是不可避免的。

考虑到上述情况，强大的方法可能要求您的代码检查传入的字符串数据以查找SQL模式。这可能是相当紧张的工作，因为攻击者可以非常复杂地避免SQL模式检测。即使您觉得您使用的SQL不可用，但即使它们失败也能够检测到这些尝试。能够选择并记录有关携带尝试的HTTP请求的其他信息是好的。

转义是最强大的方法，在这种情况下，虽然所有使用数据库中的数据的代码必须理解转义的mechanim并且能够使用它来取消数据。例如，想象一下服务器端报表生成工具，需要在将数据库字段包含在报表中之前对其进行转换。

Server.HTMLEncode可以阻止不同形式的注射。没有它，攻击者可以将HTML（包括javascript）注入您网站的输出。例如，假设一个店面应用程序允许客户查看产品供其他客户阅读。恶意“客户”可能会注入一些HTML，这些HTML可能会让他们收集有关阅读其热门产品“评论”的其他真实客户的信息。

因此总是对从数据库中检索到的所有字符串数据使用Server.HTMLEncode。

Answer 4

首先，关于一般的注射：

后者2实际上与注射无关 而前者并未涵盖所有可能的问题。

1. 准备好的陈述是可以的，除非您必须处理identifiers。
2. 存储的证据也容易受到注射。它根本不是一个选择。
3. “逃避”“用户输入”是最有趣的。

首先，我想，“转义”仅适用于字符串，而不是“用户输入”。逃避所有其他类型是没用的，并且不会保护任何东西 接下来，谈到字符串，您必须将它们全部转义，而不仅仅是来自用户输入 最后 - 不，如果你使用准备好的陈述，你不必使用任何逃避

现在回答你的问题。

您可能会注意到，HTMLEncode中不包含单词“SQL”。有人可能会说， Server.HTMLEncode与SQL注入完全无关。

它更像是另一种名为XSS的攻击防范。这似乎是一个更合适的操作，实际上应该用于不受信任的用户输入。

因此，您可以将Server.HTMLEncode与预准备语句一起使用。但请记住，这是完全不同的攻击预防。

您也可以考虑在实际HTML输出之前使用HTMLEncode，而不是在存储数据时使用。