デフォルトでは、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 にはテンポラリファイルを作成するさまざまなメカニズムが数多く存在します。これらの関数の多くは、さまざまな形態の攻撃に対して脆弱です。
例 1: 次のコードは、ネットワークから収集された中間データを、処理するまで格納するテンポラリファイルを使用しています。

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

ソフトウェアシステムに対する重大な攻撃は、ほぼすべて、プログラマにとって想定外の事態から始まります。実際に攻撃を受けた後にはプログラマの仮定は脆弱で根拠薄弱に思われます。しかし、攻撃以前は多くのプログラマがその仮定を情熱的に弁護するものです。

コードの中に簡単に見つかる 2 つの疑わしい仮定は、「このメソッドは決して失敗しない」、および「このメソッドコールが失敗するかどうかは重要ではない」です。プログラマが条件を無視する場合、プログラマはそれらの仮定のいずれかに基づいて作業していると暗黙のうちに認めています。

例 1: 次のコードの例では、CICS トランザクション中に発生する可能性のあるエラー条件が無視されます。

...
EXEC CICS
  INGNORE CONDITION ERROR
END-EXEC.
...

万が一トランザクションがこのエラー条件で失敗した場合、あたかも何もエラーが発生していないかのように、プログラムの実行が続行されます。プログラムは特別な状況を示す証拠を記録しないため、プログラムの動作を後で調べようとする場合に苛立ちを感じることもあります。

ソフトウェアシステムに対する重大な攻撃は、ほぼすべて、プログラマにとって想定外の事態から始まります。実際に攻撃を受けた後にはプログラマの仮定は脆弱で根拠薄弱に思われます。しかし、攻撃以前は多くのプログラマがその仮定を情熱的に弁護するものです。

コードの中に簡単に見つかる 2 つの疑わしい仮定は、「このメソッドは決して失敗しない」、および「このメソッドコールが失敗するかどうかは重要ではない」です。プログラマが例外を無視する場合、プログラマはそれらの仮定のいずれかに基づいて作業していると暗黙のうちに認めています。

例 1: 次のコード部分では、doExchange() で稀に発生する例外を無視しています。

try {
  doExchange();
}
catch (RareException e) {
  // this can never happen
}

RareException が発生しても、プログラムは異常が発生しなかったかのように継続して実行されます。プログラムは特別な状況を示す証拠を記録しないため、プログラムの動作を後で調べようとする場合に苛立ちを感じることもあります。

ソフトウェアシステムに対する重大な攻撃は、ほぼすべて、プログラマにとって想定外の事態から始まります。実際に攻撃を受けた後にはプログラマの仮定は脆弱で根拠薄弱に思われます。しかし、攻撃以前は多くのプログラマがその仮定を情熱的に弁護するものです。

コードの中に簡単に見つかる 2 つの疑わしい仮定は、「この関数コールは決して失敗しない」、および「このコールが失敗するかどうかは重要ではない」です。プログラマが例外を無視する場合、プログラマはそれらの仮定のいずれかに基づいて作業していると暗黙のうちに認めています。

例 1: 次のコードは、insert ステートメントの実行中に発生する可能性のあるいくつかの例外を無視しています。

PROCEDURE do_it_all
IS
BEGIN
  BEGIN
    INSERT INTO table1 VALUES(...);
    COMMIT;
  EXCEPTION
    WHEN OTHERS THEN NULL;
  END;
END do_it_all;

テーブルが存在していないか、必須の値が指定されていないか、またはそれ以外の理由から、例外が発生する可能性があります。障害が発生した場合、プロシージャーはその障害を報告することも、どのタイプの障害が発生したのかを記録することもしないため、ユーザーは問題を知りようがありません。

複数の catch ブロックは繰り返しになりますが、Exception などの高レベルクラスをキャッチすることで catch ブロックを「簡略化」すると、特別な処理が必要な例外やプログラムのこの時点ではキャッチすべきでない例外が不明確になります。キャッチする例外があまりに広範にわたると、本質的に Java の入力例外の目的にそぐわなくなるだけでなく、プログラムが新しいタイプの例外を発生させるようになり特に危険になります。新しい例外タイプは特に注意されません。

例 1: 以下のコード引用は 3 種類の例外を同じように扱います。

  try {
    doExchange();
  }
  catch (IOException e) {
    logger.error("doExchange failed", e);
  }
  catch (InvocationTargetException e) {
    logger.error("doExchange failed", e);
  }
  catch (SQLException e) {
    logger.error("doExchange failed", e);
  }

一見して、次のようにこれらの例外を単一の catch ブロックで扱うことが望ましいように思われます。

  try {
    doExchange();
  }
  catch (Exception e) {
    logger.error("doExchange failed", e);
  }

しかし、別の方法で扱うべき新しいタイプの例外を発生させるように doExchange() を変更した場合、広範囲な catch ブロックのためにコンパイラは状況を指摘することができません。さらに、プログラマの意図に反して、新しい catch ブロックは ClassCastException や NullPointerException などの RuntimeException からの例外も扱うようになります。

Exception または Throwable を発生させるメソッドの宣言は、コールする側がエラー処理やリカバリ作業を行うことを困難にします。Java の例外メカニズムは、呼び出し側が不正な内容を予期し特別な事情に対応するコードを書きやすいように設定されています。メソッドが一般形式の例外を発生することを宣言すると、このシステムを無効にします。

例 1: 次のメソッドは 3 種類の例外を発生します。

