これだけは知っておきたいセッション変数の基礎：もいちどイチから！ HTTP基礎訓練中（8）（3/4 ページ）

セッション変数で気を付けるべき“セッションフィクセーション”

ナツ　「さて、ここまではパラメータの受け渡しの話なんだけど、セッション変数の場合、それ以外にも気を付けないといけないことがあるんだよね」

クウ　「なんと」

ナツ　「セッション変数に格納された値自体の漏えいは大丈夫か、というとこだね」

クウ　「セッション変数に一度格納されれば、サーバ側の管理になるから大丈夫なんじゃ？」

ナツ　「んー。そういいたいところなのだけど、あと2つ考えないといけないかな」

クウ　「まだ2つも！」

ナツ　「1つ目は、セッションフィクセーションっていう脆弱性だね」

クウ　「……むむむ」

ナツ　「セッションフィクセーションは、セッションIDが攻撃者に知られてたら、入力した内容が確認画面とかで見られちゃうかもしれないってこと」

クウ　「まず、セッションフィクセーション自体があんまちゃんと理解できてないからいまいちピンとこないのです……」

ナツ　「ふむ……。じゃあ、セッションフィクセーションの話も含めて説明だね」

クウ　「お願いします＞＜」

　セッションフィクセーションという脆弱性は、攻撃者がユーザーに指定したセッションIDを利用させることで、ユーザーのセッション状態を乗っ取ることができてしまうという問題である。この脆弱性を突くための条件として、攻撃者が指定したセッションIDをユーザーに利用させることが必要であるが、ほかの脆弱性との組み合わせ（例えば、レスポンスヘッダインジェクションなど）で攻撃が容易に成功してしまう場合が存在する。

　特に、ログインなどの機能では、ログイン状態が乗っ取られてしまうと致命的な問題となるため、ログイン成功時に既存のセッションIDを破棄し、初期化して新しいものを発行するという仕組みが多くのサイトで取り入れられている。

図4　セッションフィクセーションの攻撃例

　この脆弱性は、ログイン状態を例として解説される場合が多いため、ログインのみの問題と認識されていることが多いが、ログイン処理がないようなサイトでもセッション変数を利用した作りの場合、同様のことが起きてしまう危険性を秘めている。

　例えば、新規登録を行うような機能の場合、ユーザーが情報を入力する前にセッションIDが初期化されていない場合、攻撃者が同じセッションIDを利用して確認画面などで入力情報の確認ができてしまう危険性が残されている。

　hiddenを用いた新規登録ではこのようなことは起こらないため、これが仕組みが異なるため考慮すべき点が異なっている例の1つといえる。

セッション変数、どこに格納する？

クウ　「ふむふむ……。なんか難しそうですけど、理屈的には攻撃できちゃうねってことなのですね」

ナツ　「そうだねー。ちょっと考えないと思いがいたらないから難しいところかもしれないけどね」

クウ　「もう1個の考えなきゃいけないことはどんなのなんですか？」

ナツ　「2つ目は、セッション変数の格納先はちゃんと管理されてるか」

クウ　「……格納先ですかぁ。考えたこともなかったかもです。システムがよきに計らってくれてるとしか〜」

ナツ　「セッション変数の格納先については、いろんなパターンがあるけど、ファイルとかだと、そのファイルって誰がアクセスできるかっていうのがあいまいになってる場合が多いんじゃないかな」

　セッション変数は、サーバ側で管理されている状態になるため、何らかの方法で情報を保管しておく必要が出てくる。揮発性の高い状態で保管されている場合にはさほど問題とはならないが、ファイルのような形で保存されている場合、そのファイルの保管状態について考慮する必要がある。

　例えば、ユーザー名、住所、クレジットカード番号などを入力するようなアプリケーションでセッション変数を用いていれば、たとえユーザーが確認画面までで処理をやめてしまったとしても、その情報がファイルとして保存されたままになってしまうような例も存在する。

図5　実際のセッションファイルの見え方

クウ　「そうなのかぁ〜。実は結構ちゃんと把握しておかないとダメかもですね」

ナツ　「まあ、使いやすいように隠ぺいされている部分も多いから把握が難しいこともあるけどね」

クウ　「表面的な動きだけじゃなくって、裏側で何が起こってるかも把握しないとダメなのですね〜」

ナツ　「お。もうこんな時間だね。そろそろ帰ろう」

クウ　「おおっ。帰りましょー」