いかんいかん、感想を書かないでいたら『』が届いちゃったよ。こっちをちゃんと読む前に『ウェブログの心理学』の感想を書いておこう。

この本は、Web（インターネット）で個人的な文章を継続して発表すること（ウェブログ/Web日記/個人サイトなど。以降ウェブログという言葉で代表させる）に関するさまざまな知識や情報をまとめたものだ。

内容としては、

• Webを使ったコミュニケーションの特徴
• 日本における歴史、ツールやサービス、コミュニティの紹介
• ウェブログの分類
• ウェブログを書くということ・人の分析
• 従来そして今後の課題
• Web日記/ウェブログを続けるに当たってのさまざまなアドバイス

などが網羅されている。

実際長年にわたってウェブログを書いてきた筆者たちが、その経験と社会心理学者という学問的知識を背景にまとめたこれらの文章は、ウェブログ作者のためのケーススタディとして活用することができる。

すでにある程度の期間ウェブログを続けてきた人は、その中のいくつかの知見をすでに手に入れていることだろう。また、自分の中で漠然とまとめきれずにいた知見が、この本によって改めて明確化（文章化）されるといったことも多いだろう。まだウェブログの経験が浅い人も、この本を読んでおくことでためになる点が多いはずだ。歴史は繰り返されており、先人が経験によって培ったノウハウは、現在でも十分に役に立つことが多いからだ。

たとえば、p17で紹介されている、さまざまなウェブログを自己表現の方法と情報の種類で分類した以下のマトリックスなどは、自己および他者のウェブログを分析する際には非常に参考になるだろう。

	直接的自己表現	間接的自己表現
情報重視	個人属性タイプ（名刺型）	情報編集タイプ（雑誌型）
自己重視	内面表出タイプ（自伝型）	作品展示タイプ（作品型）

歴史資料としての意義は、『教科書に載らないニッポンのインターネットの歴史教科書』の圧倒的な情報量には劣るが、『教科書に〜』は歴史的な事実の詳細な記録という形式で記述されており、たいていの人はその圧倒的な情報量を咀嚼しきれないだろう。ウェブログに特化した歴史の概要を追いたい場合は『ウェブログの心理学』の方が便利だろう。

で、ここからは余談。

『ウェブログの心理学』は比較的細かいところに気を配ったアドバイスが書かれているけれども、あくまでも「表通りの歩き方」的な話にとどまっている。で、『教科書に〜』をぱらぱらっとめくった感触では、こっちはかなり裏通りの話まで書かれているみたいだけど、基本的に「事実の記録」を重視している感じで、『ウェブログの心理学』みたいなアドバイス的な部分は含まれていなさそう。

というわけで、誰か「裏通りの歩き方」的なアドバイス本を書いてみると、スキマが埋まっていいかもしれない、とか思った。具体的には、「フレームにならない議論のやり方」「2chで晒されたときの対処法」とか。あるいは「ネットバトル（フレーム合戦）のやり方」もあった方がいいかもしれない。小倉弁護士的あたりに「コメントスクラムへの対処法」とか寄稿してもらいつつ（笑）。

なんか

読み返してみると、まるで『ウェブログの心理学』がハウトゥ本のような書き方になっているな。『ウェブログの心理学』で得られるのは、いわゆるハウトゥ本的な知見ではなく、メタウェブログ（ウェブログを書くということに関してのメタな思索）的な知見なのですよ。とフォローしておこう。

自分が使いたいから作ったもの（だから俺が使いやすければそれでよくで、あまり一般向けに作り込まない）と、この技術をこういう風に使うとこういうことができますよ（誰かそれを応用してもっと楽しげなものを作ってね）というものがほとんどなんで、ぱくりフリーですよ。公開しているコードなんかも、俺以外の人の権利を侵害するものでなければ、自由に使っていいですよ。

と一応書いておこう。

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

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

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

