J2EE アプリケーションはアプリケーションの信頼性と性能を向上させるために複数の JVM を使用します。複数の JVM を単一アプリケーションとしてエンドユーザーに見せるため、J2EE コンテナは HttpSession オブジェクトを複数の JVM にわたって複製します。こうすることで、1 つの JVM が利用できなくなった場合でも、アプリケーションを中断させることなく別の JVM が取って代わることができます。

セッションが作業を複製するために、セッションの属性としてアプリケーションが保存する値は Serializable インターフェイスを実装しなければなりません。

例 1: 以下のクラスはセッションに追加されますが、シリアライズ可能なクラスではないため、セッションを複製できなくなります。

public class DataGlob {
   String globName;
   String globValue;

   public void addToSession(HttpSession session) {
     session.setAttribute("glob", this);
   }
}

Web アプリケーションのスレッド管理は J2EE 標準によって禁止されており、エラーが発生する可能性が常に高くなります。スレッドの管理は難しく、アプリケーションコンテナの動作に予測不能な方法で干渉する可能性が高いと言えます。コンテナに干渉しなくとも、スレッド管理は通常、デッドロック、Race Condition、その他の同期エラーなど、検出や診断が難しいバグにつながります。

block.timestamp または block.number に関連付けられた値は通常、時間依存のイベントをトリガーするために開発者が使用しますが、これらの値から得られる時間感覚の多くは、一般的には使用しない方がよいものです。

分散型というブロックチェーンの性質により、ノードはある程度までしか時間を同期できません。block.timestamp の使用は良く言っても信頼性が低く、最悪の場合、メリットに気づいた悪意のあるマイナーがブロックのタイムスタンプを変更する可能性があります。

block.number については、ブロック間の時間 (約 14 秒) を予測することは可能ですが、ブロック時間は一定ではなく、ネットワーク アクティビティに応じて変動する可能性があります。これにより、時間関連の計算において block.number の信頼性が低くなります。

例 1: 次のコードは、block.number を使用して、一定期間後に資金のロックを解除します。

function withdraw() public {
    require(users[msg.sender].amount > 0, 'no amount locked');
    require(block.number >= users[msg.sender].unlockBlock, 'lock period not over');
    uint amount = users[msg.sender].amount;
    users[msg.sender].amount = 0;
    (bool success, ) = msg.sender.call.value(amount)("");
    require(success, 'transfer failed');
}

Node.js を使用すると、開発者は IO にブロックされるイベントにコールバックを割り当てることができます。これによって、コールバックが非同期に実行され、メイン アプリケーションが IO によってブロックされなくなるため、パフォーマンスが向上します。ただし、コールバック内のコードを実行してからでないとコールバックの外側の処理を行えない場合、競合状態を引き起こす可能性があります。

例 1: 次のコードは、認証を行うためにユーザーをデータベースと照合します。

 
...
var authenticated = true; 
...
database_connect.query('SELECT * FROM users WHERE name == ? AND password = ? LIMIT 1', userNameFromUser, passwordFromUser, function(err, results){
  if (!err && results.length > 0){
    authenticated = true;
  }else{
    authenticated = false;
  }
});

if (authenticated){
  //do something privileged stuff
  authenticatedActions();
}else{
  sendUnathenticatedMessage();
}

この例では、バックエンドのデータベースをコールしてログインに使用するユーザーの認証情報を確認し、確認できた場合は変数を true に、そうでない場合は false に設定しています。しかし、コールバックは IO によってブロックされるため、処理が非同期に実行され、if (authenticated) の確認の後に実行される可能性があります。また、デフォルトが true なので、ユーザーが実際に認証されるかどうかにかかわらず if 文が実行されます。

アプリケーションがアプリケーションを共有ストレージからインストールしますが、このストレージには外部ストレージの読み取り/書き込み権限を持つアプリケーションが書き込み可能です。 Race Condition によって、フォルダを監視している悪意のあるアプリケーションはダウンロード済みの APK ファイルを、インストール プロセスで正規の更新の代わりに使用される代替 APK ファイルと交換することができます。

例 1: 次のコードは、アプリケーションを共有ストレージからインストールします。

    Intent intent = new Intent(Intent.ACTION_VIEW);
    intent.setDataAndType(Uri.fromFile(new File(Environment.getExternalStorageDirectory() + "/download/" + "app.apk")), "application/vnd.android.package-archive");
    intent.setFlags(Intent.FLAG_ACTIVITY_NEW_TASK);
    startActivity(intent);

