当我输入这样的网址时，使用..
http://SERVER:8085/../tn/d9dd6c39d71276487ae798d976f8f629_tn.jpg
我在没有.. - 部分
Firefox是否会以静默方式将其删除？ URL中不允许使用..
P.S。：wget删除..也： - （
答案 0 :(得分：2)
＆＃34; ..＆＃34;表示相对路径，用于在层次结构中向上移动。所以＆＃34; ..＆＃34;不是文件夹的有效名称，因此您不能在URL中间使用它。这没有任何意义。
所以回答你的问题：＆＃34; ..＆＃34;在网址中允许但仅在开头。
答案 1 :(得分：1)
我最近开始看到这种情况，尽管给出了明确的答案，但将其添加到URL中确实是有道理的，并且在IT安全领域中是有效的文件夹路径，我们通常会绕过配置错误的站点中的安全措施，分类为目录遍历攻击。
Web（浏览器，wget，curl等）工具以静默方式评估URL路径并去除“ /../”，这使我寻找漏洞的工作更加困难。为了解决这个问题，我将Firefox和Burpsuite结合使用，Burpsuite是一种代理评估工具，可以捕获请求并允许我在发送至服务器之前对其进行修改。
这样做，我可以输入：
https://example.com/vpn/../vpns/cfg/etc
在我的浏览器URL中，当我使用Burpsuite捕获它时，它看起来像：
https://example.com/vpns/cfg/etc
向我显示Firefox实际上已经更改了我原来的预期URL字符串。因此，在Burpsuite中，我将请求修改为：
GET /vpn/../vpns/cfg/etc HTTP/1.1
将其发送到服务器，瞧，路径保持不变并导航到正确的位置。是的，在具有适当请求处理的正常配置的应用程序中，不必这样做。这个特定的字符串在这两种格式中的行为有所不同，因此必须进行修改，以使服务器以我们希望显示的方式来处理它，以表明应用程序如何处理请求存在配置问题（目录遍历漏洞）。
这也可以通过卷曲来证明。如果您发送如下所示的正常curl命令，curl将与Firefox相同并评估路径，并在发送到服务器之前从其中删除“ / vpn /..”：
curl -i -s -k "https://example.com/vpn/../vpns/cfg/etc"
但是，如果添加“ --path-as-is”参数，curl将不会修改它并按原样发送它，并且“ / vpn / ..”保持不变：
curl -i -s -k "https://example.com/vpn/../vpns/cfg/etc" --path-as-is
经过更多阅读后，我发现此行为部分归因于URI规范化标准（https://en.wikipedia.org/wiki/URI_normalization）。
这指向RFC 3986，用于定义URI语法https://tools.ietf.org/html/rfc3986#section-5.2.4。
答案 2 :(得分：0)
补充资料：
＆＃34; ../&# 34;也将被开发人员工具剥离（至少达到54.0.1），这意味着您无法使用＆＃34;编辑并重新发送＆＃34;手工制作这样的有效请求：
IO#read(Bytes)...这可能会导致目录遍历并检索文件。