ただ、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スキー」でも「セキュリティスキー」でもないのに、なんでこんなに一生懸命説明しているんだろうなー。

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

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

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

「Marklet BLOG: 脆弱性とセキュリティホール」にある、

例えば、ID、パスワードを入力して認証するシステムでは、その２つキーを盗み出したり、推測したり、総当たりで試す事によって突破できる可能性があるため、「脆弱性を抱えている」と言えます。

一般に「脆弱性がある」といった場合、保護しようとする情報の重要度に見合わないレベルの脆弱性が認められた場合に使われるのではないでしょうか？

ってあたりから考慮すると、

企業ユーザー・商用サービス等、秘匿度の高い情報を取り扱っている場合

脆弱性である。ただし、緊急度低・危険度低。パッチが出るまでの対処法として、SSLの利用、管理機能の利用後は必ずログアウトする、「情報を登録する?」オプションは使用しない、という運用を推奨。

一般個人ユーザー等、秘匿度の低い情報を取り扱っている場合

脆弱性というレベルではない。パッチが出るまで通常の使用を続けても問題ない。

ってあたりが妥当なんじゃないかなーと思う。

IPA Webサイトにおきまして、

・JVN#74012178：Movable Type におけるセッション管理の脆弱性 - http://www.ipa.go.jp/security/vuln/documents/2005/JVN_74012178_MovableType.html

として公開されております脆弱性問題について、Webアプリケーション開発者の立場としては、上記ページの図に書かれている2番目のステップ「悪意あるユーザーにセッション情報を盗み取られる」を実現するための具体的な手段（欠陥）が存在しない限り、それは「脆弱性」として扱うべきではないのではないかと考えております。

というのは、「悪意あるユーザーにセッション情報を盗み取られる」ステップの具体的手段を考慮しなかった場合、現在標準的なWeb関連技術で作成されているWebアプリケーションの大多数が「もしもセッション情報を盗み取られたら」「不正アクセスされてしまう」に該当してしまい、それらは「脆弱性」を持つということになってしまうからです。

もしよろしければ、この件が「脆弱性」として扱われることになった詳しい経緯をお聞かせ願えませんでしょうか。また、もしご回答をいただける場合は、その内容を私のWebサイトで公開する許可をいただけないでしょうか。

この件に関しては、私のWebサイト（http://tdiary.ishinao.net/20050514.html）において、より詳しい思考の過程を書いておりますので、もしよろしければ参考情報としてご覧ください。

以上、よろしくお願いします。

想定する（というか納得できそうな）回答例としては

• 「セッション情報が盗まれたら不正アクセスされる」が問題なのではなく、セッション情報として「無期限に」「他の認証でも利用可能な」情報が使われていたことが問題である。→そのポイントを明確にする文書にして欲しい
• MTが企業系情報サービスなどにも組み込まれており、それらの事例においてはこの仕様が重大な問題を引き起こす可能性があるため。→その辺のニュアンスを文書に盛り込んで欲しいなー

といった感じかなー。

「認証の維持」といわゆる「セッション管理」とはちょっと違う。

一般的なユーザー認証では、サーバー側にIDとパスワード（のハッシュ）という情報を持ち、ユーザーがフォームから入力したIDとパスワードの組み合わせを、サーバーの持つ情報と照合することによって認証処理を行う。

ただし、毎回フォームでIDとパスワードを入力するのは面倒なんで、一度入力したIDとパスワードは、2回目以降いちいち入力せずに認証処理を行いたい。要するに一度入力されたIDとパスワードを覚えておいて使い回したい。

BASIC認証とかのブラウザが対応している認証方式の場合は、ブラウザの機能として覚えてくれる。そして、アクセスのたびにIDとパスワード（のBASE64エンコード）が送られ、毎回認証処理が行われる。ちなみにBASIC認証で送られるパスワードのBASE64エンコードは可逆なので、パスワードを平文で送っているのと大して変わらない。

