Castor がオブジェクトをロックしていても、他のスレッドによりオブジェクトが読み取られたり書き込まれたりする可能性があります。読み取り専用のクエリは、デフォルトの共有モードと比較して、約 7 倍処理が早くなります。

例 1: 次の例では、クエリモードが SHARED に指定されており、読み取りアクセスと書き込みアクセスの両方が許可されています。

results = query.execute(Database.SHARED);

デフォルトでは、Castor は共有モードでクエリを実行します。共有モードでは、読み取りアクセスと書き取りアクセスの両方が許可されるため、目的とするクエリ操作の種類が不明瞭となります。オブジェクトが読み取り専用で使用される場合には、不要なパフォーマンス負荷がかかることになります。

例 1: 次の例では、クエリモードが指定されていません。

results = query.execute();    //missing query mode

ClassLoader 操作により、攻撃者は基盤となるアプリケーション サーバー設定にアクセスして変更することができます。Tomcat 8 などの特定のアプリケーション サーバーでは、攻撃者がこれらの設定を微調整して Web シェルをアップロードし、任意のコマンドを実行する可能性があります。

バイト配列からのデータが String に変換された場合、適用可能な文字セットに含まれないデータに何が起こるかは不明です。これによって、データが失われる可能性があります。また、適切なセキュリティ体制を保証するためにバイナリ データが必要な場合は、セキュリティ レベルの低下につながります。

例 1: 次のコードは、ハッシュを生成するためにデータを文字列に変換します。

  ...
  FileInputStream fis = new FileInputStream(myFile);
  byte[] byteArr = byte[BUFSIZE];
  ...
  int count = fis.read(byteArr);
  ...
  String fileString = new String(byteArr);
  String fileSHA256Hex = DigestUtils.sha256Hex(fileString);
  // use fileSHA256Hex to validate file
  ...

ファイルのサイズが BUFSIZE より小さいと仮定すると、myFile の情報がデフォルトの文字セットと同様にエンコードされている限り問題はありません。ただし、別のエンコーディングが使用されていたり、ファイルがバイナリ ファイルである場合は、情報を失います。その結果、生成された SHA ハッシュの信頼性が損なわれ、特にデフォルトの文字セットに含まれないデータが疑問符などの同じ値で表されている場合、衝突が発生しやすくなった可能性があることを意味します。

notify() のコールで、起動されるスレッドを指定する方法はありません。

例 1: 次のコードでは、notifyJob() が notify() をコールします。

public synchronized notifyJob() {
flag = true;
notify();
}
...
public synchronized waitForSomething() {
while(!flag) {
    try {
        wait();
    }
    catch (InterruptedException e)
    {
        ...
    }
}
...
}

この場合、開発者はwait()をコールするスレッドを起動しようとしていますが、notify()が意図しているスレッドとは別のスレッドを通知する可能性があります。

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

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

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

Java 開発者であれば誰でもある段階で、ガーベジコレクタが原因であるとしか考えられない、デバッグに際して不可解で得体の知れない問題を経験するものです。特に、Time and State に関連したバグである場合、この理論を裏付ける実証的証拠が存在する可能性があります。System.gc() のコールを挿入することで問題が解消するかのように思える場合があります。

これまでの経験上、System.gc() をコールするという方法は間違っていることがほとんどです。なぜなら、System.gc() のコールを頻繁に呼び出すと、性能の問題が引き起こされる可能性があるからです。

ほとんどの場合、Thread オブジェクトの run() メソッドの直接コールはバグです。プログラマは制御の新規スレッドを開始しようとして、誤って start() の代わりに run() をコールしたため、run() メソッドがコーラーの支配下のスレッドで実行されます。

例 1: 次の Java プログラムからの抜粋は、start() の代わりに誤って run() をコールしています。

    Thread thr = new Thread() {
      public void run() {
        ...
      }
    };

  thr.run();

ほとんどの場合、Thread オブジェクトの stop() メソッドの直接コールはバグです。プログラマーはスレッドの実行を中止しようとするかもしれませんが、スレッドの停止は適切な方法ではありません。Thread の stop() 関数は ThreadDeath 例外を Thread オブジェクトのどこかで引き起こす可能性があり、オブジェクトは不整合な状態になり、漏えいの可能性のあるリソースになります。API は本質的に安全ではないため、かなり前に廃止されています。

