ステップ1でWebアクセスのセッション管理の基本を解説した。実際のセッション管理では，セキュリティ対策が欠かせない。
セッションを勝手に使われる
Webアクセスのセッション管理でセキュリティ上の脅威になるのは，（1）セッション・ハイジャック，（2）セッション・フィクゼーション，（3）クロスサイト・リクエスト・フォージェリの三つだ（図2-1）。
セッション・ハイジャックは，セッション管理におけるセキュリティ上の最大の脅威だ（図2-1の1）。クラッカが盗聴や推測などでユーザーのセッションIDを入手し，そのセッションIDを使ってWebサイトにアクセスする。いわゆる「成りすまし」である。クラッカからのWebアクセスを受け付けたWebサイトは，セッションIDから正規のユーザーだと誤認識してしまうわけだ。
2番目のセッション・フィクゼーションは，セッション・ハイジャックと同じ成りすましに使われるものだが，攻撃方法が複雑だ（同2）。
セッション・フィクゼーションを試みるクラッカは，WebサイトにアクセスしてセッションIDを取得する。ただしクラッカは，ログインまではしない。そのセッションIDを使ったログインを，狙いを定めた正規ユーザーにやらせるのがミソだ。クラッカは自分が取得したセッションIDを埋め込んだ偽のログイン・ページを用意し，それを正規ユーザーに使わせてログインさせる。ログインさせた後にクラッカが自分で取得したセッションIDを使ってアクセスして，まんまとそのユーザーに成りすます。
3番目のクロスサイト・リクエスト・フォージェリは，正規のユーザーがWebアクセスしている最中に，ユーザーの意図とは違う操作をさせられてしまう攻撃だ。Webアプリとの間にセッションが張られているユーザーにスクリプト付きのWebページを送り込み，そのスクリプトにWebアプリを利用させる。ユーザーが気付かない間に取引されてしまったりする。
Webアプリを利用するユーザー側でこれらの脅威を防ぐのは難しい。セッションを管理するWebサイト側で対策するのが基本だ。
セッションIDには乱数を使う
そこで，Webサイトの対策を見ていこう。まずは，セッション・ハイジャック対策だ。セッション・ハイジャック対策は，セッションIDを漏えいさせないようにすることに尽きる。セッションIDの漏えいには複数のパターンに応じた対策が必要になる（図2-2）。
攻撃のパターンの中で原始的なのは，セッションIDの推測だ（図2-2の1）。仮にWebアプリがセッションIDにユーザー名をそのまま使っているとしよう。そのようなユーザー名を手に入れたクラッカは，そのユーザーがログインしているタイミングを見計らって，そのセッションIDでアクセスすればセッション・ハイジャックができてしまう。セッションIDにユーザー名を使っていなくても，連番のような推測されやすい値を使っている場合も危ない。
このような推測によるセッション・ハイジャックを防ぐのは難しくない。セッションIDに十分の長さの乱数を使って，ユーザーIDやほかのユーザーのセッションIDから推測できないようにすればよい。Webアプリのフレームワークのほとんどは，乱数で十分の長さのセッションIDを生成する機能を備えている。この機能を使えば問題は起こらない。
