RoR環境の準備

今回の記事を執筆するにあたって、RoR 1.2.2とRoR 1.2.6の2つのバージョンを用意した。RoR 1.2.6よりも古いバージョンであるRoR 1.2.2にはURLベースセッションを利用したセッションの固定化の脆弱性があり、攻撃が可能だ。なお、RoRのインストールは紙面の都合上解説しないため、環境構築に関してはRoRのマニュアルなどを参照してほしい。

実験は「実際に攻撃を行う」ことに主眼を置かず、「なぜ攻撃に脆弱になるか」について理解しやすくした非常に簡単なサンプルコードで行っていく。サンプルの作成は非常に簡単だ。

まず「rails vuln」コマンドで、実験用のプロジェクトを作成する。続いて「cd vuln」および「ruby script/generate controller test」コマンドで、コントローラ「app/contollers/test_controller.rb」を作成する。

このコントローラを編集し、リスト1の内容を含めた空のindexアクションを作成する。最後にindexアクション用のテンプレートとしてリスト2の内容を記述した「app/views/test/index.rhtml」を作成すれば準備は完了だ。

この2つのファイルを利用し、脆弱性があるRoR 1.2.2と最新版のRoR 1.2.6の両環境を構築する。それぞれの環境で「ruby script/server」コマンドを実行すれば、「http://localhost:3000/」のURLにアクセスすることで、RoRのデフォルトページが表示される。

なお、テストにはクッキーを無効にしたWebブラウザを用意してほしい。これは、クッキーがセッションに利用されると混乱の元となるためだ。ただし、脆弱性を持ったRoRに対しての攻撃は、クッキーの無効／有効に関係なく行うことができる。

リスト1：app/contollers/test_controller.rbの内容

class TestController < ApplicationController
   #session :cookie_only => true
    def index
    end
end


リスト2：app/views/test/index.rhtmlの内容

<%= debug session %>


図2：対策済みのRoR（上）と未対策のRoR（下）
（画像をクリックすると別ウィンドウに拡大図を表示します）

脆弱性を確認する

脆弱性の確認は簡単だ。脆弱性があるRoRと脆弱性が修正済みのRoR、両方ページのテスト用コントローラにセッションIDをURLに指定してアクセスすると、違いがはっきりとあらわれる。例えば、「http://localhost:3000/test/?_test_session_id=09595e50feb3b7ed8328c8e08c3a3f2c」のようなURLでアクセスしてみよう。

対策済みのRoRはエラーメッセージが表示された（図2上）。これは対策済みのRoRはクッキーのみをセッション管理に利用できるように設定されており、URLのセッションIDを受け入れないために発生したエラーだ。

未対策のRialsでは有効でない（セッションIDがセッションデータベースに登録されていない）セッションIDであり、新たなセッションIDが生成された事がわかる（図2下）。 次のページ