例 1: 次の例は、誤って Thread.stop() をコールしている Java プログラムです。

  ...
  public static void main(String[] args){
    ...
    Thread thr = new Thread() {
      public void run() {
        ...
      }
    };
    ...
    thr.start();
    ...
    thr.stop();
    ...
  }

clone() と名付けられたメソッドを実装するため、プログラマはこのクラスで Cloneable インターフェイスの実装を意図したようです。しかし、クラスは Cloneable インターフェイスを実装せず、clone() メソッドは正しく動作しません。

例 1: このクラスに clone() をコールすると、結果として CloneNotSupportedException. になります。

public class Kibitzer {
  public Object clone() throws CloneNotSupportedException {
    ...
  }
}

開発者がオブジェクトを比較する場合、通常はオブジェクトのプロパティを比較します。しかし、明示的に equals() を実装していないクラス (あるいは任意のスーパークラス/インターフェイス) で equals() をコールすると、java.lang.Object から継承した equals() メソッドがコールされる結果となります。Object.equals() はオブジェクトのメンバーフィールドやその他のプロパティを比較する代わりに、2 つのオブジェクトインスタンスを比較してその 2 つが同一のものであるかを確認します。Object.equals() の正規の利用法も存在しますが、通常はコードにバグがあることを示しています。

例 1:

public class AccountGroup
{
	private int gid;

	public int getGid()
	{
		return gid;
	}

	public void setGid(int newGid)
	{
		gid = newGid;
	}
}
...
public class CompareGroup
{
	public boolean compareGroups(AccountGroup group1, AccountGroup group2)
	{
		return group1.equals(group2);   //equals() is not implemented in AccountGroup
	}
}

clone() 関数がオーバーライド関数をコールする場合、クローンが部分的に初期化された状態で、あるいは壊れた状態で残ることがあります。

例 1: 次の clone() 関数は、オーバーライドされる可能性のあるメソッドをコールしています。

  ...
  class User implements Cloneable {
    private String username;
    private boolean valid;
    public Object clone() throws CloneNotSupportedException {
      final User clone = (User) super.clone();
      clone.doSomething();
      return clone;
    }
    public void doSomething(){
      ...
    }
  }

関数 doSomething() と括弧で囲まれたクラスは final ではないため、関数がオーバーライドされる可能性があります。その結果、クローン オブジェクト clone が部分的に初期化された状態で残され、ロジックを対処しなかった場合、予期しない方法でエラーが起こる可能性があります。

ボクシングされたプリミティブ型が等価かどうかを比較する場合、演算子 == や != ではなくボクシングされたプリミティブ型の equals() メソッドをコールするべきです。Java 仕様は、ボクシング変換について次のように記述しています。

"ボクシング変換の対象となる値 p が -128 から 127 までの数値であるint 型の整数リテラル、true または false のブール リテラル、「\u0000」から「\u007f」までの文字リテラルである場合、p に対する任意の 2 つのボクシング変換結果を a と b とする。この場合、常に a == b が成立する。"

これは、ボクシングされたプリミティブ型が使用される場合 (Boolean または Byte 以外)、特定の範囲の値のみがキャッシュまたはメモリに保存されることを意味します。値のサブセットでは、== または != を使用して正しい値を返します。このサブセットに含まれないすべての値では、オブジェクト アドレスを比較した結果を返します。

例 1: 次の例では、ボクシングされたプリミティブ型で等価演算子を使用しています。

  ...
  Integer mask0 = 100;
  Integer mask1 = 100;
  ...
  if (file0.readWriteAllPerms){
    mask0 = 777;
  }
  if (file1.readWriteAllPerms){
    mask1 = 777;
  }
  ...
  if (mask0 == mask1){
    //assume file0 and file1 have same permissions
    ...
  }
  ...

Example 1 のコードでは、Integer のボクシングされたプリミティブ型を使用して、2 つの int 値を比較しようとしています。mask0 と mask1 が両方とも 100 と等しい場合は、mask0 == mask1 は true を返します。しかし、mask0 と mask1 が両方とも 777 に等しい場合は、これらの値がボクシングされたプリミティブ型のキャッシュされた値の範囲内にないため、mask0 == maske1 は false を返します。

