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

前回の「基礎のキソ、エブリバディ・セッション管理！」に続き、セッション管理の基本を解説します。宿題の解答編もありますので、クイズを解く感覚でぜひ皆さんも挑戦してみてください（編集部）

[杉山俊春，株式会社ユービーセキュア]

セッション変数、利用方法をお間違えなく

　このセッション変数の仕組みは、特に認証管理に利用されることが多いが、認証にかかわる部分の管理だけでなく、画面遷移の状態やユーザーの操作内容などを記録する用途として利用されることも多い。図2にセッション変数を利用した場合とセッション変数を利用しない場合（hiddenを利用する場合）の動きを示す。

図2　セッション変数の利用パターンとhiddenの利用パターン

　セッション変数を利用する場合も、セッション変数を利用しない場合（hiddenを利用する場合）も、本質的な部分は変わらない。いずれにおいても、入力値はユーザーからのものであり、最終的に受け取った情報を格納する先も同じである。それぞれにおいて、入力に対する適切な検証や、出力に対する適切なエスケープなどが必要となる。

　hiddenは改ざんできるから危険といわれる場合があるが、セッション変数を用いた場合でも適切な入力値の検証や出力でのエスケープをしなければならない。そのため、いずれの方法を用いた場合でも、不正な値を受け取る可能性があることを前提とする必要がある。

　具体的な例を挙げると、hiddenを用いている場合、図2の（2）確認画面から（3）完了画面への遷移の際に受け渡しが行われているパラメータに対する入力値検証が行われていない場合も少なからず存在する。ただし、これはパラメータの受け渡し方法の問題ではなく、行うべき、入力値の検証および出力時のエスケープの不備の問題といえる。

　セッション変数を利用した場合でも、このケースと似た検証、エスケープの不備がある場合が多く存在する。

図3　問題が起きるセッション変数の使い方

　セッション変数の利用の仕方が間違っている場合、Webアプリケーション側で攻撃コードの入力をエラーとしているつもりでも、攻撃コードがそのままセッション変数に格納されて、確認画面を経由せずに処理の確定が可能になってしまうことがある。このケースでは、確認画面への遷移の際に入力値検証を行っているが、検証の前にセッション変数への格納を行ってしまっていることが意図した動きと異なっている部分となる。

　通常の利用方法では、確認画面を経由しないような画面遷移は行わないためテストなどでも気付きにくく、開発でも想定していないことが多いパターンであるため、見逃してしまうケースが実際に存在する。“不正な入力を行い、入力画面に戻された状態で、直接完了画面に遷移する”というような特殊なテストケースが正しく実行されなければ気付かないのではないだろうか。

　このようなケースでは、入力チェックのタイミングも問題ではあるが、入力チェックのみに頼っているため問題になっているともいえる。出力でも、適切なエスケープがなされていれば脆弱性という観点では問題にならないことが多い（データの不整合などが発生する可能性は残る）。特に、入力から出力までの流れが複数の機能にわたっていたり、複雑であったりする場合は、見落としによる影響を減らすため、入力および出力の双方のタイミングで適切な処理をすることが望ましい。

ジュン　「んー。まだよく分からんけど、つまり、hiddenもセッション変数も変わらないってこと？」

アキ　「そうかな。どっち使ってもいいんだけど、そこはセキュリティの要件として決めるんじゃなくて、業務要件として決めるってとこかな」

ナツ　「変わらないっていっても、考えなきゃいけないことがちょっと違う気がして面倒だね……」

アキ　「本質的には同じだけど、作りが違うからテストも違う方法じゃないとってとこだね」

ジュン　「え……。めんどくさ……」

アキ　「ほら、そこ。めんどくさいとかいわない！

クウ　「お二方でも教えてもらうとか、そんな時代があったのですねぇ」

ナツ　「まあ、そりゃねー」

ジュン　「でも、アキはすごかったよね。同期なのに私たちよりいろんなこと知ってたもんね」

クウ　「ほー。そうなんですかぁ。そのアキさんって人見てみたいなぁ」

ジュン　「なんか結局半分くらい昔話しちゃったね……って、もうこんな時間だ。帰らないと！」

ナツ　「おお。そっか。私たちはもうちょいゆっくりしてから行くよ」

ジュン　「了解〜。それじゃ、また今度ねー」

クウ　「さよならー」

ナツ　「またねー」

クウ　「それにしても、ナツさんとジュンさんが知り合いだったとは、世界は狭いっすね」

ナツ　「あは。ホントだねー。もしかしたら、アキとかもそのうち出てくるかもね」

クウ　「意外とあり得ますねぇ〜」

ナツ　「ま、それはそれとして、せっかくだし、セッション変数の話の続きしようか」

　入力および出力に関することでもう1つ特記すべきこととして、セッション変数を利用したWebアプリケーションでは、入力と出力の場所が異なる場合が多いことが挙げられる。このような場合にも検査を行えるツールはすでに存在はするが、多くのツールではページをまたがった検査には対応できていないのが現状である。そのため、ツールによる脆弱性の自動検知は難しくなる場合が多い。しかし、攻撃者から見た場合、入力と出力の場所が異なることは容易に把握することができ、手動での攻撃には、脆弱となる場合も少なくない。

　セッション変数で画面遷移状態を管理している場合などでは、セッション状態を考慮していないツールではそもそも該当の機能に到達すること自体が難しくなる場合が存在する。

　そのようなWebアプリケーションはセッションの状態（セッション変数の状態）を考慮した検査が可能なツールを利用するか、手動での検査を必要とする。

　hiddenを利用した場合とセッション変数を利用した場合とでは、作り自体が異なってくるため、発生する問題の個所も異なる場合がある。特定の問題が解決された分、別の問題が発生している可能性があることを考えておかなければならない。