全部是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