public void doExchange()
  throws IOException, InvocationTargetException,
         SQLException {
  ...
}

次のように書くと整然としているように思われますが、

public void doExchange()
  throws Exception {
  ...
}

発生する例外をコールする側が理解して処理しにくくなります。さらに、doExchange() の今後の版で、従来の例外とは異なる方法で扱うべき新しいタイプの例外が導入された場合、この要件の遵守が困難になります。

プログラマは一般に次の 3 つの状況で NullPointerException をキャッチします。

1.プログラムが NULL ポインタ間接参照を含む場合。この結果発生した例外のキャッチは根本問題を解決するより簡単です。

2. プログラムがエラー状況を知らせるために明示的に NullPointerException を発生させる場合。

3. コードが、テスト中のクラスに予期しない入力をするテストハーネスの一部である場合。

これらの 3 つの状況のうち、認められるのは 3 番目の状況だけです。

例 1: 次のコードは NullPointerException を誤ってキャッチしています。

  try {
    mysteryMethod();
  }
  catch (NullPointerException npe) {
  }

プログラマは一般に次の 3 つの状況で NullReferenceException をキャッチします。

1.プログラムが NULL ポインタ間接参照を含む場合。この結果発生した例外のキャッチは根本問題を解決するより簡単です。

2. プログラムがエラー状況を知らせるために明示的に NullReferenceException を発生させる場合。

3. コードが、テスト中のクラスに予期しない入力をするテストハーネスの一部である場合。

これらの 3 つの状況のうち、認められるのは 3 番目の状況だけです。

例 1: 次のコードは NullReferenceException を誤ってキャッチしています。

  try {
    MysteryMethod();
  }
  catch (NullReferenceException npe) {
  }

finally ブロック内部に return ステートメントがあると、try ブロックで発生する例外が破棄される原因となります。

例 1: 次のコードでは、doMagic への 2 番目のコールによって発生する MagicException、およびそのとき渡される true は、コールする側には渡りません。finally ブロック内の return ステートメントは、例外を破棄させます。

public class MagicTrick {

public static class MagicException extends Exception { }

public static void main(String[] args) {

  System.out.println("Watch as this magical code makes an " +
                     "exception disappear before your very eyes!");

  System.out.println("First, the kind of exception handling " +
                     "you're used to:");
  try {
    doMagic(false);
  } catch (MagicException e) {
    // An exception will be caught here
    e.printStackTrace();
  }

  System.out.println("Now, the magic:");
  try {
    doMagic(true);
  } catch (MagicException e) {
    // No exception caught here, the finally block ate it
    e.printStackTrace();
  }
  System.out.println("tada!");
}

public static void doMagic(boolean returnFromFinally)
throws MagicException {

  try {
    throw new MagicException();
  }
  finally {
    if (returnFromFinally) {
      return;
    }
  }
}

}

アプリケーションが非同期で終了された後に、クリーンアップを実行する必要がある場合にのみ、ThreadDeath エラーをキャッチする必要があります。ThreadDeath エラーがキャッチされる場合、スレッドが実際に終了するように、再度スローすることが重要です。ThreadDeath をスローする目的は、スレッドを停止することです。ThreadDeath が受け入れられると、スレッドの停止が妨げられる可能性があります。ThreadDeath をスローしたユーザーは、スレッドは停止していると考えるため、そのまま動作する場合、予期せぬ動作が引き起こされる可能性があります。

例 1: 次のコードは、ThreadDeath を捕捉していますが、再度スローしていません。

try
{
//some code
}
catch(ThreadDeath td)
{
//clean up code
}

Java では、finally ブロックは必ず、対応する try-catch ブロックの後に実行され、ファイルハンドルやデータベースカーソルなどの割り当てられているリソースを解放する目的でも使用される場合があります。finally ブロックで例外を発生させると、通常のプログラム実行が妨げられるため、重要なクリーンアップコードが省略される可能性があります。

例 1: 次のコードでは、FileNotFoundException がスローされたときに、stmt.close() のコールが省略されています。

public void processTransaction(Connection conn) throws FileNotFoundException
{
    FileInputStream fis = null;
    Statement stmt = null;
    try
    {
        stmt = conn.createStatement();
        fis = new FileInputStream("badFile.txt");
        ...
    }
    catch (FileNotFoundException fe)
    {
        log("File not found.");
    }
    catch (SQLException se)
    {
        //handle error
    }
    finally
    {
        if (fis == null)
        {
            throw new FileNotFoundException();
        }

        if (stmt != null)
        {
            try
            {
                stmt.close();
            }
            catch (SQLException e)
            {
                log(e);
            }
        }
    }
}

次の場合に、Unhandled Exception の脆弱性が発生します。

1. 例外が発生する。

2. 現在のページを抜ける前に、この例外が適切に処理されない。

ソフトウェアシステムに対する重大な攻撃は、ほぼすべて、プログラマにとって想定外の事態から始まります。実際に攻撃を受けた後にはプログラマの仮定は脆弱で根拠薄弱に思われます。しかし、攻撃以前は多くのプログラマがその仮定を情熱的に弁護するものです。

コードの中に簡単に見つかる 2 つの疑わしい仮定は、「この操作は決して失敗しない」、および「この操作が失敗するかどうかは重要ではない」です。プログラマが操作で発生する可能性のある例外を認識できない場合、プログラマはそれらの仮定のいずれかに基づいて作業していると暗黙のうちに認めています。