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




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

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

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

著者:大垣 靖男

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

RoRの脆弱性を攻撃する

未対策のRoRに表示された「新しく有効なセッションID」を別マシン上のWebブラウザから、URLベースのセッションIDとしてリクエストしてみる。すると、RoRはまったく異なるマシンのWebブラウザからのリクエストであるにも関わらず新しいセッションIDを発行せず、既存のHTTPセッションとして取り扱ってしまう。

何故、このような事が起こったか簡単に解説しよう。

大規模な組織や携帯などでは、利用するプロキシサーバがリクエストごとに異なるのは普通のことだ。このため、当然別のIPアドレスからのリクエストであっても「セッションIDが同じ」であれば「リクエストしてきたWebブラウザも同じ」ものとして取り扱わなければならないのだ。RoR開発者も当然このような構成を知っているに違いない。

では実際の攻撃は、どのように行われるのだろうか。原理としては、未初期化のセッションIDには新しくセッションIDを発行しているにも関わらず、セッションIDの固定化攻撃が可能になるということになる。理解し辛いかもしれないがわかってしまえば簡単だ。

具体的には、「1)攻撃者が有効なセッションIDを取得する」「2)取得した『有効なセッションID』をURLパラメータとして付加したWebページを公開したり、メールで送信する」「3)被害者が攻撃用URLを記載したWebページやメールのリンクをクリックする」の3ステップで攻撃が成功する。

この脆弱性を使うことで、個人を対象とした場合にはかなり攻撃が行いやすいことが分かる。

なお、有効なセッションIDの取得は自動化できる。例えば、攻撃対象ユーザが攻撃に利用するWebサーバにアクセスした時点でスクリプトを利用すれば、攻撃対象サーバのセッションIDを容易に取得できる。

図3:現実的な脆弱性の攻撃方法
図3:現実的な脆弱性の攻撃方法

脆弱性からアプリケーションを守る

このような古いバージョンのRoRが持つ脆弱性に対処するには、RoR 1.2.6にアップグレードするのが最善の方法だ。しかし、test_controller.rbで設定を変更することでも対応できる。具体的にはtest_controller.rbに記述された「#session :cookie_only => true」のコメントをはずすことで、URLベースのセッションIDを無効にできる。

実際、RoRはURLベースのセッション管理をデフォルトで無効とすることで、この脆弱性に対処している。万が一、RoR 1.2.6にアップグレードしていない場合は各コントローラで設定するのではなく「config/environment.rb」の中で設定することになるだろう。

RoR 1.2.6は、RoR 1.2.4で試みたセッションベースURLの無効化に漏れがあった不具合を修正した状態でリリースされたバージョンだ。「RoR 1.2.5まではアップグレートしているので関係ない」と放置していると攻撃される可能性がある。万が一未対策な場合は早急にアップグレードするかアプリケーション側で対策することをお勧めする。

なお、セキュリティ上のリスクを考慮してRoR 2.0ではURLベースのセッション管理は初期状態で無効となっている。このためRoR 2.0の場合は今回解説した脆弱性の影響は受けない。 タイトルへ戻る




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


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