<前の日記(2006-11-05) 次の日記(2006-11-11)> 最新

おおいわのこめんと (2006-11-08)


2006-11-08

[Security] Flash による Referer 偽装攻撃の有効性

なんか僕が海外に出かけるとなにかしらの事件が起こっている気がする……。とりあえず今回の件は、単純に Flash の脆弱性なんで、とっとと update しましょう、まる。

で、Flash の実験環境がないので試せないでいるし、アドバイザリもまだちゃんと読んでいないのだが、あくまで一般論として言えば XMLHTTP のようなインタフェースを提供されている状態で、Referer が設定できるだけではセキュリティへの影響は限りなく低い。むしろ、ほかのヘッダが設定できる方がやばい。Flash の脆弱性に特異な状況があればぜひ知らせてほしい。

実際、この件は昨年9月の XMLHTTP インタフェース経由の Content-Length 偽装による Request Splitting 脆弱性をレポート した際に Bugzilla 上で議論したのですが、最終的に Mozilla には Referer 偽装を防ぐコードは入っていないはずです。 僕は「設定できる必要がない」「ブラウザが正確な値を知っている」ことから設定できないようにしたらどうかと提案したのですが、security fixに必要な最小限には含まれないということで却下された模様です。

CSRF 対策の観点でこれで問題がない理由は次のとおり。

  • 同一ドメインからセッション cookie が含まれる XMLHTTP リクエストで Referer 偽装したリクエストを送ることができる脆弱性が存在する場合、攻撃は成功する。しかし、この攻撃のためには同一ドメインのページにスクリプトを送り込む必要があり、その状況ではこの脆弱性がなくても他の方法で Referer 偽装を含むかなり柔軟な攻撃が可能である。基本的に、この状況で CSRF を防ぐ方法は存在しないと考えてよい。ちなみにこの同一ドメインでの Referer 偽装方法は既知の方法だと思う(だからこそ Mozilla.org では「同一ドメインならなにできてもOK」と割り切っていると思う)が、日本国内でどれくらい知られているか、書いてやばくないかどうか、ちょっと検討してから問題がなければここに書こうと思う。
  • 他ドメインからセッション cookie が含まれる XMLHTTP リクエストを送り込める (XMLHTTP の同一ドメインチェックがバグっている) 状況では、form が含まれるページを GET して内容を解釈し、適切な値をセットして POST リクエストを送り込めば、既存のセッションを利用して任意の有効なリクエストを送出できる。よって、この状態はブラウザの深刻なバグといえる。スクリプト origin の同一ドメインチェックがバグっている状況でも同じ。
    ちなみに、仮定上の話として、この仮想のバグが修正されていない危険な状況では、フォームやページに秘密情報を入れる対策は有効ではなく、次の対策が有効になる。
    • パスワードチェック(他ドメインから読み取れる内容がHTTPレイヤの内容に限られ、他ドメインページの DOM 木が読み書きできない場合)
    • パスワードを入力する画面から遷移するすべての画面を POST で設計し、セッションを hidden パラメータで管理する (同上)
    • Referer チェック(同上、かつこのヘッダが任意にセットできない場合)
  • 他ドメインからセッション cookie が含まれない XMLHTTP リクエストを送り込める場合、cookie に含まれるセッション情報を利用したセッション乗っ取り攻撃は成功しない。

というわけで、XMLHTTP タイプのインタフェースへの攻撃で「Refererが偽装できる」という主張は頻繁にされるのですが、(意図的に隠しているのでなければ)主張としては極めて弱い、という話でした。Referer 偽装は状況がややこしいのでよく勘違いされる(そもそも HTTP でなんでも偽装できるじゃん、みたいな誤解した話もよくありますね)のですが、本当にやばいケースは「他ドメインのページから、ブラウザ利用者の意図によらずに偽装して送出できるケース」だけです。ヘッダの制限されていない XMLHTTP 系インタフェースの本当の怖さは別のところにあります。

本日のツッコミ(全6件) [メッセージを送る]
masa__ (2006-11-10 01:26)

「他ドメインのページから、ブラウザ利用者の意図によらずに偽装して送出できるケース」なので、話題になっているのだと思います。
レスポンスの受信にはクロスドメインの制限がありますが、リクエストの送信にはクロスドメインの制限がありません。セッションCookieも送信されます。

・送信出来るヘッダはFlashPlayerのバージョンごとに異なるブラックリスト方式で制限されている
・改行コードによるヘッダインジェクションが可能な脆弱性が存在する
・開発環境によって生成可能な検証コードが異なる
みたいなややこしさが満載ですので、問題を整理するのは結構大変ですが。。


ちょっと話が逸れてしまいますが、
・送信可能なヘッダがブラックリストで制限されていれば、脆弱でないと言えるのか
・脆弱でないとするならば、ブラックリストとすべきヘッダはなんであるか
という問題がすごく気になっているのですが、正解はあったりするのでしょうか?

おおいわ (2006-11-10 08:08)

