デフォルトでは、ASP.NET サーバーでは HttpSessionState オブジェクト、その属性、および参照するすべてのオブジェクトがメモリに保存されます。この処理モデルでは、アクティブセッションの状態が 1 台のマシンのシステムメモリに保存できる範囲に制限されます。これらの制限を取り除き、容量を拡張するために、複数のサーバーに対して永続的なセッション状態情報が設定される場合がよくあります。これにより容量が拡張され複数のマシン間における複製が許可されるため、全体的なパフォーマンスが向上します。セッション状態を保持するために、サーバーは HttpSessionState オブジェクトをシリアライズする必要があり、このオブジェクトをシリアライズするためには、保存されるすべてのオブジェクトがシリアライズ可能である必要があります。

セッションが正しくシリアライズされるために、セッションの属性としてアプリケーションが保存するすべてのオブジェクトで [Serializable] 属性を宣言する必要があります。さらに、オブジェクトで独自のシリアライズメソッドが必要となる場合には、ISerializable インターフェイスを実装する必要があります。

例 1: 次のクラスは自分自身をセッションに追加しますが、シリアライズ可能ではないため、セッションを正しくシリアライズすることはできません。

public class DataGlob {
   String GlobName;
   String GlobValue;

   public void AddToSession(HttpSessionState session) {
     session["glob"] = this;
   }
}

複数のスレッドが、リソースをロックしようとしている場合、ロックを保持しながら sleep() をコールすると、他のすべてのスレッドがそのリソースが解放されるのを待機するため、パフォーマンスが低下しデッドロックが発生する可能性があります。

例 1: 次のコードは、ロックを保持しながら sleep() をコールしています。

ReentrantLock rl = new ReentrantLock();
...
rl.lock();
Thread.sleep(500);
...
rl.unlock();

これまでも才能ある数多くの個人がかなりの時間を費やし、性能を向上させるために Double-Checked Locking を機能させようと取り組んできました。しかし、一度も成功したことはありません。

例 1: 一見して、次のコードのビットは不必要な同期化を回避しながらスレッドの安全を実現しているように思われます。

if (fitz == null) {
  synchronized (this) {
    if (fitz == null) {
      fitz = new Fitzer();
    }
  }
}
return fitz;

プログラマは、Fitzer() オブジェクトが 1 つのみ割り当てられていることを保証したいと考えますが、このコードのコールのたびに同期化させるコストをかけたくはありません。この用法は Double-Checked Locking として知られます。

残念ながら、うまく機能せず、複数の Fitzer() オブジェクトが割り当てられます。詳細は「Double-Checked Locking is Broken」宣言を参照してください [1]。

あるシグナルがミューテックスを待機している他のスレッドにシグナルを送信した後、別のスレッドが実行を開始できるようにするためには、pthread_mutex_unlock() をコールしてミューテックスをアンロックする必要がありますシグナルを送信しているスレッドがミューテックスをアンロックできない場合は、2 番目のスレッドにある pthread_cond_wait() コールは返されず、スレッドは実行されません。

例 1: 次のコードは、pthread_cond_signal() をコールしてミューテックスを待機している他のスレッドにシグナルを送信していますが、他のスレッドが待機しているミューテックスのアンロックに失敗しています。

   ...
   pthread_mutex_lock(&count_mutex);

   // Signal waiting thread
   pthread_cond_signal(&count_threshold_cv);
   ...

アプリケーションはテンポラリファイルを非常に頻繁に必要とするため、C ライブラリと Windows(R) API にはテンポラリファイルを作成するさまざまなメカニズムが数多く存在します。これらの関数の多くは、さまざまな形態の攻撃に対して脆弱です。
例: 次のコードは、ネットワークから収集された中間データを、処理するまで格納するテンポラリファイルを使用しています。

...
if (tmpnam_r(filename)){
	FILE* tmp = fopen(filename,"wb+");
	while((recv(sock,recvbuf,DATA_SIZE, 0) > 0)&&(amt!=0))
		amt = fwrite(recvbuf,1,DATA_SIZE,tmp);
}
...

このコードは本来、平凡なコードですが、安全でないメソッドに依存してテンポラリファイルを作成するため、さまざまな攻撃に対して脆弱です。この関数などにより導入される脆弱性について、以降で説明します。テンポラリファイルの作成と関係がある最も顕著なセキュリティ上の問題が UNIX ベースのオペレーティングシステムで発生していますが、Windows アプリケーションにも同様のリスクがあります。このセクションでは、UNIX および Windows の両方のシステムにおけるテンポラリファイルの作成について説明します。

メソッドと動作はシステムにより異なりますが、それぞれで発生する基本的なリスクはほぼ一定です。安全なコア言語関数と、テンポラリファイルの作成に関する安全な手法については「Recommendations」セクションを参照してください。

テンポラリファイルの作成を支援するよう設計された関数は、単にファイル名を提供するだけか、または実際に新しいファイルを開くかどうかによって 2 つ のグループに分類することができます。

グループ 1 - 「一意の」ファイル名:

C ライブラリや WinAPI の最初のグループは、新しいテンポラリファイルに対して一意のファイル名を生成し、テンポラリファイルの作成処理を支援します。このテンポラリファイルをプログラムが開きます。このグループに含まれるのは、tmpnam()、tempnam()、mktemp()などの C ライブラリ関数と、先頭に _ (アンダースコア) が付けられた、それぞれに対応する C++ 関数、および Windows API に属する GetTempFileName() 関数です。このグループの関数は、選択されたファイル名の Race Condition の脆弱性があります。関数は、ファイル名が選択されたときに一意であることを保証しますが、ファイルの選択後、アプリケーションがファイルを開こうと試みる前に別のプロセスまたは攻撃者が同一の名前を持つファイルを作成するのを阻止するメカニズムがありません。同じ関数への別のコールによって発生する正当な衝突の危険のほかに、攻撃者が悪意ある衝突を作成する可能性も十分あります。これらの関数によって生成されたファイル名が十分にランダムでなく、推測が難しくないためです。

