0

假设我有一个 .NETHttpModule可以分析传入请求以检查可能的攻击，例如Sql Injection. 现在假设我的应用程序的用户在表单字段中输入以下内容并提交：

&#039&#032&#079&#082&#032&#049&#061&#049

那是 Unicode 的' OR 1=1。所以在请求中我得到类似的东西：

http://example.com/?q=%26%23039%26%23032%26%23079%26%23082%26%23032%26%23049%26%23061%26%23049

在我HttpModule看来这很好（没有 Sql 注入），但服务器会正​​确解码它q=' OR 1=1并且我的过滤器会失败。

所以，我的问题是：Is there any way to know at that point what is the encoding used by the request query string, so I can decode it and detect the attack?

我猜浏览器必须告诉服务器请求的编码是什么，这样才能正确解码。还是我错了？

4

2 回答 2

1

您看到的是 URL 编码，其中百分号后跟 2 个十六进制数字表示单个编码字节八位字节。在 HTML 中，以 & 符号开头并以分号结尾的实体包含实体名称或显式 Unicode 代码点值。

通过浏览器和服务器之间的线路发送的内容是http://example.com/?q=%26%23039%26%23032%26%23079%26%23082%26%23032%26%23049%26%23061%26%23049，但从逻辑上讲，它实际上表示http://example.com/?q=&#039&#032&#079&#082&#032&#049&#061&#049服务器在接收到它时解码时的内容。当您的代码读取查询字符串时，它应该正在接收&#039&#032&#079&#082&#032&#049&#061&#049. 服务器不应该进一步解码' OR 1=1，您必须在自己的代码中执行此操作。

如果您允许 URL 查询字符串按原样指定 SQL 查询过滤器，那么您一开始就是一个错误。这表明您正在动态构建 SQL 查询，而不是使用参数化 SQL 查询或存储过程，因此您将面临 SQL 注入攻击。你不应该使用它。参数化 SQL 查询和存储过程不会受到注入攻击，因此您的客户端应该只被允许提交 URL 中的单个参数值。然后，您的服务器代码可以从 URL 查询中提取各个值，并根据需要将它们传递给 SQL 参数。SQL 引擎将确保对值进行清理和格式化以避免攻击。您不应该手动处理。

于 2012-08-14T23:30:54.943 回答
1

服务器会将其正确解码为q=' OR 1=1

它不应该。&#039...在 SQL 查询中使用字符串之前，应用程序没有正当理由 (*) 对字符串进行 HTML 解码。HTML 解码是客户端事件。

(* 有一个无效的原因：应用程序作者对他们在做什么一无所知，试图编写一个输入 HTML 转义函数 - 首先是一个被误导的想法 - 由于无能而写了一个输入-de-escaping 函数......但这是不太可能的情况。希望。）

有什么方法可以知道请求查询字符串使用的编码是什么

不会。一些 Web 应用程序防火墙试图通过将他们能想到的每个解码方案应用于传入数据，并在其中任何一个匹配可疑的东西时触发，以防应用程序碰巧有一个该类型的任意解码器坐在在输入和易受攻击的系统之间。

这可能会导致性能下降以及误报率增加，对于尝试两个或多个解码器的所有可能组合的 WAF 来说更是如此。（例如，是T1IrMQbase-64 编码、URL 编码的OR 1SQL 攻击，还是只是车牌号？）

你在多大程度上采用这个想法是在你捕获多少潜在攻击和你对应用程序的真实用户产生多少负面影响之间进行权衡。没有一个“正确”的解决方案，因为最终您永远无法在应用程序外部的一层中提供针对应用程序漏洞的完整保护（又名“WAF 不起作用”）。

于 2012-08-15T23:24:32.533 回答