JSONに関する妄想ばなし２ - hoshikuzu

前回の当日記のJSONに関する妄想ばなしの記事において、Kanatokoさんからマジなコメントを頂いたみたいですので、補足を。



<body onload="alert(JSON.XMLDocument.parseError.srcText)" >
<script id="JSON" type="text/xml" src="ターゲットの外部jsfileのURL"  >

</script></body>

IE対象のPoCは上記のとおりです。JSONデータを１行だけ抜けます。１行になっているケースも少なくないでしょう。データ量を節約して改行を省くからです。…PoCが悪さをするためには、OSとIEとのそれぞれのバージョンにおいて、セキュリティゾーンとゾーンごとの設定の既定値が大きく影響するはずです。また、ゾーンごとの設定を緩めていると危険かもしれません。パッチが最新でない場合も、危険性が増します。　これらを踏まえて、変わったベクタのひとつですが、ローカルにおかれたHTMLファイルから、mhtファイルへとリダイレクトやiframeなどで制御を移されると、mhtファイルのセキュリティゾーンが信頼済みサイトになるケースもあることでしょう。　また、罠サイト自体が、信頼済みサイトゾーンであっても危険でしょう。難しいことを考えずともローカルにおかれたHTMLファイルのスクリプトの実行を許すインターネットオプションをオンにしてしまっている企業とかもあるかもしれません。このときには好きなだけ…
PoCが有効になる理由は、クロスドメイン通信でのセキュリティガードが緩くなってしまうからです。

こまごまと申し上げましたが、上はすべてクライアント側の問題です。　クライアント側で最新最善の対策と注意をはからっていてくれればオーケーですが、それを期待してよいのかについてはおおいに疑問です。

サーバサイドでのウェブアプリケーションで取れる対策が複数あった場合に、コストがほぼ同じであれば、クライアント側を信頼しなくとも安全である対策を選択すべき…と主張する立場もよしとしなければなりません。

POST強制による対策はサーバ側だけで一律にコントロール可能ですから、ブラウザ側をあてにしなくとも良いという点でメリットを感じます。　また、未来においてブラウザ側の穴が出てきても、比較的に強靭であるはずです。

とか急に今あわてて考えてみました。Kanatokoさんからのマジコメントに感謝いたします。

※なお、ここまでのオハナシが依然として妄想なのです。なぜならば、XHRそのものが、セキュリティゾーンとその設定値に依存して危険だったりするという事態が考えられるのに、私は少しも調べずにここまでのオハナシをしているからです。