「【重要】 第三者による不正アクセスを許す危険性の対策について」で発表された内容について、「Movable Type の脆弱性の件 : NDO::Weblog」のコメント欄あたりでごちゃごちゃ書いていたことをまとめておこう。

今回の問題は結局、

• movable typeのWeb管理ツールでは、認証Cookieとして「ユーザーID」と「パスワードのハッシュ」を組み合わせた文字列を使っている
• その認証CookieはそのままAtom APIを使った外部ツールからの認証処理でも使われている
• もしも認証Cookieが漏れた場合、Web管理ツールやAtom APIインターフェースを通して、管理機能（の一部）を乗っ取られる可能性がある（追加情報：BlogWrite担当さんのコメント）

ということだと理解した。

もしも他に問題があるならば話は変わるが、今回の発表の元になった脆弱性報告を行った人の「「旅行びと日記」日記: Movable Type 3.151以前のセッションハイジャック脆弱性問題」による解説と、JVNによる発表「JVN#74012178 Movable Type におけるセッション管理の脆弱性」およびIPAによる発表「JVN#74012178：Movable Type におけるセッション管理の脆弱性」をあわせてみると、結局それ以上の問題はないように見える。

これは、「漏れてはまずいから漏れないようにしている認証情報（Cookie）が、もしも万が一漏れたら危険なことになりますよ」という話だ。しかし、具体的に「もしも万が一」を突破する手段がない限りは、別に危険ではない。あらゆる認証情報（たとえばパスワードとか）は、「もしも万が一」漏れたら危険なものだ。しかし「万が一漏れたら」というだけでは、ふつう脆弱性とは言わない。具体的に漏れる方法が見つかった段階で「脆弱性」になる。

「あなたのメールパスワードは、他人に漏れないように注意してくださいね。もしも漏れたら他人にメールを読まれちゃいますよ」というだけで、脆弱性とは言わないだろう。具体的にパスワードが漏れる手段が見つかった段階で、それは脆弱性となる。

確かにmovable typeの、認証Cookieがそのまま「無期限に」「複数の認証に」利用できるという設計は、セキュリティ的に安全性が高いとは言えない。しかしそれは「脆弱性」ではなく、「よりセキュリティ的に安全性が高い設計に変更することが望ましい」程度の問題だろう。

脆弱性報告を行った人は、その根拠となる参考文献として高木浩光氏による「安全なWebアプリ開発 31箇条の鉄則（PDF）」を挙げているようだが、その中の「14.セッションIDを使う」において高木氏は、「ユーザIDだけを引数とする方式」については、「致命的な欠陥、認証なしと同等、ファイル丸見え並の危険性」としているが、今回movable typeが採用していた「ユーザID＋パスワードのハッシュ値を引数とする方式」については、「これでもよいが、セッションを使う方式の方がより安全」としている。つまり、この方法でも問題はないわけだ。

ここからは邪推。

上記のような報告を受け、JPCERT/CCもしくはIPAからシックスアパートに対して勧告が行われた。が、上記のような判断を行うとこれは「脆弱性」とは言えない。しかし、シックスアパートの担当者は、そのことをJPCERT/CCもしくはIPAの担当者に理解してもらうことができなかった。あるいはJPCERT/CCもしくはIPAの担当者はそのことを理解できなかった。公表と対処を迫られたシックスアパートは、納得がいかないままに情報を公開した。しかし、納得できていないので、ひとまずポイントとなるキーワードはちりばめたものの、非常に微妙な表現の文章になってしまった。という経緯なのではなかろうか。

というわけで、私はこの件は脆弱性ではないと思います。ただし、認証Cookieの仕様はもうちょっと安全性の高いものに変えた方がいいとも思います。おしまい。

ちょっと修正

• 「ユーザ＋パスワードのハッシュ値を引数とする方式」→「ユーザID＋パスワードのハッシュ値を引数とする方式」
• 「JNAもしくはIPA」→「JPCERT/CCもしくはIPA」。っつーかJNAってなによ。
• 「Web管理ツールやAtom APIインターフェースを通して、管理機能を乗っ取られる可能性がある」→「Web管理ツールやAtom APIインターフェースを通して、管理機能（の一部）を乗っ取られる可能性がある」