为什么在 URI 中允许编码斜杠会带来安全风险？答案

【问题标题】：Why is it a security risk to allow encoded slashes in a URI?为什么在 URI 中允许编码斜杠会带来安全风险？
【发布时间】：2011-08-22 00:23:06
【问题描述】：

我有一种情况，我想在 URI (%2F) 中使用编码斜杠，但是当我发出请求时我的 .htaccess 规则被忽略，而是将我发送到 404 页面。我很快找到了 Apache 指令 AllowEncodedSlashes，我打算打开它，但我仍然不明白为什么它首先会带来安全风险。如果他们试图作恶，难道任何人都不能手动将编码的斜线转换为真正的斜线吗？（虽然我看不出它们能造成什么伤害……）

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

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

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

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

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

【问题讨论】：

标签： php apache mod-rewrite

【解决方案1】：

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

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

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

PoC 漏洞利用示例：

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

【讨论】：

我之所以使用_escaped_fragment_ $_GET 变量是因为它是一个符合Google's spec的Ajax应用程序
@JKS - 我明白了。但最后，我上面所说的仍然适用。使用echo '<pre>'.print_r($_SERVER,true).'</pre>'; 找出您应该解析的内容。
酷，我一定会调查的。我还对上面的安全问题添加了一些说明——特别是编码斜杠限制仅适用于路径（而不是查询字符串），但查询字符串也容易受到您上面列出的漏洞的影响。那么他们为什么要挑出这条路呢？
@JKS - 因为如果路径是可利用的，那么您将遇到严重的服务器问题 :D。
查询字符串也是如此。然而，编码斜线是允许的。还是我真的很顽固？尽管如此，还是感谢您的所有想法！

【解决方案2】：

如果需要转义，我认为在 URL 的任何地方都可以使用转义斜杠。例如，以下（相关）问题中引用的示例是一个非常合理的示例：

Is a slash ("/") equivalent to an encoded slash ("%2F") in the path portion of an HTTP URL

至于为什么它会被默认禁用……这篇 2003 年的博客文章表明它是为了“保护蹩脚的 CGI 脚本不受自身影响”：

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

某些粗心的做法可能会导致一些人发现自己的代码库中包含一个他们不确定是否要取消转义的字符串。因此，他们“只是为了安全”才摆脱它。但这可能发生在假设没有路径字符的点之后......并且它被传递到一些可执行的上下文中，该上下文认为它已经完成了所需的所有检查。

因此，如果您使用的是大多数现代 Web 框架的推荐方法，我怀疑这是一个重大问题，您可以毫无顾虑地使用 AllowEncodedSlashes。

【讨论】：