URL上的HTML <script>片段是否可以用于纯客户端应用程序中的XSS?

Mik*_*ain 18 html javascript security xss http

背景

说我有以下网页:

<html>
  <script>
    document.write('querystring=' + location.search.substr(1));
  </script>
<html>
Run Code Online (Sandbox Code Playgroud)

我在这样的URL打开它:

http://completely-secure-site/?<script>alert('fsecurity')</script>
Run Code Online (Sandbox Code Playgroud)

在所有尝试的浏览器(Chrome 57,Firefox 52和Safari 10)中,结果是:

查询字符串=%3Cscript%3Ealert(%27fsecurity%27)%3C /脚本%3E

因为尖括号<>无效的URL字符,他们似乎得到自动的方式浏览器中编码,才可以拿到附近的JS运行时的任何地方.

我的假设

这让我相信简单地在客户端上直接渲染查询字符串document.write总是安全的,而不是可能的XSS向量.(我意识到当然还有许多其他方式可以让应用程序容易受到攻击,但让我们坚持这里描述的精确案例.)

我的问题

我在这个假设中是否正确?

  • 在所有合理的浏览器中标准化/强制规定的URL中的不安全字符的入站编码是什么?(没有可能的XSS)
  • 或者,这只是我不应该全球依赖的某些(现代?)客户的精确/实施细节?(上面描述的XSS理论上是可行的)

与问题无关,但有趣的是一边.如果我首先解码URI,那么浏览器的行为是不同的:document.write(decodeURI(location.search.substr(1)));.Chrome和Safari中的XSS Auditor会阻止该页面,而Firefox会显示警报.

Tes*_*ini 8

如果我?<script>alert("d")</script>在Windows XP上的IE6上使用查询字符串我得到注入的代码显示警报,这也发生在页面上decodeURIdecodeURIComponent在页面中,所以我想说你的第二个假设是正确的,如果IE6仍然是一个合理的浏览器:它是一个功能现代浏览器

我还看到Firefox 53在使用解码方法时显示注入XSS警报,Opera 44和Chrome 57(全部在Windows上)阻止代码.