为什么在 URI 中允许编码斜杠存在安全风险？

php apache mod-rewrite

2022-08-30 19:19:06

我有一种情况，我想要在URI中编码斜杠（），但是当我发出请求时，我的规则被忽略，而是将我发送到404页面。我很快就找到了Apache指令RecordEdSlashes，我计划打开它，但我仍然不明白为什么它首先是一个安全风险。难道没有人能手动将编码的斜杠转换为真正的斜杠，如果他们试图成为邪恶的？（虽然我看不出他们能造成什么伤害...）%2F.htaccess

我正在测试的应用程序是用PHP编写的，与它交互的mod_rewrite规则如下所示：

RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule ^test/(.*)$ /test.php?_escaped_fragment_=$1 [NE,QSA,L]

在继续之前，我只想确保我了解风险。

澄清一下：Apache不允许在路径中使用编码斜杠，但在查询字符串中允许使用斜杠。查询字符串同样容易受到 Christian 在下面列出的漏洞利用（“远程代码执行、本地文件访问和目录遍历”）。）。

那么，为什么ASF甚至创建了一个特殊指令来允许这种行为呢？我不是想变得困难，我只是真的不明白。我认为不言而喻，在任何数据库或文件系统功能中使用任何用户输入（包括URI）都需要经过验证。

答案 1

我认为如果有必要进行转义，则可以在URL中的任何位置使用转义斜杠。例如，以下（相关）问题中引用的示例是一个非常合理的示例：

是 HTTP URL 的路径部分中的斜杠（“/”）是否等效于编码斜杠（“%2F”）

至于为什么默认情况下会禁用它...这篇2003年的博客文章表明，这是为了“保护蹩脚的CGI脚本免受自身侵害”：

http://ken.coar.org/burrow/Apache_2f_encoding_decoding_and_security

某些粗心大意的做法可能会导致一些人发现自己在代码库中，他们不确定是否要取消解释。因此，他们“只是为了安全起见”而忽略了它。但这可能发生在假设没有路径字符的点之后......它被传递到一些可执行的上下文中，这些上下文认为它已经完成了所需的所有检查。

因此，如果您使用的是大多数现代Web框架的推荐方法，我怀疑这是一个重大问题，您可以使用RecordEncodedSlashes而不必担心。

答案 2

老实说，我没有看到任何安全问题，但我必须承认我在这个领域工作得不多。也就是说，规则仍然不正确。

您应该重定向到解析而不是通过的处理程序文件（php 脚本）。这主要是为了避免您通常遇到的非编码内容问题。$_SERVER['REQUEST_URI']$_GET

另一方面，您可能正在运行 Web 应用防火墙，其中包含禁止通过 URI 传递斜杠的规则。这是因为此行为通常与远程执行代码、本地文件访问和目录遍历相关联。然而，这是一种预防措施，你首先不应该依赖它。

PoC 漏洞示例：

include 'languages/'.$_GET['lang']; // hacker may pass ../ to move around.