第3回：Railsでセッションハイジャックを実体験 (1/3)

Railsでセッションハイジャックを実体験

第3回となる本記事では、Web開発プラットフレームワークとして人気が急上昇中の「Ruby on Rails」（以下、RoR）を目標に、サンプルコードを用いたセッションハイジャック攻撃を行う。

RoRはRuby言語で記述されたWebアプリケーションフレームワークで「DRY（Don't Repeat Yourself：自分で繰り返さない）」を信条の基に開発されている。「scaffolding（足場組み、スタブコードの自動生成）」や「ActiveRecord（ORMライブラリ）」など、アジャイル開発に必要な機能を備えている。

Webアプリケーションに欠かせないHTTPセッション管理機構ももちろん標準で装備しており、初期状態で機能するよう設定されている。現在のWebアプリケーション、特にRoRで開発するようなWebアプリケーションでは、セッション管理が普通に利用されていると考えられるため、デフォルトで動作して当然の機能だといえる。

セッション管理は、ページ間（リクエスト間）でデータを受け渡すだけでなく、ユーザのログイン状態を管理するためにも利用される。このため、セッションを横取りされる「セッションハイジャック」に対する脆弱性があり、他のユーザに成りすますことが可能なWebサイトがあるとすれば、そのサイトは致命的な欠陥を抱えていることになる。

本記事では「セッション固定化（Session Fixation）」と呼ばれる脆弱性を利用してセッションをハイジャックする方法を解説する。

図1：セッションの固定化を利用したセッションハイジャック
（画像をクリックすると別ウィンドウに拡大図を表示します）

セッションの固定化とは?

今回解説する「HTTPプロトコルによるセッション固定化の脆弱性」は、URLベースのセッション管理が原因となっている。セッションの固定化を理解するには「HTTPセッション管理が何故必要か」と「どのように管理されているか」の2つの点に対して知る必要がある。

「HTTPプロトコルはステートレスプロトコルだ」といわれている。HTTPプロトコルではリクエストの送受信が終了するとネットワーク接続はクローズされる。そしてHTTPプロトコル自体はどのユーザからのリクエストであるか区別する仕組みを持たない。

つまり、どのユーザからのリクエストかHTTPプロトコルではまったく関知していないのだ。ログイン状態などを維持するにはアプリケーションが状態を管理しなければならい、それがHTTPセッション管理の実情だ。

RoRのセッション管理機構はPHPと異なり、すでに発行済みのセッションID以外は受け付けない。このため「URLなどからセッションIDを受け入れても安全だ」と誤解され、昨年になるまで修正されなかったのだと思われる。

実際にRoRのURLベースのセッション管理機構を攻撃するには2つのステップが必要になる。実際の攻撃方法は後ほど脆弱性対策と合わせて解説する。 次のページ