gpt4 book ai didi

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

转载 作者:技术小花猫 更新时间:2023-10-29 12:08:30 25 4
gpt4 key购买 nike

背景

假设我有以下网页:

<html>
<script>
document.write('querystring=' + location.search.substr(1));
</script>
<html>

我在这样的 URL 上打开它:

http://completely-secure-site/?<script>alert('fsecurity')</script>

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

querystring=%3Cscript%3Ealert(%27fsecurity%27)%3C/script%3E

因为尖括号 <>not valid URL characters它们似乎在进入 JS 运行时之前就被浏览器自动编码了。

我的假设

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

我的问题

我的假设是否正确?

  • URL 中不安全字符的入站编码是否在所有合理的浏览器中标准化/强制执行? (没有可能的 XSS)
  • 或者,这是否只是某些(现代?)客户端的细节/实现细节,我不应该在全局范围内依赖它们? (上述XSS理论上是可以的)

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

最佳答案

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

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

关于javascript - URL 上的 HTML &lt;script&gt; 片段是否可以用于纯客户端应用程序中的 XSS?,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/43436111/

25 4 0
Copyright 2021 - 2024 cfsdn All Rights Reserved 蜀ICP备2022000587号
广告合作:1813099741@qq.com 6ren.com