为什么在 URI 中允许编码斜杠存在安全风险? [英] Why is it a security risk to allow encoded slashes in a URI?

问题描述

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

I have a situation where I want encoded slashes in a URI (%2F), but my .htaccess rules are ignored when I make the request, sending me instead to a 404 page. I quickly found the Apache directive AllowEncodedSlashes, which I plan to turn on, but I still don't understand why it's a security risk in the first place. Couldn't anyone manually transform the encoded slashes to real slashes, if they were trying to be nefarious? (Although I can't see what harm they could do...)

我正在测试的应用程序是用 PHP 编写的，与其接口的 mod_rewrite 规则如下所示:

The application I'm testing is written in PHP, and the mod_rewrite rule that interfaces with it looks like:

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

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

I just want to make sure I understand the risks before proceeding.

澄清:Apache 不允许在 path 中使用编码斜杠，但它们在查询字符串中是允许的.查询字符串同样容易受到 Christian 下面列出的漏洞的影响(远程代码执行、本地文件访问和目录遍历").

To clarify: Apache does not allow encoded slashes in the path, but they are allowed in the query string. The query string is just as susceptible to the exploits listed by Christian below ("Remote Code Execution, Local File Access and Directory Traversal").

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

So why did the ASF go so far as to create a special directive just to allow this behavior? I'm not trying to be difficult, I just really don't understand. I think it goes without saying that any user input (including the URI) needs to be verified before using it in any database or file system function.

推荐答案

如果需要转义，我认为可以在 URL 中的任何位置使用转义斜杠.例如，以下(相关)问题中引用的示例非常合理:

I would think it is fine to use escaped slashes anywhere in a URL if escaping is warranted. For instance, the example cited in the following (relevant) question is a very reasonable one:

斜线(/")是否等同于 HTTP URL 路径部分中的编码斜线(%2F")

至于为什么默认情况下它会被禁用...这个 2003 年的博客条目表明它是为了保护蹩脚的 CGI 脚本不受其影响":

As for why it would be disabled by default...this blog entry from back in 2003 suggests it is to "protect lame CGI scripts from themselves":

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

某些粗心的做法可能会导致一些人发现自己在代码库中带有一个他们不确定是否要转义的字符串.所以他们只是为了安全"而逃避它.但这可能发生在假设没有路径字符的点之后......并且它被传递到一些认为它已经完成了它需要的所有检查的可执行上下文中.

Certain careless practices probably lead some people to find themselves in a codebase with a string they're unsure whether to unescape or not. So they unescape it "just to be safe". But this may occur after a point that assumed there were no path characters... and it gets passed on into some executable context that believed it had done all the checking it needed to.

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

So if you're using the recommended methods of most modern web frameworks, I doubt this is a significant issue and you can use AllowEncodedSlashes without much concern.

这篇关于为什么在 URI 中允许编码斜杠存在安全风险?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！