界: Time and State

分散型計算とは、時間と状態に関するものです。つまり、複数のコンポーネントが通信するためには、状態を共有しなければならず、そのためには時間がかかります。

ほとんどのプログラマーは、自分の仕事を人であるかのように考えています。彼らは、自分で仕事をしなければならない場合、自分がするのと同じように、1 つのスレッドのコントロールでプログラム全体を実行することを考えます。しかし、最近のコンピュータは、タスクの切り替えが非常に速く、マルチコア、マルチ CPU、分散システムなどでは、2 つのイベントが全く同時に発生することもあります。不具合は、プログラマーが考えたプログラムの実行方法のモデルと、現実に起きていることとのギャップを埋めるために押し寄せます。これらの欠陥は、スレッド、プロセス、時間、および情報の間の予期せぬ相互作用に関連しています。これらの相互作用は、セマフォ、変数、ファイル システムなど、基本的には情報を保存できるあらゆるものを含む共有状態を通じて行われます。

Session Fixation

Abstract
既存のセッション ID がある場合でもそれを無効にせずにユーザーを認証すると、認証済みのセッションを盗む機会を攻撃者に与えることになります。
Explanation
次の場合に Session Fixation の脆弱性が発生します。

1.Web アプリケーションが、既存のセッションを無効にしないでユーザーを認証し、すでにユーザーと関連付けられているセッションを引き続き使用する場合。
2.攻撃者がユーザーに既知のセッション ID を強制的に使用させることができる場合に、このユーザーが認証されると、攻撃者は認証済みセッションにアクセスできます。

Session Fixation の脆弱性の一般的な悪用では、攻撃者は Web アプリケーション上に新しいセッションを作成し、関連したセッション ID を記録します。次に攻撃者はそのセッション ID を使用してサーバーに攻撃対象を認証させ、アクティブなセッションの間、ユーザーのアカウントに攻撃者がアクセスできるようにします。

Spring Security など、新しいセッションの作成時に既存のセッションを自動で無効にするフレームワークもあります。この動作は無効化できますが、アプリケーションはこの攻撃に対して脆弱になります。

例 1: 次の例に示す Spring Security で保護されるアプリケーションのスニペットでは、セッション ID 固定化対策が無効化されています。


<http auto-config="true">
...
<session-management session-fixation-protection="none"/>
</http>


アプリケーションが脆弱であっても、ここで説明する特定の攻撃が成功するかどうかは、監視されていない公共端末へのアクセス、危険に晒されているセッションをアクティブにする能力、公共端末上の脆弱なアプリケーションへのログオンを行う被害者のような、攻撃者に有利に働く数々の要因によります。多くの場合、最初の 2 つの問題は時間をかければ克服できます。公共の端末を使用し、また脆弱なアプリケーションにログインしようとする攻撃対象を発見することも、サイトの認知度が適度に高ければ可能です。サイトがあまり知られていない場合は、公共の端末を使用してアクセスする攻撃対象を発見する確率も、前述した攻撃手段の成功の確率も、それだけ低くなります。

Session Fixation の脆弱性を悪用する際に攻撃者が直面する最大の課題は、攻撃者に既知のセッション ID を使用して脆弱なアプリケーションの認証を受けるように仕向けることです。Example 1 では、攻撃者は明らかに直接的な方法を使用しており、あまり知られていない Web サイトまでには攻撃の手を広げていません。ただし、安心は禁物です。攻撃者はこの攻撃手段の限界をバイパスするための七つ道具を持っています。攻撃者が最も一般的に使用するテクニックは、ターゲット サイトにある Cross-Site Scripting や HTTP レスポンス スプリッティングといった脆弱性を利用することです [1]。攻撃者は攻撃対象を操作して、JavaScript などのコードを攻撃対象のブラウザーに反映するなど悪意あるリクエストを脆弱なアプリケーションに送信するように仕向けて cookie を作成し、攻撃者の支配下にあるセッション ID を再使用させることができます。

指定された URL に関連する最上位のドメインに cookie が関連付けられることが多いため、注意が必要です。bank.example.comrecipes.example.com のように、多数のアプリケーションが同一の最上位ドメインに存在する場合、1 つのアプリケーションに脆弱性があると、攻撃者はセッション ID が固定化された cookie を設定して、ドメイン example.com 上のあらゆるアプリケーションとの間のすべての通信で使用されるようにできます [2]。

他の攻撃手段には、DNS ポイズニングおよび関連したネットワークベースの攻撃があります。この攻撃では、攻撃者は適正なサイトへのリクエストをリダイレクトすることによって、悪意あるサイトにユーザーを誘い込みます。ネットワークベースの攻撃は一般的に、被害者のネットワーク上に物理的に存在することや、ネットワーク上の危険性のあるマシンを制御することで行われます。リモートから攻撃することはより難しくなりますが、重大さを見過ごすわけにはいきません。Apache Tomcatのデフォルト実装などの、それほど安全でないセッション管理メカニズムでは、通常 cookie にあるとされるセッション ID を URL で指定されることも許容されます。この場合、攻撃者は攻撃対象に悪意あるURLを電子メールで送信するだけで、固定されたセッションIDを使用させることができます。
desc.config.java.session_fixation
Abstract
既存のセッション ID がある場合でもそれを無効にせずにユーザーを認証すると、認証済みのセッションを盗む機会を攻撃者に与えることになります。
Explanation
次の場合に Session Fixation の脆弱性が発生します。

1.Web アプリケーションが、既存のセッションを無効にしないでユーザーを認証し、すでにユーザーと関連付けられているセッションを引き続き使用する場合。

2.攻撃者がユーザーに既知のセッション ID を強制的に使用させることができる場合に、このユーザーが認証されると、攻撃者は認証済みセッションにアクセスできます。

Session Fixation の脆弱性の一般的な悪用では、攻撃者は Web アプリケーション上に新しいセッションを作成し、関連したセッション ID を記録します。次に攻撃者はそのセッション ID を使用してサーバーに攻撃対象を認証させ、アクティブなセッションの間、ユーザーのアカウントに攻撃者がアクセスできるようにします。

例 1: 次のコードでは、セッション cookie の use_strict_mode 属性を無効にしています。

session.use_strict_mode=0
References
[1] D. Whalen The Unofficial Cookie FAQ
[2] The PHP Group PHP Use Strict Mode Documentation
desc.config.php.session_fixation