PR

 ステップ1でWebアクセスのセッション管理の基本を解説した。実際のセッション管理では,セキュリティ対策が欠かせない。

セッションを勝手に使われる

 Webアクセスのセッション管理でセキュリティ上の脅威になるのは,(1)セッション・ハイジャック,(2)セッション・フィクゼーション,(3)クロスサイト・リクエスト・フォージェリの三つだ(図2-1)。

図2-1●セッション管理に潜む三つの脅威<br>セッション・ハイジャック,セッション・フィクゼーション,クロスサイト・リクエスト・フォージェリの三つがある。せっかく認証を受けたセッションであっても,他人に悪用されてしまうことがある。
図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)。

図2-2●セッションID漏えいのパターンと対策<br>セッションID漏えいのパターンは4種類ある。対策として考えられるのは,セッションIDに推測されない乱数を使うこと,SSLで暗号化すること,セッションIDをURLに含めないことがある。
図2-2●セッションID漏えいのパターンと対策
セッションID漏えいのパターンは4種類ある。対策として考えられるのは,セッションIDに推測されない乱数を使うこと,SSLで暗号化すること,セッションIDをURLに含めないことがある。
[画像のクリックで拡大表示]

 攻撃のパターンの中で原始的なのは,セッションIDの推測だ(図2-2の1)。仮にWebアプリがセッションIDにユーザー名をそのまま使っているとしよう。そのようなユーザー名を手に入れたクラッカは,そのユーザーがログインしているタイミングを見計らって,そのセッションIDでアクセスすればセッション・ハイジャックができてしまう。セッションIDにユーザー名を使っていなくても,連番のような推測されやすい値を使っている場合も危ない。

 このような推測によるセッション・ハイジャックを防ぐのは難しくない。セッションIDに十分の長さの乱数を使って,ユーザーIDやほかのユーザーのセッションIDから推測できないようにすればよい。Webアプリのフレームワークのほとんどは,乱数で十分の長さのセッションIDを生成する機能を備えている。この機能を使えば問題は起こらない。