選択された名前のファイルが作成されると、ファイルの開き方に応じて、既存のコンテンツまたはファイルのアクセス許可は変更されないままとなります。ファイルの既存のコンテンツが悪意ある性質のものである場合、アプリケーションがテンポラリファイルからデータを読み戻す際に、攻撃者がアプリケーションに危険なデータを挿入できる可能性があります。攻撃者が事前にアクセス許可を緩くしたファイルを作成した場合、アプリケーションによりテンポラリファイルに格納されたデータに対して攻撃者はアクセス、変更、破壊を行うことができます。UNIX ベースのシステムの場合、攻撃者は事前に別の重要なファイルへのリンクとしてファイルを作成しておくことで、さらに露見しにくい攻撃が可能です。この場合、アプリケーションがデータを切り詰めたりファイルに書き込んだりすると、知らずに攻撃者の意図に沿って損傷をもたらす操作を実行することになる可能性があります。昇格した許可でプログラムが動作している場合、これは特に深刻な脅威となります。

最後に、最良のケースでは、O_CREAT フラグや O_EXCL フラグを使用した open() のコールや、CREATE_NEW 属性を使用した CreateFile() のコールでファイルが開かれるのは、ファイルが既に存在する場合に失敗するため、前述のタイプの攻撃は阻止されます。ただし、攻撃者が一連のテンポラリファイル名を正確に予測できる場合、アプリケーションは必要とするテンポラリストレージを開こうとしても阻止され、Denial of Service (DoS) 攻撃が発生する可能性があります。これらの関数によって生成されたファイル名の選択に使用されているランダム度が小さければ、このタイプの攻撃を準備するのは容易です。

グループ 2 - 「一意の」ファイル:

C ライブラリ関数の 2 番目のグループは、一意のファイル名を生成するだけではなく、そのファイルを開くことによって、テンポラリファイルに関連するセキュリティ上の問題の一部を解決しようと試みます。このグループに含まれるのは、tmpfile() などの C ライブラリ関数と、先頭に _ (アンダースコア) が付けられた、それに対応する C++ 関数、および多少動作が優れている C ライブラリ関数 mkstemp() です。

tmpfile() スタイル関数は一意のファイル名を作成して、"wb+" フラグが渡された場合の fopen() と同じ方法、つまり読み書きモードでバイナリ ファイルとしてそのファイルを開きます。ファイルが既に存在する場合、tmpfile() により、サイズがゼロに切り詰められます。これは、一意であるはずのファイル名を選択してから、選択されたファイルをその後で開くまでの間に存在する Race Condition に関する、前述したセキュリティ上の懸念を緩和しようとするものです。ただし、この動作は関数のセキュリティ上の問題を明確に解決するわけではありません。まず、攻撃者は事前にアクセス許可を緩くしたファイルを作成でき、その許可が tmpfile() により開かれるファイルによって変更される可能性はあまりありません。さらに、UNIX ベースのシステムの場合、攻撃者がファイルを別の重要なファイルへのリンクとして事前に作成すると、アプリケーションは昇格した許可を使用してそのファイルを切り詰める可能性があり、結果的に攻撃者の意図した損傷を与えます。最後に、tmpfile() が実際に新しいファイルを作成する場合、そのファイルに適用されるアクセス許可はオペレーティングシステムにより異なります。つまり、攻撃者が事前にファイル名を予測できない場合も、アプリケーションデータは脆弱な状態に保たれる可能性があります。

最後に、mkstemp() は、テンポラリファイルを作成する上で十分に安全性が確保された方法です。ユーザーが提供したファイル名テンプレートに基づき、ランダムに生成した一連の文字を組み合わせて一意のファイルを作成して開こうとします。ファイルを作成できなかった場合は、失敗して -1 を戻します。最近のシステムでは、ファイルはモード 0600 で開かれます。つまり、ユーザーがアクセス許可を明示的に変更しない限り、ファイルは改竄に対して安全です。しかし、mkstemp() は予測可能なファイル名が使用されているため攻撃されやすく、攻撃者が使用されるファイル名を予測して事前に作成することで mkstemp() の失敗を引き起こした場合、アプリケーションは Denial of Service 攻撃にさらされる可能性があります。

セッションが開いている時間が長ければ、それだけ、ユーザーアカウントが侵害される機会が長くなります。セッションがアクティブになっていると、攻撃者は、ユーザーのパスワードに Brute-Force 攻撃を仕掛けたり、ユーザーのワイヤレス暗号鍵を解読したり、あるいは開いているブラウザからセッションを乗っ取ったりできるようになる可能性があります。また、セッションタイムアウトを長くしているとメモリが解放されず、大量のセッションが作成される場合に Denial of Service となる場合があります。

例 1: 次の例では、コードが最大非アクティブ間隔に負の値を設定しており、セッションが永続的にアクティブ状態になります。

...
HttpSession sesssion = request.getSession(true);
sesssion.setMaxInactiveInterval(-1);
...

Web アプリケーションでアプリケーションコンテナをシャットダウンすることは決していい方法ではありません。終了メソッドのコールは、おそらく Leftover Debug Code または非 J2EE アプリケーションからインポートされたコードの一部です。

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、その他の同期エラーなど、検出や診断が難しいバグにつながります。

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);

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つ目のスレッドの出力に表示されています。

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を使用させることができます。