RoamingFolder プロパティおよび RoamingSettings プロパティは、ローミング アプリのデータストアのコンテナを取得します。このコンテナは、複数デバイス間でのデータの共有に使用することができます。ローミング アプリのデータストアに格納されているオブジェクトに対する読み書きにより、危険にさらされるリスクが高まります。その対象は、ローミング アプリのデータストアを使用してこれらのオブジェクトを共有するデータ、アプリケーション、およびシステムの機密性、完全性、および可用性です。

開発者は、まず、必要な技術制御を実装してからこの機能を使用する必要があります。

シグナルハンドラとしてインストールされた関数が再入可能ではない場合、つまり、内部状態を維持するまたは内部状態を維持する別の関数をコールする場合に、シグナル処理で Race Condition が発生する場合があります。このような Race Condition は、複数のシグナルを処理するために同じ関数がインストールされている場合にさらに発生しやすくなります。

シグナル処理における Race Condition は以下のような場合に発生しやすくなります。

1. 複数のシグナルについて単一のシグナルハンドラがプログラムによりインストールされる場合。

2. ハンドラがインストールされている 2 つの異なるシグナルが立て続けに到着する場合。この状況では Race Condition がシグナルハンドラで発生します。

例: 次のコードでは、2 つの異なるシグナルについて同一の簡易な再入不能なシグナルハンドラがインストールされています。攻撃者が適切なタイミングでシグナルを送信すると、シグナルハンドラで Double Free の脆弱性が発生します。free() を同じ値で 2 回コールすると、Buffer Overflow が発生する可能性があります。プログラムが free() を同じ引数で 2 回コールすると、プログラムのメモリ管理データ構造が破損します。これにより、プログラムがクラッシュするか、一部の環境では、その後に malloc() を 2 回コールして同じポインタを戻すことになります。malloc() が同じ値を 2 回戻し、その後に攻撃者が、この二重に割り当てられたメモリに書き込まれたデータの制御をプログラムから得た場合、プログラムは Buffer Overflow 攻撃に対して脆弱になります。

void sh(int dummy) {
  ...
  free(global2);
  free(global1);
  ...
}

int main(int argc,char* argv[]) {
  ...
  signal(SIGHUP,sh);
  signal(SIGTERM,sh);
  ...
}

サーブレットがひとつずつ発生することを多くのサーブレット開発者は理解していません。サーブレットのインスタンスはひとつしかなく、異なるスレッドにより同時に処理される複数のリクエストを取り扱うために、ひとつのインスタンスが使用および再使用されます

この誤解の結果、ユーザーが別のユーザーのデータを偶然に参照し得るようなサーブレットメンバーフィールドの使い方を開発者がすることがあります。言い換えるならば、ユーザーデータをサーブレットメンバーフィールドに格納すると、データアクセスの Race Condition となります。

例 1: 以下のサーブレットはメンバーフィールドのリクエストパラメーター値を格納し、後でパラメーター値をレスポンス出力ストリームに返します。

public class GuestBook extends HttpServlet {

   String name;

   protected void doPost (HttpServletRequest req, HttpServletResponse res) {
     name = req.getParameter("name");
     ...
     out.println(name + ", thanks for visiting!");
   }
}

このコードは単一ユーザー環境では問題なく動作しますが、2 人のユーザーがほぼ同時にサーブレットにアクセスすると、2 つのリクエストハンドラースレッドが次のようにインターリーブされます。

スレッド 1: assign "Dick" to name
スレッド 2: assign "Jane" to name
スレッド 1: print "Jane, thanks for visiting!"
スレッド 2: print "Jane, thanks for visiting!"

したがって、最初のユーザーに 2 番目のユーザー名を表示します。

データベース接続など、トランザクションに関係するリソースオブジェクトは、一度に 1 つのトランザクションのみと関連付けることができます。そのため、接続をスレッド間で共有してはいけません。また、static フィールドに格納するべきでもありません。詳細については、J2EE 仕様 4.2.3 の項を参照してください。

例 1:

public class ConnectionManager {

private static Connection conn = initDbConn();
...
}

次の場合に 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.com や recipes.example.com のように、多数のアプリケーションが同一の最上位ドメインに存在する場合、1 つのアプリケーションに脆弱性があると、攻撃者はセッション ID が固定化された cookie を設定して、ドメイン example.com 上のあらゆるアプリケーションとの間のすべての通信で使用されるようにできます [2]。

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