기본적으로 Castor는 공유 모드에서 쿼리를 실행합니다. 공유 모드에서는 읽기 및 쓰기 접근이 모두 가능하기 때문에 쿼리가 의도한 작업의 종류가 무엇인지 불분명합니다. 개체가 읽기 전용 컨텍스트에 사용될 경우, 공유된 접근은 불필요한 성능 오버헤드를 추가합니다.

예제 1: 다음 예는 쿼리 모드를 지정하지 않습니다.

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

ClassLoader Manipulation을 통해 공격자는 기본 응용 프로그램 서버 설정에 액세스하고 이를 수정할 수 있습니다. Tomcat 8과 같은 특정 응용 프로그램 서버에서 공격자는 이러한 설정을 조정하여 웹 셸을 업로드하고 임의의 명령을 실행할 수 있습니다.

바이트 배열의 데이터를 String으로 변환할 때 해당되는 문자 집합 외부의 데이터가 어떻게 변환되는지는 지정되지 않습니다. 따라서 데이터가 손실되거나, 적절한 보안 대책을 따르기 위해 이진 데이터가 필요할 때 보안 수준이 낮아질 수 있습니다.

예제 1: 다음 코드는 해시를 만들기 위해 데이터를 String으로 변환합니다.

  ...
  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()을 호출하면 다른 모든 스레드는 리소스가 해제되기를 기다리게 될 수 있어 성능이 저하되거나 교착 상태(deadlock)가 될 수 있습니다.

예제 1: 다음 코드는 잠금 상태에 있는 동안 sleep()을 호출합니다.

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

Java 개발자는 개발 경력을 쌓다 보면 누구나 아주 난해하고 이해하기 힘들고 디버깅으로 해결할 수 없어서 가비지 수집기(garbage collector) 외에는 다른 원인을 찾을 수 없을 것 같은 문제를 겪게 됩니다. 특히 버그가 time and state와 관련된 경우 이 이론을 뒷받침하는 경험 상의 증거는 다음과 같습니다. 바로 call to 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() 함수는 Thread 개체 내의 모든 위치에서 ThreadDeath 예외를 발생시켜 개체가 일치하지 않는 상태가 되고 리소스가 누출될 수 있습니다. 이 API는 본질적으로 안전하지 않으므로 오래 전부터 더 이상 사용되지 않습니다.

예제 1: Java 프로그램에서 발췌된 다음 코드는 Thread.stop()을 잘못 호출합니다.

  ...
  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()는 동일한지 알아보기 위해 두 개의 개체 인스턴스를 비교합니다. 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 사양에는 boxing 변환이 다음과 같이 설명되어 있습니다.

"상자로 표시되는 값 p가 -128에서127 사이의 int 유형 정수 리터럴이거나, 부울 리터럴 true 또는 false이거나, '\u0000'에서 '\u007f' 사이의 문자 리터럴인 경우 p의 두 boxing 변환 결과를 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 상자 표시 기본 형식을 사용하여 두 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() 개체만 할당되는 것을 보장하려 하지만 이 코드를 호출할 때마다 동기화 비용을 지불하지는 않으려는 경우가 있습니다. 이런 경우를 double-checked locking이라고 합니다.

유감스럽게도 코드는 의도대로 동작하지 않고 여러 Fitzer() 개체를 할당합니다. 자세한 내용은 "Double-Checked Locking is Broken" Declaration을 참조하십시오[1].

공격자는 프로그램이 악성 코드를 실행하도록 만들기 위해 의도적으로 클래스 이름을 복제할 수 있습니다. 이러한 이유로 클래스 이름은 좋은 형식 식별자가 아니며 지정된 개체에 대한 신뢰를 부여하는 기준으로 사용해서는 안 됩니다.

예제 1: 다음 코드에서는 inputReader 개체의 입력을 신뢰할지 여부를 해당 클래스 이름을 기준으로 결정합니다. 공격자가 악성 명령을 실행하는 inputReader의 구현을 제공할 수 있는 경우, 이 코드는 개체의 양성 버전과 악성 버전을 구별할 수 없습니다.

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

Java Language Specification은 finalize() 메서드로 super.finalize()를 호출하는 것이 좋은 방법이라고 설명합니다[1].

예제 1: 다음 메서드는 super.finalize() 호출이 생략된 것입니다.

protected void finalize() {
  discardNative();
}

이 필드는 FortifyNonNegative로 주석 추가되었으며 음수 값은 허용되지 않음을 나타내는 데 사용됩니다.

이 프로그램은 문자열이 같은지 비교하기 위해 == 또는 !=을 사용하는데 이 연산자는 두 개체의 값이 아닌 참조를 비교합니다. 두 참조가 같지 않을 가능성이 큽니다.

예제 1: 다음 분기는 실행되지 않습니다.

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

== 및 != 연산자는 같은 개체에 포함된 문자열을 비교하도록 사용할 때에만 예상대로 작동합니다. 이를 위한 가장 일반적인 방법은 인턴(intern)된 문자열에 대한 것이고, 여기에서 이 문자열은 String 클래스에 의해 유지되는 개체의 풀에 추가할 수 있습니다. 한 번 문자열이 인턴(intern)되면, 모든 문자열 사용은 동일한 개체를 사용하고 같은 연산자가 예상대로 작동합니다. 모든 문자열 리터럴 및 문자열 값 상수는 자동으로 인턴(intern)됩니다. 다른 문자열은 String.intern()을 수동으로 호출하여 인턴할 수 있어 현재 문자열의 정규 인스턴스를 반환하고, 필요한 경우 하나를 생성합니다.

이 필드는 FortifyNonZero로 주석 추가되었으며 0은 허용된 값이 아님을 나타내는 데 사용됩니다.