NaN と比較した場合、常に false と評価されます。例外は != 演算子で、NaN は非順序型であるため常に true と評価されます。

例 1: 次では、変数が NaN ではないことを確認しています。

  ...
  if (result == Double.NaN){
    //something went wrong
    throw new RuntimeException("Something went wrong, NaN found");
  }
  ...

ここでは、result が NaN ではないことの検証を試みています。しかし、NaN に演算子 == を使用すると、常に結果は false の値になり、このチェックで例外がスローされることはありません。

コンストラクターがオーバーライド可能な関数をコールするとき、オブジェクトが完全に初期化される前に攻撃者が this 参照にアクセスすることを許可する可能性があるため、脆弱性につながります。

例 1: 次の例では、オーバーライドされる可能性のあるメソッドをコールしています。

  ...
  class User {
    private String username;
    private boolean valid;
    public User(String username, String password){
      this.username = username;
      this.valid = validateUser(username, password);
    }
    public boolean validateUser(String username, String password){
      //validate user is real and can authenticate
      ...
    }
    public final boolean isValid(){
      return valid;
    }
  }

関数 validateUser とクラスは final ではないため、オーバーライドされる可能性があります。また、この関数をオーバーライドするサブクラスへの変数を初期化することで、validateUser 関数の回避を可能にしてしまいます。例：

  ...
  class Attacker extends User{
    public Attacker(String username, String password){
      super(username, password);
    }
    public boolean validateUser(String username, String password){
      return true;
    }
  }
  ...
  class MainClass{
    public static void main(String[] args){
      User hacker = new Attacker("Evil", "Hacker");
      if (hacker.isValid()){
        System.out.println("Attack successful!");
      }else{
        System.out.println("Attack failed");
      }
    }
  }

Example 1 のコードは "Attack successful!" を出力します。これは、Attacker クラスがスーパークラス User のコンストラクターからコールされる validateUser() 関数をオーバーライドすることで、Java は最初にコンストラクターからコールされた関数のサブクラスを見るためです。

これまでも才能ある数多くの個人がかなりの時間を費やし、性能を向上させるために 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]。

攻撃者は、プログラムで悪意あるコードが実行されるようにするために、クラス名を故意に複製する可能性があります。この理由から、クラス名はタイプを表す識別子として適切ではないため、特定のオブジェクトを信頼する基準として使用しないでください。

例 1: 次のコードは、そのクラス名を基準にして inputReader オブジェクトからの入力を信頼するかどうかを決定しています。攻撃者が悪意あるコマンドを実行する inputReader の実装を提供できる場合、このコードはオブジェクトが無害であるか悪意あるものであるかを区別することができなくなります。

if (inputReader.getClass().getName().equals("com.example.TrustedClass")) {
   input = inputReader.getInput();
   ...
}

Java 言語仕様は、finalize() メソッドで super.finalize() のコールを行うことは適切な方法であるとしています [1]。

例 1: 次のメソッドは、super.finalize() のコールを省略しています。

protected void finalize() {
  discardNative();
}

このフィールドには FortifyNonNegative というアノテーションが付けられています。これは、負の値が認められていないことを示すためのものです。

このプログラムは 2 つの文字列の比較に == または != を使用し、2 つのオブジェクトの値ではなく、オブジェクトが等価かどうかを比較します。このような場合、2 つの参照が等価でない可能性が高いのです。

例 1: 以下の分岐を通ることはありません。

  if (args[0] == STRING_CONSTANT) {
      logger.info("miracle");
  }

== および != 演算子は、等価であるオブジェクトに含まれる文字列を比較するために使用されるときにのみ、予期されるとおりに動作します。これが発生する一般的な状況は、文字列が抑留され、String クラスにより保持されるオブジェクトのプールにこの文字列が追加される場合です。文字列が一度抑留されると、同じオブジェクトと等価演算子を使用する文字列のすべての使用は、予期されるとおりに動作します。すべての文字列リテラルおよび文字列値の定数は、自動的に抑留されます。その他の文字列は String.intern() を呼び出して手動で抑留できます。これにより、現在の文字列の正準な (規則に沿った) インスタンスが返されます (必要な場合には、正準なインスタンスが作成されます)。