TOP情報セキュリティ> 【セキュリティ最前線】セキュリティホールをついて遊ぶ> 第3回:Railsでセッションハイジャックを実体験 (2/3)

【セキュリティ最前線】セキュリティホールをついて遊ぶ

【セキュリティ最前線】
セキュリティホールをついて遊ぶ

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

著者:大垣 靖男

公開日:2008/1/25(金)

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(下)
図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下)。 次のページ




大垣靖男(OHGAKI, Yasuo)
著者プロフィール
大垣靖男(OHGAKI, Yasuo)
University of Denver卒。同校にてコンピュータサイエンスとビジネスを学ぶ。株式会社シーエーシーを経て、エレクトロニック・サービス・イニシアチブ有限会社を設立。Linuxはバージョン0.9xの黎明期から利用してるが、オープンソースシステム開発やコミュニティへの参加はエレクトロニック・サービス・イニシアチブ設立後から。PHPプロジェクトのPostgreSQLモジュールのメンテナ、日本PostgreSQLユーザ会の四国地域での活動等を担当している。


INDEX
第3回:Railsでセッションハイジャックを実体験
  Railsでセッションハイジャックを実体験
RoR環境の準備
  RoRの脆弱性を攻撃する