Ruby on Rails ページ 5 ｜Webシステム開発の株式会社フラッツ

こんにちは。木村です。

今回はRuby On Rails Security Guideの訳 : 2.Sessions 2.6の続きです。

今回は2.7 Session Fixationです。

原文の単語と全く違う言葉に置きかえている場合が多々あります。原文ページと併せて、ご覧下さい。気になる箇所や間違っている箇所があれば、どうかご指摘下さい。

では、以下訳です。

2.7 Session Fixation

- ユーザのセッションIDを盗むのではなく、攻撃者が知っているIDでセッションIDをフィックスする可能性があります。これをsession fixationと呼びます。

【Session Fixation攻撃イメージ図(原文ページをご覧ください)】

この攻撃は攻撃者が知っているIDでユーザのセッションIDを固定しつつ、ユーザのブラウザにこのIDを強制的に使用させることに重点を置きます。従って、それ以後はセッションIDを盗む必要性がありません。どの様にこの攻撃が働くかは次の通りです。

1. 攻撃者が有効なセッションIDを生成する。
   セッションを固定したいWebアプリケーションのログインページを読み込み、レスポンスからクッキーのセッションIDを取り出します(図の1と2を参照)
2. 攻撃者はできる限りセッションを維持します。
   例えば20分毎に切れるような期限切れが近いセッションは、攻撃のための時間が非常に少なくなります。それゆえに、攻撃者はセッションを維持させるために、時々Webアプリケーションにアクセスします。
3. 攻撃者はユーザのブラウザにこのセッションIDを強制的に使用させます。(図の3を参照)
   別のドメインのクッキーを変えることはできないので(生成元同一性のため)、攻撃者はターゲットのWebアプリケーションのドメインでJavaScriptを実行しなければなりません。XSSによりアプリケーションにJavaScriptコードを埋め込むことで、この攻撃を実行します。(例)
   <script>document.cookie=
   "_session_id=16d5b78abb28e3d6206b60f22a03c8d9";</script>
   XSSとインジェクションについては後の章を読んでください。
4. 攻撃者はユーザをJavaScriptコードを埋め込んだページにおびき出します。
   ページを見ることによって、被害者のブラウザはセッションIDを仕掛けられたIDに変更します。
5. 新しい仕掛けられたセッションは未使用のため、Webアプリケーションはユーザに認証を求めます。
6. その時点で、被害者と攻撃者は同じセッションでWebアプリケーションを共用することになります。
   つまり、セッションが有効になり、被害者は攻撃に気づかなかったということです。

次回は2.8 Session Fixation – Countermeasuresです。

こんにちは。木村です。

今回はRuby On Rails Security Guideの訳 : 2.Sessions 2.4 – 2.5の続きです。随分間が空いてしまってすみません・・・。

今回は2.6 Replay Attacks for CookieStore Sessionsです。

原文の単語と全く違う言葉に置きかえている場合が多々あります。原文ページと併せて、ご覧下さい。気になる箇所や間違っている箇所があれば、どうかご指摘下さい。

では、以下訳です。

2.6 CookieStoreセッションへのリプレイアタック

- CookieStoreを使用する上で知っておかなければならない攻撃の1つの種類にリプレイアッタクがあります。

リプレイアタックは以下のように動作します。

• ユーザは合計額がセッションに保存されたクレジットを受けとる。(これは悪い方法ですが、デモンストレーションの目的で例にしています)
• ユーザが何か買う。
• 低くなったクレジットをセッションに保存する。
• ユーザのダークサイドが最初の段階のクッキーを取り出させ(ユーザがコピーしていたもの)、ブラウザの現在のクッキーと置き換えさせる。
• ユーザにクレジットが戻ってくる。

セッションにnonce値(ランダムな数字)を含めることで、リプレイアッタクを解決できます。nonce値は1回だけ有効で、サーバは全ての有効なnonce値を把握しなければなりません。ましてや、もし、いくつもアプリケーションサーバ(mongrels ※1)があるならば、なおさら複雑になります。nonce値をデータベースのテーブルに保存することは、CookieStoreの目的(データベースへのアクセスを避けること)を完全に無意味なものにするでしょう。

リプレイアタックに対抗する一番よい解決方法は、この種類のデータをセッションに保存せず、データベースに保存することです。ここで挙げた例では、クレジットをデータベースに保存し、ログインユーザIDをセッションに保存します。

※1 Mongrelという名前のWebサーバアプリケーションです。

次回は2.7 Session Fixationです。