Flashで ヘッダ操作は 脆弱か？

Security

http://d.hatena.ne.jp/harupu/20061107
http://www.oiwa.jp/~yutaka/tdiary/tb.rb/20061108
この辺で話題になってることについて書いてみます。
おおいわさんには別途質問をしているんですけど、個人的な見解も書いておいた方がいいかな。ってことで。

　基本的に、Web のセキュリティには HTTP + HTML + Javascript をデファクトスタンダードとするような形でセキュリティモデルが暗黙的に考えられていますので、個々の機能の脆弱性の有無はそれをベースに考えます。

人によっては、HTTP + HTML + Javascript + Falsh をデファクトスタンダードとし、セキュリティモデルを考える人がいるかもしれません。この前提では、addRequestHeader()のような関数の使用が(操作する必要性があるかないかは、別問題として)許容されます。暗黙的に考えるという抽象的な前提には、明確な根拠がなければならないと思います。

  • クロスドメインでセッションCookie付きのリクエスト送信が可能。かつそのレスポンスをプログラム内で読み込むことが出来る

ならば、明確に脆弱であると認識することが出来ますが

であることが、脆弱であるといえる根拠はあるでしょうか？
RFCなどの規格による定義がなされていない以上、明確な根拠が示せない前提に依存したセキュリティ対策を行うことは危険であると考えます。明確な根拠を示すには、RFCに従った脆弱性の根本的な対策を行った実装の上で、ヘッダ操作が可能なことが危険であることを証明する必要があるでしょう。ここでは、正規ユーザに被害が及ばない（正規ユーザ経由でなくても攻撃者により攻撃が成功する）ケースは除外します。
個人的に調査した範囲では、Cookieを含む全てのヘッダにおいて、問題は発生しないであろうという見解です。この中で扱いが難しいヘッダである、Hostヘッダ、Content-Lengthヘッダに関する考察は以下の通りです。

  • Content-Lengthヘッダは、このヘッダを使用する場合、適した値を送信することがRFCにより義務付けられているため、自動的な値の設定が行われるべきである
  • Hostヘッダは、正確な値を送信することがRFCにより義務付けられているため、ブラウザorプラグインにより自動的な値の設定が行われるべきである

#Refererヘッダには、正確な値を送るべきという定義はありません。
以上の考察により、

であることが脆弱性であるという前提の上で、セキュリティ対策を行うことは危険であると判断しました（Content-Length,Hostヘッダは自動設定される前提です）。
つまり、Refererの値に依存してCSRF対策を行うべきではないという結論です。

ただし、個人的にヘッダ操作が出来るFlashの仕様は感心できるものではありません。私の考察過程に穴がある場合、個人的な結論はひっくり返る可能性があります。


11/14 追記
そうなるとクロスドメインでヘッダがセット出来ることに起因する脆弱性はFlashの問題であり、サーバ側で解決する責任はない。と考えてよいでしょうか。
の質問に対して、

まず、1つ目の質問の僕の答えは Yes です

の回答を頂きました。
うーん、なるほど。この答えを頂けたことでだいぶすっきりしました。ここの切り分けをしっかりしておかないと、責任の所在を考えた判断が出来なくなってしまいますので。もし問題を指摘する必要があったなら、本質的にはFlashの問題だが、エスケープしておいた方がよいですよ。といったニュアンスに留めるのがよさそうですね。
もともとは、危険があることを証明しなければ、リリースされてから２年以上が経過している、addRequestHeader()関数の廃止を望むことは難しいと考えていましたが、逆にaddRequestHeader()のような関数を実装するならば、実装側が安全性を証明しなければならない、という考え方が正しいのかな。と思えてきました。

個人的には消化出来たので、概念的な話を離れて現実を見ていくと。。。FlashにaddRequestHeader()関数が存在する限りめんどくさい状況は続いていきそうです。廃止の方向に向かって欲しいのだけど、どのような手続きを踏んでいけばいいのか・・・