ブラウザの標準機能を使わず認証を行う場合は、Webの標準的な機能を使ってIDとパスワードを覚えておかないといけない。そこでCookieが使われることになる。IDとパスワード（平文あるいはBASE64のような可逆エンコード）を覚えておくというのが一番単純なやり方（初回にフォームからIDとパスワードが送られたときと同じ照合コードが使える）だけど、ちょっと安全性を高めたければ、IDとパスワードのハッシュ（非可逆）を覚えておく。

サーバーサイドには、IDとパスワード（のハッシュ）の組み合わせしか認証チェック用の情報を持たないことが前提なんで、ブラウザから送られる情報は、サーバーに保存されているIDとパスワード（のハッシュ）を使って照合可能なデータである必要がある。

一方（いわゆる）セッション管理というのは、基本的には認証とは関係なく、単にあるブラウザからの連続したアクセスを同定し、複数回のアクセスにおいて状態（データ）をサーバー上で保持（認識）したい、という話だ。

そのためには、あるブラウザからのアクセスを特定するために、ブラウザごとにユニークな識別IDを割り振り、それを使用する。それがセッションID。そのセッションIDも基本的にはCookieに保存することになる。

セッションIDはユニークであれば連番とかで生成してもいいけど、連番で生成したセッションIDの場合、他の人のセッションIDが類推できてしまう。たとえば自分のセッションIDが100だったら、「きっと99とか101とかの人もいるに違いない」とか。だから、セッションIDはできるだけ類推の効かない（ランダム性の高い）ものを使うことで、安全性を高める必要がある。

セッション管理を使えばあらゆる状態を維持することができるんで、もちろん認証の維持にも使うことができる。セッション管理の仕組みを認証の維持に使うことによって、IDやパスワードと直接結びつくデータを毎回送信する必要がなくなり、安全性が高まる。

またいわゆるセッション管理機能を使わない場合でも、直接IDやパスワードと結びつかないランダムでユニークな認証キーをサーバー側で生成し、サーバー上でIDと結びつけておくと同時に、ブラウザにその認証キーを覚えてもらう。そして、その認証キーを利用して認証処理を行うことによって、直接IDやパスワードに結びつく情報のやりとりを最小限に抑えることにより、安全性を高めることができる（他にも方法はいろいろある）。

ただし、セッションIDやランダムな認証キーを利用する場合でも、直接IDやパスワードと結びつくデータが流れないというだけで、セッションIDやランダムな認証キー自体が直接認証機能と結びつき、それを悪用されることで認証処理を乗っ取られることに代わりはない。

また、せっかくセッションIDやランダムな認証キーを利用していても、その有効期間が必要以上に長い場合は、結局その文字列自体をパスワードのように利用することができ、セッションIDやランダムな認証キーを使っているからより安全だ、とは言い切れない。もちろんCookieが漏れるような設計だったら、セッションIDやランダムな認証キーを利用していても意味がない。

って俺は毎日なんでこんな文章を書いているんだろうなー。

ところで、JavaScript必須でチャレンジ＆レスポンスとかやっている例ってあるのかな？とふと思った。

昨日の問い合わせの返事が来た。なかなか早いなー。すげー時間がかかるかと思ったのに。ちなみに内容は以下の通り（公開許可取得済み）。

IPA セキュリティセンターです。

お問合せいただきました件ですが、脆弱性関連情報の個々の取扱いの詳細に関するご質問につきましては、回答を控えさせていただいておりますので、ご了承下さい。

本件が脆弱性であるかどうかの判断は、2004年7月7日に経済産業省より公示された「ソフトウエア等脆弱性関連情報取扱基準」（平成16年経済産業省告示第235 号）および、「情報セキュリティ早期警戒パートナーシップガイドライン」に基づき行ないました。

詳しくは IPA ウェブサイトの「脆弱性関連情報の取扱い」より、それぞれの資料をご覧下さい。

