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




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

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

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

著者:大垣 靖男

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

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:セッションの固定化を利用したセッションハイジャック
図1:セッションの固定化を利用したセッションハイジャック
(画像をクリックすると別ウィンドウに拡大図を表示します)

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

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

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

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

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

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




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


この記事の評価をお聞かせください
ボタンをクリックしますとウインドウが開きます。

INDEX
第3回:Railsでセッションハイジャックを実体験
Railsでセッションハイジャックを実体験
  RoR環境の準備
  RoRの脆弱性を攻撃する
【セキュリティ最前線】セキュリティホールをついて遊ぶ
第1回 体当たりで学ぶセキュリティ!
第2回 PHPのSQLインジェクションを実体験
第3回 Railsでセッションハイジャックを実体験