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

おおいわのこめんと (2006-04-02)


2006-04-02

[Security] CSRF と CSSXSS に関する議論について

(3/30の続編)

思いっ切り一時 Slashdottedでした (^^;。 自前サーバの耐久性低くて済みません>読者のみなさま。

# FastCGI のおかげで、tDiary の負荷が上がってもシステム運用には影響出てなくて、 復旧もそんなに大変じゃない辺りはいい感じなんですけど、tDiary 自体は割とすぐ重くなりますね……。

随分と CSSXSS*1 のIEのバグ挙動の性質が整理されてきたようです。 そうは言っても所詮IE6の実装バグに起因する挙動なんで、性質を推定しても それが本当に正しいのかは観察の積み上げというレベルでしかわからないという嫌な状況ではあります。

元々の30日の原稿、 CSSXSS 自体の性質にはあまり踏み込まず、 一般的に「他ドメインのページからデータの読み取りが可能な脆弱性がブラウザにある場合」という前提で 書いたものですが、 「えむけい」さんのメッセージ、 /.J でのAnonymous Cowardtix さん「ワンタイムトークンは不要では」 などのコメント を読んでいて、僕の中では大分問題の所在が整理されてきた感じです。

CSSXSS 脆弱性にのみ着目して、今回の問題について私の立場から改めて整理しますと、

  • CSSXSS 対策と CSRF 対策は直交している(この表現、えむけいさんから拝借)。 より正確に言えば、Referer 検査以外の秘密情報埋め込み型の CSRF 対策は CSSXSS 脆弱性の影響を受けるが、その場合の対処法は CSRF 対策の手法には依存せず共通である。
  • CSSXSS の場当たり的なバグ対策としては、
    • CSSXSS の「GETメソッドで取得したページの内容しか読めない」という性質を用いて、 CSRF対策のための認証情報(例えば「いわゆる高木方式」における session ID)や 個人のプライバシー情報など、第三者に読み取られたくないデータの格納されているページを 全て POST で取得するように改変する。
    • CSSXSS では特定の形のページ(CSSのように見えるページ?)の特定のデータしか 読み取れないことを利用し、第三者に読み取られたくないデータが CSSXSS の読み取り可能データ領域に入らないように「巧妙に」エンコードしてやる。

    などの対策が現状では考えられる (この辺り、今回の各議論の皆様の知見を大いに参考)。

    但し、この辺りの議論、特に後者に関してはIE6のバグ挙動の正確で網羅的な検証が必要。 また、IE7 では既に修正されている模様 (/.J より)

  • 一方で、CSRF 対策はこれまで通り、攻撃者の知り得ない何らかの値を付加認証情報としてフォームに含める。 最も単純には、「いわゆる高木方式」=「session ID をフォーム入力に付加」でよい。
    • 「『いわゆる高木方式』否定派」の方々の提唱する手法を含め、 どのような値を送信すると決めた場合でも、上記のCSSXSS対策は (IE6のバグに対処すると心に決めたなら) 別途必要
    • どのような付加認証情報であっても、送信すべき値そのものが CSSXSS や未知のブラウザ脆弱性などで 盗まれた場合、同一の攻撃手法で CSRF 攻撃を受けるため、どれも危険になる。 この1点に関しては、「いわゆる高木方式」を含む各手法間の優劣は存在しない。
      つまり、「いわゆる高木方式」に上に書いた CSSXSS 対策を施せば、 CSSXSS を利用した CSRF / セッション窃盗 攻撃に対して安全になる。
    • 「『いわゆる高木方式』で万が一フォームの値が漏れたときにsession IDが直接漏れるのは怖い」、 という意見は(「怖い」という感情的な表現のレベルなら)心情的には一応理解できる。 *2 しかし、「session ID 方式は現状でずば抜けて危険である」とか、 逆に「session IDでなければ漏れた際の被害が少なく、有意に安全である」という積極的主張は、 CSRF による「間接セッション乗っ取り」の危険性*3 を過小評価しており、不適当であると私は考える。
    • また、上記のような「怖さ」に基づく対策を敢えて採用する場合でも、session ID 自体が十分に 安全に生成されていれば、session ID の SHA-1 ハッシュで十分と考えられる。 *4
    • 「いわゆる高木方式」やその他の値を用いる方式を含め、 付加認証情報自体のエントロピーは、CSRF攻撃に対する安全性に直結するので、 外部からの推測に対して十分に (session ID と同程度に) 安全な情報を用いる必要がある。 推測容易な手法で生成した一時トークンによるCSRF対策は、 推測困難な session ID を用いた「いわゆる高木方式」や、「高木方式ハッシュ適応版」より遥かに危険である。 *5

といった感じになりますね。みなさま貴重なご意見ありがとうございます。

私個人的にも CSSXSS は興味深い問題ではあるんで、キチンと対策を考えてみたいとは 思っていますが、仕様の明示できないバグ挙動の回避は、ある意味いくら考えても 他に抜け穴のある可能性が否定できないんで、微妙ではあるんですよね。 元稿の脚注で触れた昨年の Ruby の件ではソースファイルがあったのである意味で挙動は正確に把握できたのですが、 IEに関しては完全にブラックボックスなので、思いついた攻撃の範囲にどうしても限定されてしまうんですよね……。

さて、元の(えびさんから参照されていた金床さんの)ページは閉鎖されてしまったようなんですけど... (^^;; 「(刑法上の) 名誉毀損」ってのも微妙だなぁ (^^;;

[Misc] Mirror.co.uk: Reebok's killer charm made of 99% lead

相変わらず情報セキュリティ以外のネタ満載な(笑) セキュリティホールmemoより。

よくある(よくあっちゃ困るけど)不幸な混入話かと思っていたら、そんなレベルじゃなかったらしい。

And tests after his death in Minnesota found bracelets with 99 per cent lead - against a safety limit of 0.06 per cent.

99%鉛って、要するにこの手の安価な物品の加工材料としてはほぼ純鉛ってことですよね。 どういう材料調達・製造工程経るとそんなものが作れるんだ……。 まぁ確かに鉛は溶かすの簡単だけどね……。

想定していた正規の材料によっては比重で判りそうな気もするけど、検収者は気付かなかったのかねぇ。 そもそも何の想定材料も考えていなかった、が正解?

*1 あちこちで言われている通り、この呼び名もイマイチですね。 cross-domain resource access via CSS であって、XSS とは直接関係無いんですが……。

*2 その意味で、「別に元々 session ID 使うのが脆弱性というわけではないんだけど、 大した手間じゃないんだからハッシュ取っとけば『気分が楽』だよね」位の主張なら判らなくもないが、 所詮はハッシュが漏れたらそれだけでアウトなんで、その認識がないと却って心理ファクタの油断の分だけ危険。

*3 特に今回の場合は単なるCSRFではなく、 「任意のURLのGETによる取得内容を読みとることのできる」裏口付きの前提の元でのCSRFであり、 通常のCSRF以上に強力であることにも留意すべき。(4/3追記)

*4 SHA-1 ハッシュに対する辞書攻撃などのオフライン攻撃は、session ID自体の 推測不能性が十分であるならば無視できる。
この手法において、ハッシュ値が漏れた (よって CSRF によるセッションの乗っ取り攻撃を受ける状態になった) 場合でも session ID 自体は推測不能であるためには、 session ID に対するオンラインアタックによる直接乗っ取りを想定した場合よりは若干高い秘密量が session ID に必要となる。とはいえ、これは攻撃に辞書を用いた場合でも80ビット程度で十分なので、 実装上大きな問題になるとは考えられない。新たにコードを書くするならば、SHA-1 に合わせて 160ビットにしておけばよい。
なお、このようなハッシュの使い方で salt を用いた HMAC が必要になるケースは、元の秘密情報が脆弱で 辞書攻撃に耐えない場合(例えばパスワードなど)か、 同一の値が複数箇所で用いられる可能性が有意にあり、一致が外部から推測できては困る場合 (これもパスワードとか)に限られ、本件では該当しない。
ちなみに "SHA-1(session ID)" 自体の情報量は、session ID が 159bit 以下の場合は ほぼその情報量に一致、160bit の場合で 159.3bit (2005年12月1日「逆誕生日問題」参照)、 それを越える場合は160bitとなる。

*5 当然だが、推測可能な session ID ってのは CSRF を仮定するまでもなく論外に危険なので、 「session ID が推測困難」は大前提。この議論は、「session ID はフレームワークが安全な方法 (例えば /dev/urandom とか CryptoAPI とか) を使って予め用意してくれているような環境で、 一時キー作るときには rand で作る (or それしか方法がない)、とかやると却って危いよー」 という主旨。

[TrackBack URL: http://www.oiwa.jp/~yutaka/tdiary/trackback.rb/20060402 (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)