SQL 注入或 Server.HTMLEncode 或两者兼而有之？经典ASP
人们说要防止 SQL 注入，您可以执行以下操作之一（除其他外）：
- 准备语句（参数化）
- 存储过程
- 转义用户输入
我已经完成了第 1 项，准备我的语句，但我现在想知道是否应该转义以及所有用户输入。我已经准备好了声明，这看起来是浪费时间还是会让我预防的机会加倍？
People say to prevent SQL Injection, you can do one of the following (amongst other things):
- Prepare statements (parameterized)
- Stored procedures
- Escaping user input
I have done item 1, preparing my statements, but I'm now wondering if I should escape all user input as well. Is this a waste of time seeming as I have prepared statements or will this double my chances of prevention?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
除了使用参数化语句之外，转义输入通常是浪费时间。如果您使用的是数据库供应商提供的数据库“驱动程序”，并且您仅使用参数化
语句而不执行诸如 SQL 字符串连接之类的操作或尝试参数化实际 SQL 语法，而不仅仅是提供变量值，那么您就已经尽可能安全了。
总而言之，你最好的选择是相信数据库供应商知道如何在他们自己的 SQL 实现中转义值，而不是尝试滚动你自己的编码器，这对于很多数据库来说可能会比你做更多的工作思考。
如果除此之外您还需要额外的保护，您可以尝试使用 SQL 监控解决方案。有一些可用的工具可以发现异常的 SQL 查询并阻止/标记它们，或者只是尝试了解您的默认应用程序行为并阻止其他所有内容。显然，根据您的设置和用例，您的里程可能会有所不同。
It's usually a waste of time to escape your input on top of using parametrized statements. If you are using a database "driver" from the database vendor and you are only using parametrized
statements without doing things like SQL String concatenation or trying to parametrize the actual SQL syntax, instead of just providing variable values, then you are already as safe as you can be.
To sum it up, your best option is to trust the database vendor to know how to escape values inside their own SQL implementation instead of trying to roll your own encoder, which for a lot of DBs out there can be a lot more work then you think.
If on top of this you want additional protection you can try using a SQL Monitoring Solution. There are a few available that can spot out-of-the-ordinary SQL queries and block/flag them, or just try to learn your default app behavior and block everything else. Obviously your mileage may vary with these based on your setup and use-cases.
当然，防止 SQL 注入攻击的第一步是始终使用参数化查询，切勿将客户端提供的文本连接到 SQL 字符串中。一旦您采取了参数化步骤，存储过程的使用就无关紧要了。
然而，还有一个 SQL 注入的次要来源，其中 SQL 代码本身（通常在 SP 中）必须编写一些 SQL，然后执行这些 SQL。因此，即使您的 ASP 代码始终使用参数化查询，它仍然可能容易受到注入攻击。如果您可以确定您的 SQL 中没有一个也不会这样做，那么您就相当安全，不会受到 SQL 注入的影响。根据您正在执行的操作以及您使用的 SQL Server 版本，有时 SQL 组合 SQL 是不可避免的。
考虑到上述情况，稳健的方法可能需要您的代码检查传入字符串数据的 SQL 模式。这可能是一项相当繁重的工作，因为攻击者可以非常熟练地避免 SQL 模式检测。即使您认为您正在使用的 SQL 不易受到攻击，能够检测到此类尝试（即使它们失败）也是有用的。能够获取并记录有关携带该尝试的 HTTP 请求的附加信息是很好的。
转义是最可靠的方法，在这种情况下，尽管使用数据库中数据的所有代码都必须了解转义机制并能够对数据进行转义以利用它。例如，想象一下服务器端报告生成工具，在将数据库字段包含在报告中之前需要对数据库字段进行转义。
Server.HTMLEncode防止不同形式的注入。如果没有它，攻击者就可以将 HTML（包括 javascript）注入到您网站的输出中。例如，想象一个店面应用程序，允许客户评论产品以供其他客户阅读。恶意“客户”可能会注入一些 HTML，这可能使他们能够收集其他真实客户的信息，这些客户阅读了他们对流行产品的“评论”。因此，始终对从数据库检索的所有字符串数据使用
Server.HTMLEncode。Certainly the first step to prevent SQL Injection attacks is to always use parameterised queries, never concatenate client supplied text into a SQL string. The use of stored procedures is irrelevant once you have taken the step to parameterise.
However there is a secondary source of SQL injection where SQL code itself (usually in an SP) will have to compose some SQL which is then EXEC'd. Hence its still possible to be vunerable to injection even though your ASP code is always using parameterised queries. If you can be certain that none of your SQL does that and will never do that then you are fairly safe from SQL Injection. Depending on what you are doing and what version to SQL Server you are using there are occasions where SQL compositing SQL is unavoidable.
With the above in mind a robust approach may require that your code examines incoming string data for patterns of SQL. This can be fairly intense work because attackers can get quite sophisticated in avoiding SQL pattern detection. Even if you feel the SQL you are using is not vunerable it useful to be able to detect such attempts even if they fail. Being able to pick that up and record additional information about the HTTP requests carrying the attempt is good.
Escaping is the most robust approach, in that case though all the code that uses the data in you database must understand the escaping mechanim and be able to unescape the data to make use of it. Imagine a Server-side report generating tool for example, would need to unescape database fields before including them in reports.
Server.HTMLEncodeprevents a different form of Injection. Without it an attacker could inject HTML (include javascript) into the output of your site. For example, imagine a shop front application that allowed customers to review products for other customers to read. A malicious "customer" could inject some HTML that might allow them to gather information about other real customers who read their "review" of a popular product.Hence always use
Server.HTMLEncodeon all string data retrieved from a database.早在我必须做经典 ASP 的时候，我就使用了方法 2 和方法 3。我更喜欢存储过程的性能，它有助于防止 SQL 注入。我还使用了一组标准的包含来过滤（转义）用户输入。为了真正安全，不要使用经典的 ASP，但如果必须的话，我会同时使用这三个。
Back in the day when I had to do classic ASP, I used both methods 2 and 3. I liked the performance of stored procs better and it helps to prevent SQL injection. I also used a standard set of includes to filter(escape) user input. To be truly safe, don't use classic ASP, but if you have to, I would do all three.
首先，关于一般的注射：
后两者实际上与注射无关。
前者并不能涵盖所有可能的问题。
标识符。首先，我认为“转义”仅适用于字符串，而不适用于任何“用户输入”。转义所有其他类型是毫无用处的，并且不会保护任何内容。
接下来，说到字符串，您必须将它们全部转义，而不仅仅是来自用户输入。
最后 - 不，如果您使用准备好的语句，则不必使用任何转义
现在回答您的问题。
您可能会注意到，
HTMLEncode中不包含单词“SQL”。人们可能会认为Server.HTMLEncode与 SQL 注入完全无关。它更像是另一种攻击预防措施，称为 XSS。在这里，这似乎是一个更合适的操作，并且确实应该用于不受信任的用户输入。
因此，您可以将
Server.HTMLEncode与准备好的语句一起使用。但请记住，这是完全不同的攻击预防。您还可以考虑在实际 HTML 输出之前而不是在存储数据时使用 HTMLEncode。
First, on the injections in general:
Both latter 2 has nothing to do with injection actually.
And the former doesn't cover all the possible issues.
identifiers.First, I suppose, "escaping" is intended for the strings only, not whatever "user input". Escaping all other types is quite useless and will protect nothing.
Next, speaking of strings, you have to escape them all, not only coming from the user input.
Finally - no, you don't have to use whatever escaping if you are using prepared statements
Now to your question.
As you may notice,
HTMLEncodedoesn't contain a word "SQL" in it. One may persume then, thatServer.HTMLEncodehas absolutely nothing to do with SQL injections.It is more like another attack prevention, called XSS. Here it seems a more appropriate action and indeed should be used on the untrusted user input.
So, you may use
Server.HTMLEncodealong with prepared statements. But just remember that it's completely different attacks prevention.You may also consider to use HTMLEncode before actual HTML output, not at the time of storing data.