Webアプリの設計とセッション・認可
Webアプリケーションの設計におけるセッション管理と認可は、利用者が正しい本人であることを保ち、その利用者に許された情報や処理だけを扱わせる仕組みである。セッション管理では、ログイン後の利用者をセッションIDで識別し、ログアウト後の再利用や固定化による乗っ取りを防ぐ。認可では、認証済みの利用者が本来アクセスできない情報や機能に到達できないよう、サーバ側で権限を判定する。
ログアウト時のセッション処理
ログアウト時に必要な処理は、サーバ側でセッションIDを無効にすることである。ブラウザにセッションIDが残っていても、サーバが無効化したIDでのアクセスを認めなければ、盗まれたIDによる乗っ取りの機会が減る。
ブラウザのキャッシュを消去したり、セッションIDをブラウザのディスクに保存したりしても、サーバ側のセッションが有効なままでは乗っ取りを防げない。 利用者が自分専用のPCを使う状況であっても、サーバ側でセッションを無効化する処理が必要である点は変わらない。
セッションIDの固定化と推測
セッションIDの固定化攻撃では、攻撃者が正規サイトから取得したセッションIDを利用者のブラウザに送り込み、利用者がそのIDでログインした後、攻撃者が同じIDを使って利用者になりすます。ログイン後もIDが変わらないことが成立条件であるため、認証時のセッションIDの扱いが対策の要点になる。 ログイン成功の時点でセッションIDを新たに発行し直す設計が、一般的な対策である。
推測攻撃は固定化攻撃とは別の攻撃であり、攻撃者が利用者のセッションIDを予測して使うものである。この区別は、攻撃者が関与してIDを指定するか、IDを予測するかの違いで判断する。 また、URLにセッションIDを含める設計は、履歴やログ、参照元情報から漏えいするおそれがあるため避ける。
重要な情報の表示前の再認証
セッションが乗っ取られた場合でも被害を広げないため、個人情報など重要な情報を表示する直前に、パスワードによる利用者認証を行う。乗っ取られた有効なセッションだけでは再認証を通過できず、重要情報を表示させられないため、被害の拡大を防げる。
この節の続き
- 認可制御の不備とアクセス制御の回避
- 設計段階での確認と診断結果の活用
- 試験で問われやすい区別
ここまでが冒頭部分です。ログインすると、無料でも1日2節まで全文をお読みいただけます。
アプリでこの節を読む