次のページへセッション変数、利用方法をお間違えなくこのセッション変数の仕組みは、特に認証管理に利用されることが多いが、認証にかかわる部分の管理だけでなく、画面遷移の状態やユーザーの操作内容などを記録する用途として利用されることも多い。図2にセッション変数を利用した場合とセッション変数を利用しない場合(hiddenを利用する場合)の動きを示す。セッション変数の利用パターンとhiddenの利用パターンセッション変数を利用する場合も、セッション変数を利用しない場合(hiddenを利用する場合)も、本質的な部分は変わらない。いずれにおいても、入力値はユーザーからのものであり、最終的に受け取った情報を格納する先も同じである。それぞれにおいて、入力に対する適切な検証や、出力に対する適切なエスケープなどが必要となる。hiddenは改ざんできるから危険といわれる場合があるが、セッション変数を用いた場合でも適切な入力値の検証や出力でのエスケープをしなければならない。そのため、いずれの方法を用いた場合でも、不正な値を受け取る可能性があることを前提とする必要がある。具体的な例を挙げると、hiddenを用いている場合、図2の(2)確認画面から(3)完了画面への遷移の際に受け渡しが行われているパラメータに対する入力値検証が行われていない場合も少なからず存在する。これはパラメータの受け渡し方法の問題ではなく、行うべき、入力値の検証および出力時のエスケープの不備の問題といえる。セッション変数を利用した場合でも、このケースと似た検証、エスケープの不備がある場合が多く存在する。問題が起きるセッション変数の使い方セッション変数の利用の仕方が間違っている場合、Webアプリケーション側で攻撃コードの入力をエラーとしているつもりでも、攻撃コードがそのままセッション変数に格納されて、確認画面を経由せずに処理の確定が可能になってしまうことがある。このケースでは、確認画面への遷移の際に入力値検証を行っているが、検証の前にセッション変数への格納を行ってしまっていることが意図した動きと異なっている部分となる。通常の利用方法では、確認画面を経由しないような画面遷移は行わないためテストなどでも気付きにくく、開発でも想定していないことが多いパターンであるため、見逃してしまうケースが実際に存在する。“不正な入力を行い、入力画面に戻された状態で、直接完了画面に遷移する”というような特殊なテストケースが正しく実行されなければ気付かないのではないだろうか。このようなケースでは、入力チェックのタイミングも問題ではあるが、入力チェックのみに頼っているため問題になっているともいえる。出力でも、適切なエスケープがなされていれば脆弱性という観点では問題にならないことが多い(データの不整合などが発生する可能性は残る)。入力から出力までの流れが複数の機能にわたっていたり、複雑であったりする場合は、見落としによる影響を減らすため、入力および出力の双方のタイミングで適切な処理をすることが望ましい。