ファイルアクセス Race Condition は TOCTOU (time-of-check, time-of-use) Race Condition とも呼ばれ、以下の場合に発生します。

1. プログラムがファイルのプロパティをチェックする際に、ファイルを名前で参照する場合。

2.後でプログラムは、同じファイル名を使用し、前に確認したプロパティが変更されていないと仮定して、ファイル システム オペレーションを実行します。
例 1: 以下のコードは、setuid root をインストールしたプログラムのものです。このプログラムでは、権限が付与されていないユーザーに代わって特定のファイル操作を行い、アクセス チェックを使用して、現在のユーザーが利用できないはずの操作を、root 権限で行わないようにします。このプログラムでは、access() システム コールを使用して、プログラムを実行している人が指定されたファイルにアクセスする権限を持っているかどうかを確認してから、ファイルを開き、必要な処理を行います。

  if (!access(file,W_OK)) {
    f = fopen(file,"w+");
    operate(f);
    ...
  }
  else {
    fprintf(stderr,"Unable to open file %s.\n",file);
  }

access() のコールは想定どおりに機能し、プログラムの実行者がファイルに書き込むために必要な権限を持っている場合は 0 を戻し、そうでない場合は -1 を戻します。しかし、access() と fopen() はどちらもファイルハンドルではなくファイル名に対して実行されるため、file 変数が fopen() に渡される際にも、access() に渡されたときと同じディスク上のファイルを参照している保証はありません。攻撃者が access() のコール後に file を別のファイルへのシンボリックリンクに置き換えた場合、そのファイルが本来ならば攻撃者が変更できないファイルであっても、プログラムはファイルを root 権限で操作します。プログラムを操作して本来実行できない操作を実行させることにより、攻撃者は昇格した権限を獲得します。

このタイプの脆弱性は、root 権限を持つプログラムに限定されません。本来は攻撃者に許可されていない操作を実行できるアプリケーションはすべて、ターゲットになる可能性があります。

そのような攻撃に対する脆弱性の時間帯は、プロパティがテストされた時点と、ファイルが使用される時点の間の期間です。確認後ただちに使用した場合でも、最新のオペレーティング システムは、プロセスが CPU を明け渡す前に実行されるコードの量について保証していません。攻撃者は、より簡単に悪用するための機会の時間枠を拡張するさまざまなテクニックを持っています。ただし、時間枠が短くても、悪用の試みは、成功するまで単純に何度も繰り返される可能性があります。

例 2: 次のコードはファイルを作成し、ファイルの所有者を変更しています。

    fd = creat(FILE, 0644);  /* Create file */
    if (fd == -1)
        return;
    if (chown(FILE, UID, -1) < 0) {  /* Change file owner */
      ...
    }

このコードは、chown() のコールにより操作されるファイルが creat() のコールにより作成されたファイルと同じであると仮定していますが、必ずしもそうならない場合があります。chown() はファイル名に対して操作され、ファイル ハンドルに対しては操作されないため、攻撃者により、攻撃者が所有しないファイルへのリンクにそのファイルが置き換えられる可能性があります。そのような場合、リンクされたファイルの所有権が chown() のコールによって攻撃者に付与されます。

java.text.Format にあるメソッド parse() および format() には、あるユーザーが別のユーザーのデータを表示できるという Race Condition が含まれています。

例 1: 次のコードは、この設計上の不備がどのようになっているのかを示しています。

public class Common {

    private static SimpleDateFormat dateFormat;
    ...

    public String format(Date date) {
        return dateFormat.format(date);
    }
    ...

    final OtherClass dateFormatAccess=new OtherClass();
    ...

    public void function_running_in_thread1(){
        System.out.println("Time in thread 1 should be 12/31/69 4:00 PM, found: "+ dateFormatAccess.format(new Date(0)));
    }

    public void function_running_in_thread2(){
        System.out.println("Time in thread 2 should be around 12/29/09 6:26 AM, found: "+ dateFormatAccess.format(new Date(System.currentTimeMillis())));
    }
}

このコードは、単一ユーザーの環境では正しく動作しますが、2つのスレッドが同時に実行されると、下記の出力を生成する場合があります。

Time in thread 1 should be 12/31/69 4:00 PM, found: 12/31/69 4:00 PM
Time in thread 2 should be around 12/29/09 6:26 AM, found: 12/31/69 4:00 PM

この場合、format() の実装にある Race Condition のため、最初のスレッドの日付が2つ目のスレッドの出力に表示されています。