_ 認証の維持とセッション管理の違い (09:11)

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

一般的なユーザー認証では、サーバー側に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から返事が来た (16:05)

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

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

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

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

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

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

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

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

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

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

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

後者では、

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

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

となっていた。

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

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

様子を見るといいながら

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

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

といった感じ。

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

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