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

(3/30の続編)

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

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

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

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

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

CSSXSS 対策と CSRF 対策は直交している （この表現、えむけいさんから拝借）。 より正確に言えば、Referer 検査以外の秘密情報埋め込み型の CSRF 対策は 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が直接漏れるのは怖い」、 という意見は（「怖い」という感情的な表現のレベルなら）心情的には一応理解できる。 しかし、「session ID 方式は現状でずば抜けて危険である」とか、 逆に「session IDでなければ漏れた際の被害が少なく、有意に安全である」という積極的主張は、 CSRF による「間接セッション乗っ取り」の危険性 を過小評価しており、不適当であると私は考える。 また、上記のような「怖さ」に基づく対策を敢えて採用する場合でも、session ID 自体が十分に 安全に生成されていれば、session ID の SHA-1 ハッシュで十分と考えられる。 「いわゆる高木方式」やその他の値を用いる方式を含め、 付加認証情報自体のエントロピーは、CSRF攻撃に対する安全性に直結するので、 外部からの推測に対して十分に (session ID と同程度に) 安全な情報を用いる必要がある。 推測容易な手法で生成した一時トークンによるCSRF対策は、 推測困難な session ID を用いた「いわゆる高木方式」や、「高木方式ハッシュ適応版」より遥かに危険である。



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

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

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