JSONハイジャック攻撃が最新のブラウザで機能しないのはなぜですか？どのように修正されましたか？
JSONハイジャックの脆弱性がすべての最新のブラウザーで修正されていることを理解していますが、正確にはどうですか？
JSONハイジャック攻撃を防ぐための手法（つまり、Googleのようにwhile(1);を前に付ける）について述べた記事はたくさんありますが、今日でもWebアプリケーションに実装する必要があるかどうかについては誰も説明していません（明らかにユーザーが勝ったと仮定します）非常に古いブラウザでアプリを使用していない）。
JSONデータを配列リテラルとして返すことは、今日のセキュリティリスクと考えるべきですか？
Googleがwhileを先頭に追加する原因となったJSONの問題は、Firefoxの初期バージョン（具体的には1.5および2b）と同じ原因であり、オフサイトから通常のスクリプトタグとしてJSONファイルをロードでき、到達可能なデータ。
通常、JSONファイルは、スクリプトとしてロードされた場合、JSエンジンに何もしないように「通知」しないため、データ構造への参照はありません/ありません。 JSのセキュリティは参照ベースであるため、想定は適切です。 JSONオブジェクトリテラル（_{}_）はコードの中括弧のように見えるため、実際にはJSのエンジンにはあいまいであり、構文エラーを引き起こします。古いFFの問題は、解析または作成時に配列リテラルが他のコードを実行する原因となる、あいまいなランタイム変更を使用できることでした。その他のコードは、内省的に配列の内容に到達する可能性があり、これはバグでした。
一部のXML形状はFFのE4X拡張（Ecmascript4XML）を使用する有効なJavaScript（tm）であるとFirefoxが見なしたため、XMLに関連する問題がありました。 IEは、JavaScript以外のコンテンツがスクリプトとしてロードされてエラーが発生するが、事前に適用されたグローバルエラーハンドラーにコンテンツが明らかになるという問題がありました。問題。
リモートのJSONコンテンツを取得する実行可能な安全な方法があるため、廃止されたブラウザーとJSONp/eval()エクスプロイトの脆弱性はコンテンツのロードに適用されなくなりました。有効なJSONリソースをスクリプトとしてロードしようとすると、他のJSからコンテンツにアクセスできません。
最後に、これは実際にはセキュリティとはあまり関係がないと思います。 php、curl、python etcは、ブラウザのルールについてわずらわしさを与えません。データがそこにある場合、そこにあります。同じオリジンポリシーがその点で行う唯一のことは、実行の防止です。秘密のデータを盗む工場の「ディープリンク」リソース。