Background
Say I have the following webpage:
<html>
<script>
document.write('querystring=' + location.search.substr(1));
</script>
<html>
I open it at a URL like this:
http://pletely-secure-site/?<script>alert('fsecurity')</script>
In all browsers tried (Chrome 57, Firefox 52 and Safari 10) the result is:
querystring=%3Cscript%3Ealert(%27fsecurity%27)%3C/script%3E
Because angle brackets <> are not valid URL characters they seem to get automatically encoded by the browser on the way in, before they can get anywhere near the JS runtime.
My assumption
This leads me to believe that simply rendering the querystring directly on the client using document.write is always safe, and not a possible XSS vector. (I realize that there are many other ways in which an app can be vulnerable of course, but let's stick to the precise case described here.)
My question
Am I correct in this assumption?
- Is the inbound encoding of unsafe characters in the URL standardized / mandated across all reasonable browsers? (No possible XSS)
- Or, is this just a nicety / implementation detail of certain (modern?) clients on which I shouldn't rely globally? (XSS described above is theoretically possible)
Not relevant to the question, but an interesting aside. If I decode the URI first then browser behavior is different: document.write(decodeURI(location.search.substr(1)));. The XSS Auditor in both Chrome and Safari blocks the page, while Firefox shows the alert.
Background
Say I have the following webpage:
<html>
<script>
document.write('querystring=' + location.search.substr(1));
</script>
<html>
I open it at a URL like this:
http://pletely-secure-site/?<script>alert('fsecurity')</script>
In all browsers tried (Chrome 57, Firefox 52 and Safari 10) the result is:
querystring=%3Cscript%3Ealert(%27fsecurity%27)%3C/script%3E
Because angle brackets <> are not valid URL characters they seem to get automatically encoded by the browser on the way in, before they can get anywhere near the JS runtime.
My assumption
This leads me to believe that simply rendering the querystring directly on the client using document.write is always safe, and not a possible XSS vector. (I realize that there are many other ways in which an app can be vulnerable of course, but let's stick to the precise case described here.)
My question
Am I correct in this assumption?
- Is the inbound encoding of unsafe characters in the URL standardized / mandated across all reasonable browsers? (No possible XSS)
- Or, is this just a nicety / implementation detail of certain (modern?) clients on which I shouldn't rely globally? (XSS described above is theoretically possible)
Not relevant to the question, but an interesting aside. If I decode the URI first then browser behavior is different: document.write(decodeURI(location.search.substr(1)));. The XSS Auditor in both Chrome and Safari blocks the page, while Firefox shows the alert.
- 1 Just in case you didn't know, there's a security.stackexchange that has deep experts in this stuff on it. Very helpful folks there. – Iain Duncan Commented Apr 25, 2017 at 17:17
2 Answers
Reset to default 8 +50If I use Query String ?<script>alert("d")</script> on IE6 on Windows XP I get the injected code show the alert, this happens also using decodeURI or decodeURIComponent in the page, so I would say your second assumption is right if IE6 is still a reasonable browser: it is a feature of modern browsers
I also see Firefox 53 showing injected XSS alert when using the decode methods, Opera 44 & Chrome 57 (all on windows) block the code.
According to RFC 3986, section 2.4 inbound encoding of unsafe characters is standardized. Although I remend to not rely on that for two reasons:
- Not all browsers implement it
- There are so many browsers out in the wild which may do it another way accidentally or by intention.