问题
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:
http://localhost/http.mygarble.com/hello.txt?displayname=%22%3E%3Cscript%3Ealert%28123%29%3C%2Fscript%3E%22
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:
http://localhost/http.mygarble.com/hello.txt?displayname=%22%3E%3Cscript%3Ealert%28123%29%3C%2Fscript%3E%22
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
回答1:
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 .
回答2:
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.
回答3:
I've made some progress on this issue. Consider the following:
http://www.google.com/%22%%203E%3Cscript%3Ealert%28123%29%3C%2Fscript%3%20E%22
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...
http://www.google.com/?displayname=%22%3E%3Cscript%3Ealert%28123%29%3C%2Fscript%3E%22
...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
来源：https://stackoverflow.com/questions/6395856/why-do-firefox-and-certain-other-browsers-alter-the-url-in-the-address-bar-when