既知 のすべてのJavaScriptフレームキラーはXSSに対して脆弱ですか？
はいの場合、iframeから抜け出す前にサニタイズするだけで十分window.locationでしょうか？
それを行うための最良の方法は何でしょうか？
XSS攻撃の可能性の例を教えてください。
ありがとう！
UPD：私が尋ねている理由は、JSフレームキラーコードを含むがユーザーによって制御されているtop.location.replace(document.location)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について話すことができる1つの例は、次のようなコードです。
document.write('<a href="' + document.location + '?newvar=newvalue">Click here</a>')
あなたのコードでdocument.locationのようなURIを構築http://test.com/?dummy"<script>alert("Test")</script>"dummyし、代わりに置き換えると、信頼できるWebページのコンテキストで信頼できないスクリプトがトリガーされます。このようなURIを作成し、エスケープせずに渡すのは難しいため、実際のXSSは、HTML、CSS、JS、PHPなどの言語ディレクティブのフローに信頼できない変数を逐語的に挿入することを含むいくつかのより複雑なシナリオで機能します。
XSSを認識しない開発のもう1つのよく知られた例は、JSONの発明の歴史です。JSONは非常に人気がありますが（私もその支持者の中にいます）、当初はJSデータをプレーンなJS形式のデータ構造の一部として格納する「クイックアンドダーティ」な方法として意図されていました。JSONブロックを「解析」するには、それらをeval（）するだけで十分でした。幸いなことに、人々はこのアイデア全体がいかに欠陥があるかをすぐに認識しました。そのため、今日では、正気の知識のある開発者は、代わりに常に適切な安全なJSONパーサーを使用します。