_ MTの認証Cookieに関する脆弱性とされているものについて (02:38)

「【重要】 第三者による不正アクセスを許す危険性の対策について」で発表された内容について、「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インターフェースを通して、管理機能（の一部）を乗っ取られる可能性がある」

_ Re:「ここギコ！: MovableType脆弱性の話」 (16:49)

個人的には（そこまで重大かどうかは別として。緊急度は「低」だと思う）やっぱりこれは脆弱性といってよいのでは、と思います。

まあそう考える人もいるでしょう。元報告者の方およびその報告を受けて対応した方々はそう考えているんでしょうし（でもシックスアパート自体は「脆弱性」ではなく「危険性」と書いているんですけどね。その辺の言葉の選択もビミョー）。

ただ、Webアプリケーションで認証状態を維持する方法としては、一般的にCookieが利用されるものです。そのCookieにどのような情報が含まれるのであれ、そのCookieが漏れた場合は、ある程度の期間において認証状態が乗っ取られる可能性が発生することになります。

そのCookieによる認証をどの程度の期間有効にするかはWebアプリケーションの設計によりますが、ブラウザセッション（ブラウザを閉じるまで）を越えて有効な認証状態を継続するようなアプリケーション（MTでいうところの「情報を登録する?」オプションがあるもの）では、無期限とまでは言わないまでもかなりの期間、認証が有効な状態が継続するでしょう。

そして現在のところ、WebアプリケーションでHTTPセッション（1回のサーバーへのアクセス）を越えて状態を維持する手段としては、機能性・利便性・安全性のバランスにおいてCookieよりも妥当な方法がありません。より安全なSSL＋secure Cookieを利用する方法や、証明書やハードウェアキーなどを利用した方法は、現時点ではいつでも使える手段とはなっていません（もちろんより安全性が必要な場合は、それらを選択するべきでしょうけど）。

つまり、現在一般的なWebアプリケーションで（特にブラウザセッションを越えて）認証状態を継続しようとした場合は、多かれ少なかれ今回movable typeの認証Cookieが持っていたような危険性を持たざるをえないわけです。で、Webアプリケーション側では、漏れたら危険な認証情報をCookieに持たせる代わりに、Cookieが第三者に漏れないようなアプリケーションの設計にするわけです。Cookieが漏れないようにする（入り口に鍵をかける）ことによって、安全性を確保するわけですね。

もちろんCookieがそれほど安全なものでないことは、XSSやブラウザ自体が持つ脆弱性、盗聴の危険性などから、ある程度知られています。そして、そのような危険性への回避策もいろいろとあります。ただし安全性を高める回避策は基本的にはSSLとの組み合わせとなってしまう（利便性が損なわれすぎる）ため、一般向けのアプリケーションではそれに依存した設計はできません。

というわけで、現在のところ「Cookieにはある程度秘密の情報を保存してもいいが、その代わり第三者にCookieが漏れないような設計にする（漏れた場合はそれは脆弱性である）」というWebアプリケーションの設計方針は、（それほど重要ではない情報・機能を扱うWebアプリケーションにおいては）妥当なものだと考えています。おそらく現在稼働しているWebアプリケーションで、そのような設計方針の下に作成されたものは非常に多いのではないでしょうか。

で、私はmovable typeにおいても、基本的には（扱っている情報・機能とのバランスを考えて）上記のような設計は「あり」だと思います。つまり、「Cookieが漏れるような穴がない限りは、Cookieに秘密情報を保存していること自体は問題にならない」という考えです。ただし、より安全性を重視した設計にするならば、Cookieに保存する情報の内容自体ももっと安全な（漏れたときの影響が小さい）ものにするべきだとも思いますけど。

movable typeのような使われ方をしているWebアプリケーションでは、SSL必須にするわけにはいかないでしょうから、今回の問題を解決する方法としては、おそらくランダム性の高い（少なくともAtom APIでは使えない）認証キーをCookieに保存するようにするのでしょう。それでも「情報を登録する?」オプションが存在する限りは、その認証キーはある程度の期間有効でしょうし、その認証キーが漏れた場合はWeb管理ツールを乗っ取られる危険性があります。Cookieに登録されている情報の内容に関わらず、「Cookieが漏れたら危険である」わけです。つまり重要なのは「Cookieが漏れるかどうか」であって「Cookieに記録されている情報」の方ではない、と考えるわけです。

と、なんか長々書いてきたけど、うまい締めが思いつかないんで、ひとまず「まあそういうことなんですよ」って感じで終わっておく。それにしても俺は別に「MTスキー」でも「セキュリティスキー」でもないのに、なんでこんなに一生懸命説明しているんだろうなー。

_ 「「MT に脆弱性」@水無月ばけらのえび日記」より (21:19)

非 SSL で Basic 認証を使っていれば普通に起きていることなので、大して危険ではないような気もするのですが、危険性の評価は利用状況によるでしょう。MT を利用してるのは個人サイトだけではありませんし。

ってあたりがポイントなのかな。確か、商用サービスとか企業向けサービスとかで、MTをより機密度が高い情報サービスと連携させて動くように組み込んでいる事例とかもあった気がするし、そういうマキシマムの危険性を重視した上で「脆弱性」として扱うというのは、ありといえばありかもしれない。

ただ一般ユーザーレベルで取り扱う情報を管理するツールとしては、これを「脆弱性」扱いするのはなんか違うと思う。たとえば（SSLなしで）BASIC認証で管理機能を保護しているCGIなんかは、すべてこれと同じような危険性をはらんでいる（Cookie系のアタックに弱い点を考えると「同じような」というのは言い過ぎか）ことになるわけだから、これが「脆弱性」ならばそれらも「脆弱性」になっちゃうってことだし。