safe_mode が有効に設定されていると、PHP safe_mode_exec_dir オプションによって PHP は指定されているディレクトリからのみコマンドを実行できるように制限されます。safe_mode_exec_dir エントリが欠如していてもセキュリティ上の脆弱性が発生する訳ではありませんが、制限が緩くなるため、攻撃者がほかの脆弱性と組み合わせてより危険な悪用方法を生み出す可能性があります。

open_basedir 設定オプションが有効に設定されていると、php.ini で指定されているディレクトリツリー以外の場所にあるファイルを PHP プログラムが操作できないようにします。作業ディレクトリが . で指定されている場合、攻撃者が chdir() を使用して変更する可能性があります。

open_basedir オプションはセキュリティにとって全面的に好ましいものではありますが、その実装においては、状況次第で攻撃者が制限を回避できてしまう Race Condition が悩みの種となります [2]。TOCTOU (time-of-check, time-of-use) Race Condition は、PHP によってアクセス許可がチェックされるタイミングとファイルが開かれるタイミングの間で発生します。他の言語における File System の Race Condition の場合と同様で、この Race Condition により、攻撃者が Access Control チェックに合格するファイルへのシムリンクの代わりに本来であればそのチェックで不合格となる別のシムリンクを配置して、保護されているファイルにアクセスする可能性があります。

このような攻撃に対する脆弱性は、アクセスチェックの実行時とファイルのオープン時との間に発生しやすくなります。コールが立て続けに実行される場合でも、このプロセスが CPU を解放するまでに実行されるコードの数量について、最近のオペレーティングシステムでは保証されていません。攻撃者は、悪用を容易にするため、さまざまなテクニックで攻撃に利用可能な期間を延長しようとします。短期間の場合でも、成功するまで、悪用の試行をただ繰り返すという方法があります。

register_globals オプションが有効に設定されていると、PHP によってすべての EGPCS (環境、GET、POST、cookie、サーバー) 変数がグローバルに登録されるため、任意の PHP プログラムの任意のスコープにおいてこれらの変数にアクセスできます。このオプションを使用すると、プログラマは依存している値の出所を知らないままプログラムを記述してしまいやすくなります。その結果、悪意のない環境においては予期せぬ動作を引き起こす可能性があります。また、悪意のある環境においては攻撃者に攻撃の機会を与えてしまう可能性があります。register_globals がもたらす可能性のあるセキュリティ上の脅威を受け、このオプションは PHP 4.2.0 ではデフォルトで無効に設定されています。また、PHP 6 では廃止予定であるか削除済みです。

例 1: 次のコードは、クロスサイト スクリプト攻撃に対して脆弱です。プログラマは、$username の値はサーバーで制御されているセッションに由来していると想定しますが、攻撃者は代わりにリクエスト パラメーターとして $username に悪意ある値を指定できます。register_globals が有効に設定されている場合、攻撃者が送信した悪意ある値はこのコードによって生成された動的な HTML コンテンツに含められます。

<?php
if (isset($username)) {
    echo "Hello <b>$username</b>";
} else {
    echo "Hello <b>Guest</b><br />";
    echo "Would you like to login?";

}
?>

safe_mode オプションは、PHP の最も重要なセキュリティ機能の 1 つです。safe_mode が無効に設定されている場合、PHP は呼び出しを実行したユーザー (通常は権限を持つユーザー) の権限でファイルを操作します。PHP で safe_mode を無効に設定してもセキュリティ上の脆弱性は発生しませんが、制限が緩くなるため、攻撃者がほかの脆弱性と組み合わせてより危険な悪用方法を生み出す可能性があります。

session.use_trans_sid が有効に設定されていると、PHP は URL でセッション ID を渡すようになるため、攻撃者がアクティブセッションを乗っ取ったり、すでに攻撃者に制御されている既存のセッションをユーザーが使用するように仕組んだりすることが非常に容易になります。

URL で渡されるパラメーターはブラウザの履歴、お気に入り、ログファイルを始めとする非常に分かりやすい場所で使用されるため、POST パラメーターや cookie の値よりも目立ちます。攻撃者がシステムのアクティブセッションの機密セッション ID を知り得た場合、ユーザーのセッションを乗っ取るためにそのセッション ID をプログラムに戻す可能性があります。

URL でセッション ID が明らかになると、セッション乗っ取りのほかに Session Fixation 攻撃も可能となります。Session Fixation の脆弱性の一般的な悪用では、攻撃者は Web アプリケーション上に新しいセッションを作成し、関連したセッション ID を記録します。次に攻撃者はそのセッション ID を使用してサーバーに攻撃対象を認証させ、アクティブなセッションの間、ユーザーのアカウントに攻撃者がアクセスできるようにします。セッション ID を URL で渡すと、攻撃者は、危険にさらされているセッション ID を含んだ URL を電子メールなどのマスコミュニケーションメカニズムを介して被害者に送信することによって、多数のユーザーに被害をもたらすことがあります。

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

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

次の場合に、SSL 例外の未処理の脆弱性が発生します。

1. SSL 特有の例外が発生する。

2. 例外が明示的に処理されない。

SSL 特有の例外 javax.net.ssl.SSLHandshakeException、javax.net.ssl.SSLKeyException、および javax.net.ssl.SSLPeerUnverifiedException はすべて、SSL 接続に関連する重要なエラーを伝達します。これらのエラーが明示的に処理されない場合、接続が予期しない状態で残されたままとなり、セキュリティ上安全ではない状態になる可能性があります。

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

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

特定のクラスのすべてのインスタンスで単一のロガーオブジェクトを共有し、プログラム中に同じロガーを使用することは良いプログラミング方法です。

例 1: 次のステートメントでは、誤って静的ではないロガーを宣言しています。

private final Logger logger =
            Logger.getLogger(MyClass.class);

良いロギング方法では各クラスの単一ロギングの使用が指示されています。

例 1: 次のコードでは、誤って Multiple Loggers を宣言しています。

public class MyClass {
  private final static Logger good =
            Logger.getLogger(MyClass.class);
  private final static Logger bad =
            Logger.getLogger(MyClass.class);
  private final static Logger ugly =
            Logger.getLogger(MyClass.class);
  ...
}

例 1: 新人の開発者は次のような Java プログラムを書きます。

public class MyClass
  ...
    System.out.println("hello world");
  ...
}

たいていのプログラマは Java の微妙なニュアンスを体得していきますが、最初に学んだことにとらわれ、System.out.println() を使って標準出力にメッセージを書いている場合が驚くほど多く見受けられます。

問題は、標準出力または標準エラーに直接書くことが、往々にしてロギングの非構造化形式として使用されることです。構造化ロギング機能は、ロギングレベル、統一フォーマット、ロガー識別子、タイムスタンプなどの機能だけでなく、ログメッセージを正しい場所に送るというおそらく最も重要な機能があります。システム出力ストリームをロガーを適正に使用するコードと混乱すると、結果として重要な情報のないログになることが多くあります。

開発者は構造化ロギングの必要性を広く認めていますが、「実運用前」の開発でシステム出力ストリームを使用し続けている場合が多くあります。開発初期段階を過ぎたコードをレビューしているときに System.out または System.err が使用されている場合は、構造化ロギングシステムへの移行で何かが見落とされている可能性があります。