为什么 FireFox 和某些其他浏览器在服务器响应时会更改地址栏中的 URL
由于以下问题，我本季度难以满足 PCI-DSS 合规性。
当您在浏览器中输入以下内容时...
http://www.mygarble.com/main/Community/Chat?command=CHAT_MESSAGE&displayname=%22%3E%3Cscript%3Ealert%28123%29%3C%2Fscript%3E%22
...它会做出响应，因此，由于某种我无法确定的原因，浏览器地址栏中的 URL 更改为以下内容：
http://www.mygarble.com/main/Community/Chat?command=CHAT_MESSAGE&displayname="><script>alert(123)<%2Fscript>"
您可以看到某些原始 URL 中的转义字符已被未转义字符替换。
我给出的原因是，当服务器响应时，无论服务器如何响应，FireFox 都会自动重新格式化地址栏中的 URL，以使其更具可读性。我告诉他们我对此无能为力。然而，公平地说，他们反驳说，如果您尝试以下 URL...
http://www.google.com/%22%%203E%3Cscript%3Ealert%28123%29%3C%2Fscript%3%20E%22
...当 Google 服务器响应时，浏览器不会更改 URL 并且保持不变：
http://www.google.com/%22%%203E%3Cscript%3Ealert%28123%29%3C%2Fscript%3%20E%22
而且他们有道理。
那么到底发生了什么？我已经缩小了问题范围，如果我只请求一个空文本文件，但在它后面附加一些无意义的查询...
http://localhost/http.mygarble.com/hello.txt?displayname=%22%3E%3Cscript%3Ealert%28123%29%3C%2Fscript%3E%22
...瞧，当我的本地服务器响应时它会被重写：
我'我已经通过 Fiddler 运行了这个，没有看到任何异常，并且我已经关闭了重写引擎。我正在运行阿帕奇。
更令人困惑的是，不同的浏览器的响应也不同。 输入...
http://localhost/http.mygarble.com/hello.txt?displayname=%22%3E%3Cscript%3Ealert%28123%29%3C%2Fscript%3E%22
在 Chrome 中
进入 IE ，URL 保持完全相同。在 Opera 中，除非您单击地址栏，否则查询字符串将被删除，这证实了我的信念：浏览器会根据响应自动更改地址栏中的 URL，以使它们更具可读性。 Safari 与 IE 一样，单独保留 URL。
我现在要检查谷歌的回应以寻找线索。是否有一些 HTTP 指令指示浏览器不要干扰响应中的 URL。
非常感谢任何帮助！
亲切的问候，
詹姆斯
I'm having difficulty meeting PCI-DSS compliance this quarter because of the following problem.
When you type the following into a browser...
http://www.mygarble.com/main/Community/Chat?command=CHAT_MESSAGE&displayname=%22%3E%3Cscript%3Ealert%28123%29%3C%2Fscript%3E%22
...it responds and, as a consequence, for some reason that I cannot ascertain, the URL in the browswer address bar is changed to the following:
http://www.mygarble.com/main/Community/Chat?command=CHAT_MESSAGE&displayname="><script>alert(123)<%2Fscript>"
You can see that some of the escaped characters in the original URL have been replaced by unescaped ones.
The reason I gave for this is that FireFox automatically reformats the URL in the address bar when the server responds, no matter how it responds, in order to make it more readable. I told them there was nothing I could do about it. However, in fairness, they countered that if you try the following URL...
http://www.google.com/%22%%203E%3Cscript%3Ealert%28123%29%3C%2Fscript%3%20E%22
...when the Google servers respond, the browser does not change the URL and it remains the same:
http://www.google.com/%22%%203E%3Cscript%3Ealert%28123%29%3C%2Fscript%3%20E%22
And they have a point.
So what on earth is going on? I've narrowed down the problem and if I do no more than request an empty text file, but append some nonsense query after it...
http://localhost/http.mygarble.com/hello.txt?displayname=%22%3E%3Cscript%3Ealert%28123%29%3C%2Fscript%3E%22
...lo and behold it gets rewritten when my local server responds:
I've run this through Fiddler and can see nothing untoward, and I've turned off the rewrite engine. I'm running Apache.
To add to the confusion, different browsers respond differently. Typing...
http://localhost/http.mygarble.com/hello.txt?displayname=%22%3E%3Cscript%3Ealert%28123%29%3C%2Fscript%3E%22
...into Chrome yields:
Into IE, the URL stays exactly the same. In Opera, the query string is dropped unless you click on the address bar, lending credence to my belief that browsers automatically change URLs in address bars on response in order to make them more readable. Safari, like IE, leaves the URL alone.
I'm going to check Google's response now for clues. Is there some HTTP directive that instructs the browser not to meddle with the URL on response.
Any help very gratefully appreciated!
Kind regards,
James
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
google URL 栏结果不会更改，因为 URL 编码序列无效（“%3”不是有效的编码序列 - 应该有两个十六进制数字）。如果您将第一个链接中的相同 URI 部分附加到 google 域，则：
http://www.google.com/%22%3E%3Cscript%3Ealert%28123%29%3C%2Fscript%3E%22
它也会在地址栏中替换为未转义的字符（在 Firefox 4.0.1、Mac OS X Snow Leopard、荷兰）
有关转义和不转义的一些有趣的讨论，请参见例如。 https://bugzilla.mozilla.org/show_bug.cgi?id=425480 。
The google URL bar result doesn't change because the URL encoding sequence isn't valid ("%3" is not a valid encoding sequence - there should be two hex digits). If you append the same URI part from your first link to the google domain, thus:
http://www.google.com/%22%3E%3Cscript%3Ealert%28123%29%3C%2Fscript%3E%22
It also gets replaced in the address bar with the unescaped characters (on Firefox 4.0.1, Mac OS X Snow Leopard, the Netherlands)
For some interesting discussion about what to escape and what not to escape, see eg. https://bugzilla.mozilla.org/show_bug.cgi?id=425480 .
在我发现 Firefox 地址栏中的字符只是解码显示但并未真正改变之前，我设置了一个测试来找出发生了什么。
这导致了这个演示：'神奇的 Firefox 地址栏解码器' 演示（并列出）了哪些字符在地址栏中显示解码以及通过脚本从地址栏读取的内容。在不同的浏览器中运行该页面会显示差异。
Firefox 变化最大，Chrome 只变化几个字符，IE 和 Safari 没有变化任何内容。 Firefox 解码的字符选择似乎与encodeUriComponent 编码的字符选择无关。希望这可以帮助任何人。
Before I found out that the characters were only displayed decoded but not really changed, in the address bar by Firefox, I set up a test to find out what happened.
This lead to this demo: 'The magic Firefox address bar decoder' that demonstrates (and lists) which characters are displayed decoded in the address bar and what is read from the address bar by script. Running the page in different browsers shows the differences.
Firefox changes the most, Chrome changes only a few characters, IE and Safari don't change anything. The choice of characters that are decoded by Firefox seems unrelated to the selection of characters that are encoded by encodeUriComponent. Hope this might help anyone.
我在这个问题上取得了一些进展。请考虑以下情况：
在这种情况下，浏览器保持 URL 不变的原因是服务器返回 HTTP 404 响应，表示找不到资源。在这些情况下，Firefox 不会更改 URL。如果您尝试使用一个提示来自 Google 的 200 OK 响应的 URL，如下所示...
...您会发现，当服务器以更改的 URL 响应时，FireFox 会更改该 URL。
自己尝试一下。事实上，如果您将更改后的 URL 剪切并粘贴到电子邮件中，您会发现字符保持不变。
除了 HTTP 响应代码之外，这与服务器实际响应的内容无关。如果服务器响应“404 未找到”，FireFox 将选择保持地址栏中的 URL 不变。如果服务器响应“200 OK”，FireFox 将选择更改 URL，取消转义某些字符，可能是为了使 URL 更具可读性。如果找不到资源，逻辑是我认为这样做是没有意义的。
我假设您使用的是 Firefox。事实上，浏览器对这种情况的处理方式有所不同。我尝试在多个浏览器中输入此 URL（第二个）。我总结了结果：
Google Chrome 与 Firefox 相同。引号和尖括号显示为普通字符，未转义。
Internet Explorer 保持 URL 不变，但显示有关 XSS 的消息警告，并且不显示 Google 页面。
Opera 在地址栏中仅显示“www.google.com”。
Safari 保持 URL 不变。
我希望这能解决问题。为了让自己相信这一切，你可以做的一件事就是运行一个 HTTP 调试代理，比如 Fiddler。您可以看到，在每种情况下，服务器返回的内容都是相同的，这只是每个浏览器在服务器响应时选择如何更改 URL 的问题。
亲切的问候，
詹姆斯
I've made some progress on this issue. Consider the following:
The reason the browser leaves the URL unchanged in this case is that the server returns a HTTP 404 response, signifying that the resource cannot be found. In these cases, Firefox makes no change to the URL. If you instead try a URL that prompts a 200 OK response from Google, such as the following...
...you will find that FireFox will change the URL when the server responds with a changed URL.
Try it yourself. In fact if you cut and paste the changed URL into an email, you'll find that the characters remain unchanged.
This has nothing to do with what the server actaully responds with, apart from the HTTP reponse code. If the server responds with '404 Not found', FireFox elects to leave the URL in the address bar unchanged. If the server responds with '200 OK', FireFox elects to alter the URL, unescaping some of the characters presumably in an attempt to make the URL more readable. If the resource cannot be found, the logic is I guess that there's no point in doing this.
I'm assuming you're using Firefox. In fact, browsers treat this case differently. I've tried typing this URL (the second one) into several browsers. I've summarised the results:
Google Chrome Does the same as Firefox. Quotes and angle braces are displayed as normal characters, unescaped.
Internet Explorer Leaves the URL unchanged, but presents a message warning about XSS and does not diplay the Google page.
Opera Shows just 'www.google.com' in the address bar.
Safari Leaves the URL unchanged.
I hope this clears things up. One thing you can do to convince yourself of all of this is to run an HTTP debugging proxy like Fiddler. You can see that in each case what the server returns is identical, it is simply a matter of how each browser chooses to alter the URL when the server responds.
Kind regards,
James