基本的に、Web のセキュリティには HTTP + HTML + Javascript をデファクトスタンダードとするような形でセキュリティモデルが暗黙的に考えられていますので、個々の機能の脆弱性の有無はそれをベースに考えます。モデルが規定できない状況では安全性の議論はできません。極論ですが、特定の形の安全性機構だけをバイパスできるようなプラグインを作ることはいくらでもできますから、それができた途端にこの手法は脆弱だとか言われても困りますよね。そういう状況はプラグインの危険性として整理すべきです。同じ理由で、特定の実装の脆弱性が修正されないことを前提としたセキュリティの議論もほとんど意味がありません。

ご質問の件ですが、今回の Flash の脆弱性については、改行挿入の脆弱性の深刻さは当然として、クロスドメインでヘッダがセットできること自体が単純に実装の脆弱性と言い切って構わないと考えます。この状況で設定できてよいヘッダは存在しません。

masa__ (2006-11-11 14:42)

ありがとうございます。
そうなるとクロスドメインでヘッダがセット出来ることに起因する脆弱性はFlashの問題であり、サーバ側で解決する責任はない。と考えてよいでしょうか。
RefererなどをHTMLエンコードせずに出力するWebアプリケーションや、Apache"Expect" Header Cross-Site Scripting Vulnerability といった問題について、Flashの脆弱性であるから対策しない、という選択肢が有り得えるのかどうかが気になります。

masa__ (2006-11-11 23:47)

すいません、お昼頃、変な例でコメントを書いてしまいました。
- RefererなどをHTMLエンコードせずに出力するWebアプリケーションや、
+ Accept-LanguageなどのヘッダをHTMLエンコードせずに出力するWebアプリケーションや、
といった例の方が誤解を招きにくいですね。

----------------------------
ありがとうございます。
そうなるとクロスドメインでヘッダがセット出来ることに起因する脆弱性はFlashの問題であり、サーバ側で解決する責任はない。と考えてよいでしょうか。
Accept-LanguageなどをHTMLエンコードせずに出力するWebアプリケーションや、Apache"Expect" Header Cross-Site Scripting Vulnerability といった問題について、Flashの脆弱性であるから対策しない、という選択肢が有り得えるのかどうかが気になります。

masa__ (2006-11-13 00:11)

質問ばっかりでは申し訳がないので、個人的な見解を以下にまとめてみました。コメントなど頂けると嬉しいです。
http://d.hatena.ne.jp/masakiti2005/20061112

おおいわ (2006-11-13 10:59)

読みました。
 まず、1つ目の質問の僕の答えは Yes です。もちろん、敢えて「この手のクライアントの全ての脆弱性まで24時間7日対応でサーバ側の対処お任せください! 月500万円!」とかいうサービスをやることまでは止めませんけど :-)、責任という意味ではクライアントが悪い、の一言で済ませてよいでしょう。あ、やるなら「バッファオーバーフロー脆弱性」までちゃんと面倒見てくださいね :-P
 次に、RefererやExpectについては、エスケープするべきデータであることは明らかなので(文字列 (の部分型) →HTMLへの型変換が起こっている以上、論理的にはエスケープすべき)、「対策しなくていい」と言いきることに疑問はありますが、今回の件だけを理由に対処を替える必要が現時点ではない、という意味では同じです。
 最後に、見解を見させて頂きましたが、「結局ヲレヲレプラグインを排除してバグ入り Flash を OK にする根拠がない」点が問題かと思います。趣味でプログラミングしている範囲ならそれでもいいかも知れませんけど、きちんと「将来に渡って安全なプログラムを書く」ことを可能にするためには、「後から独自の新機能が追加されたことで、既存の安全だったものが安全でなくなる」という事象をきちんと排除しておかないといけません。Webのようなオープンな環境で、「既存の安全性設計を壊すプラグイン/新機能は存在自体が脆弱性である」という前提を壊してしまうと、Web アプリが一切書けなくなります。この判断基準は、原則としてプラグイン・ブラウザの種別によらず固定されている必要があります。
 JavaScript の XMLHTTP はそういう意味ではかなり微妙な「新機能」だったわけです。最初みたときは「大丈夫かこれ」と正直思いましたが、結局「XMLHTTPで脆弱になる既存アプリはXMLHTTPなくても脆弱」という関係がほぼ成立するので、既存のセキュリティモデルを壊していない、よって許容されても問題ない、というきちんと考えられた設計だと思います。この点が Flash の設計上の「適当にヘッダセットできるようにしちゃったぜ」脆弱性と大きく異なるところです。

[TrackBack URL: http://www.oiwa.jp/~yutaka/tdiary/trackback.rb/20061108 (note: TrackBacks are moderated: spams will not be shown.) ]

大岩 寛 (おおいわ ゆたか) <yutaka@oiwa.jp.nospam ... remove .nospam> .

Copyright © 2005-2014 Yutaka OIWA. All rights reserved.
Posted comments and trackbacks are copyrighted by their respective posters.

記事の内容について (Disclaimer / Terms and Conditions)