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

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

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

平文の証明書を設定ファイルまたはマニフェスト ファイルに保存すると、そのファイルを読み取ることができるすべてのユーザーが、証明書で保護されたリソースにアクセスできるようになります。開発者は、設定にアクセスできる人からアプリケーションを防御できないと考えることがありますが、この考え方は攻撃者の作業を容易にします。適切な証明書管理ガイドラインでは、証明書を平文で保存しないことが求められます。

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

テンプレート エンジンは動的なデータを使用してコンテンツをレンダリングするために使用されます。このコンテキスト データは通常、ユーザーによって制御され、テンプレートによって書式設定されて、Web ページ、電子メールなどが生成されます。テンプレート エンジンでは、コンテキスト データを条件文、ループなどのコード構造で処理することで、動的コンテンツをレンダリングするための強力な言語表現をテンプレートで使用できます。攻撃者がテンプレートを制御してレンダリングできる場合、式を挿入してコンテキスト データを開示したり、悪意のあるコードをブラウザーで実行できます。

例 1: 次の例では、テンプレートを URL から取得し、これを使用して AngularJS による情報のレンダリングを行う方法を示しています。

function MyController(function($stateParams, $interpolate){
    var ctx = { foo : 'bar' };
    var interpolated = $interpolate($stateParams.expression);
    this.rendered = interpolated(ctx);
    ...
}

この場合、$stateParams.expressionはユーザーが制御している可能性のあるデータを取得し、これを指定されたコンテキストで使用するテンプレートとして評価します。これにより、悪意のあるユーザーはブラウザ内で目的のコードを実行できるようになり、コードが実行されているコンテキストについての情報の取得、アプリケーションの作成方法に関する追加情報の検索、または本格的な XSS 攻撃への変換を行えるようになる可能性があります。

ブール値に対する算術演算子の動作は、整数値に対する動作とは異なるため、予期せぬ動作を引き起こす場合があります。

バイト配列からのデータが 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 ハッシュの信頼性が損なわれ、特にデフォルトの文字セットに含まれないデータが疑問符などの同じ値で表されている場合、衝突が発生しやすくなった可能性があることを意味します。

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

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

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
	}
}

ICloneable インターフェイスでは、ディープコピーが保証されず、このインターフェイスを実装するクラスはクローンが作成されるときに予想される通りに動作しない可能性があります。ICloneable を実装し、シャローコピー (別のオブジェクトへの既存の参照を含む、オブジェクトのみをコピーする方法) のみを行うクラスでは、予期せぬ動作が発生する可能性があります。ディープコピー (オブジェクトとすべての参照オブジェクトをコピーする方法) が一般にクローンメソッドの動作として仮定されているため、ICloneable インターフェイスを使用するとエラーが発生しやすくなります。このインターフェイスの使用は避ける必要があります。

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]。