RoRの脆弱性を攻撃する

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：現実的な脆弱性の攻撃方法

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

このような古いバージョンの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の場合は今回解説した脆弱性の影響は受けない。