全部是known容易受到XSS？JavaScript framekiller和XSS漏洞
如果是的话，是不是应该在清除iframe之前清理window.location？
最好的办法是做什么？
您能举一个可能的XSS攻击的例子吗？
谢谢！
UPD：我问的原因是因为我有一个漏洞扫描警告说，JS包含top.location.replace(document.location) framekiller代码XSS脆弱的document.location由用户控制。
什么是对在它们的描述：如 'document.location'， 'window.location的'， 'self.location' 被（部分地）由非可信用户控制的变量。这是因为在非信任域和页面位置（'http：// non.trusted.domain .com/mypage'）和不可信请求字符串（'http：/' /my.domain.com/？myrequest'）是根据用户的意愿形成的，可能并不总是对你有好处。
出了什么问题：此用户依赖项不一定是XSS漏洞。实际上，为了形成XSS，您需要使用一些代码，这些代码可以有效地使用由输出流中不受信任用户控制的内容作为页面。在像top.location.replace(window.location)这样的简单框架示例中，没有XSS的危险。
一个例子，我们可以谈论XSS会是这样的代码
document.write('<a href="' + document.location + '?newvar=newvalue">Click here</a>')
构建URI像http://test.com/?dummy"<script>alert("Test")</script>"dummy，而是代document.location由你的代码会引发信任的网页的非信任的脚本上下文。由于构建这样的URI并将它传递给它是一个挑战，真正的XSS可以在一些更复杂的情况下工作，包括将不受信任的变量逐字地插入到语言指令流中，无论是HTML，CSS，JS还是PHP等。
XSS-unaware开发的另一个众所周知的例子是发明了JSON的历史。虽然JSON受到了很高的欢迎程度（也让我成为其支持者之一），但最初它的目的是将JS数据存储为普通的JS格式数据结构的“快速 - 肮脏”方式。为了“解析”JSON块，它们就足够了，只需要eval（）它们。幸运的是，人们很快意识到这个想法有多么的缺陷，所以现在任何懂得理智的开发人员总是会使用合适的安全JSON解析器。
非常感谢您的详细解答！现在我已经确认了framekiller代码的安全性，唯一的问题是我该怎么做才能防止扫描警报... – aliona
我重新格式化了我的答案，以显示正确的代码为'
为什么你认为有任何XSS问题？帧拦截器通常不与XSS相关，它们旨在处理欺骗和点击劫持。 –
你是要求代码以避免framekillers？在框架中加载的基于JS的解决方案也可以被访问，修改，因此被欺骗，是的。 – Smamatti
@JeremyBanks我已经更新了这个问题，以澄清我为什么要问这个 – aliona