http://www.ipa.go.jp/security/vuln/

以上、よろしくお願いいたします。

ということで、個々の取り扱いの詳細については答えてもらえないそうだ。まあ確かに細かい問い合わせにいちいち答えてられないだろうしなー。詳細に答えてもらいたければ、聞く方もそれなりの手続きをふまなきゃだめなんだろう。

で、返答のメールに書かれていた「ソフトウエア等脆弱性関連情報取扱基準（PDF）」および「情報セキュリティ早期警戒パートナーシップガイドライン（PDF）」を読んでみる。

「脆弱性」の定義は、前者では、

ソフトウエア等において、コンピュータウイルス、コンピュータ不正アクセス等の攻撃によりその機能や性能を損なう原因となり得る安全性上の問題箇所。ウェブアプリケーションにあっては、ウェブサイト運営者がアクセス制御機能により保護すべき情報等に誰もがアクセスできるような、安全性が欠如している状態を含む。

後者では、

脆弱性とは、ソフトウエア製品やウェブアプリケーション等において、コンピュータ不正アクセスやコンピュータウイルス等の攻撃により、その機能や性能を損なう原因となり得るセキュリティ上の問題箇所です。

なお、ウェブアプリケーションにおいて、ウェブサイト運営者の不適切な運用によって、個人情報等が適切なアクセス制御の下に管理されておらずセキュリティが維持できなくなっている状態も含みます。（ウェブサイトの不適切な運用に関しては付録４に示します。）

となっていた。

「攻撃によりその機能や性能を損なう原因となり得る安全性上の問題箇所」の解釈がポイントなんだろうな。俺は「具体的な攻撃手段」が存在した上での「安全性上の問題箇所」が「脆弱性である」と考えるんだけど、ポイントを「安全性上の問題箇所」にある（具体的な攻撃手段はどうでもいい）と読む人もいるんだろうな。

個人的にはすごく納得がいかないんだけど、これ以上追求するのは大変そうなんで、ここまで調べた段階でしばらく様子を見ることにしよう。

様子を見るといいながら

やっぱり気になったんで、もう1回だけIPAに聞いてみることにした。内容は

「具体的な攻撃手段」が存在しない場合でも、「セキュリティ上の問題箇所」が存在すれば、「脆弱性」であると解釈されるのでしょうか？

といった感じ。

粘着ですまんのー＞IPAの担当者の方。でも今後の開発指針とかにいろいろ影響が出るんで、つっこんで聞いておきたいところなんだよなー。

っつーかぶっちゃけ、HTTPで認証をやっているありとあらゆるものは、すべて脆弱性だっていう判断だって、全然おかしくないわけよ。というか、現状のインターネットははっきり言ってゆるゆるのがばがばなわけだよ。だから、ヒジョーにキビシク脆弱性認定を行うことで、「痛みを伴う改革を断行しよう」とか言われたら、それはそれで納得できるわけよ。で、その辺どうなの？

• Apacheのモジュール一覧を見直し、だいぶいらないモジュールを削減した（静的組み込みにはしてないけど）→気休め程度
• 重い検索（テーブルロックがかかるやつ）専用MySQLプロセスを別に立てていたのをやめ、MySQLプロセスを1個にした→やっぱこれが重かったよね
• その代わり、slow_logから抜き出した重い検索処理は、実行前にexplainでその重さを（簡単に言うと各検索条件ごとのrowsの多さ）をチェックし、ある程度以上重い検索と予想される場合は、実行をキャンセルするようにした→これで1プロセスですべての検索を処理しても、テーブルロックされる時間が短くなった
• httpdのログをweeklyでローテートしていたんだけど、その日本語検索キーワード解析処理とかがめちゃめちゃ重かったんで、httpdのログはdailyでローテートするようにした→これは定期的にスラッシング気味になる原因だったっぽい
• MySQL、Apacheのパラメータを状況に合わせて微調整→そんなに意味はない

って感じ。