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

예제 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로 주석 추가되었으며 음수 값은 허용되지 않음을 나타내는 데 사용됩니다.

PL/SQL에서, NULL의 값은 불명확합니다. 이는 무엇과도 같지 않으며 다른 NULL 값과도 같지 않습니다. 또한 null 값은 다른 값과도 같지 않습니다.

예제 1:다음 문은 항상 false가 됩니다.

checkNull BOOLEAN := x = NULL;

예제 2:다음 문은 항상 false가 됩니다.

checkNotNull BOOLEAN := x != NULL;

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

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

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

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

스레드가 뮤텍스에 대기 중인 다른 스레드를 신호 처리한 다음, 또 다른 스레드가 실행을 시작하기 전에 pthread_mutex_unlock()을 호출하여 뮤텍스를 잠금 해제해야 합니다. 스레드의 신호 처리가 뮤텍스의 잠금 해제를 실패하는 경우, 두 번째 스레드의 pthread_cond_wait() 호출은 반환되지 않고 이 스레드는 실행되지 않습니다.

예제 1: 다음 코드는 pthread_cond_signal()를 호출하여 뮤텍스에 대기 중인 또 다른 스레드를 신호 처리하지만, 대기 중인 나머지 스레드를 뮤텍스의 잠금 해제하는 것은 실패합니다.

   ...
   pthread_mutex_lock(&count_mutex);

   // Signal waiting thread
   pthread_cond_signal(&count_threshold_cv);
   ...

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

이 표현식은 함수의 반환 값보다 함수 포인터를 참조하므로 항상 null이 아닙니다.

예제 1: 다음과 같은 조건절은 작동하지 않습니다. 조건부 getChunk == NULL은 getChunk이 프로그램에 정의된 함수의 이름이므로 항상 false가 됩니다.

  if (getChunk == NULL)
    return ERR;

로컬 변수가 스택에서 할당되므로 프로그램이 로컬 변수로 포인터를 반환할 때 스택 주소가 반환됩니다. 이후의 함수 호출은 같은 스택 주소를 다시 사용할 가능성이 높고 따라서 함수의 스택 프레임이 반환될 때 무효화된 이후 같은 변수와 더 이상 일치하지 않는 포인터의 값을 덮어쓰게 됩니다. 이 경우에는 예상치 않게 포인터의 값이 변경되는 문제만 일어납니다. 상당수의 경우, 포인터가 역참조된 다음에 프로그램이 중단됩니다. 이 문제는 증상과는 관계가 없는 경우도 있어 디버깅이 어려울 수 있습니다.

예제 1: 다음 함수는 스택 주소를 반환합니다.

char* getName() {
  char name[STR_MAX];
  fillInName(name);
  return name;
}

정적 메서드는 클래스의 인스턴스가 아닌 클래스 자체에 속하므로 원칙적으로 오버라이드할 수 없습니다. 정적 메서드가 하위 클래스에서 오버라이드된 것처럼 표시되는 경우도 있는데, 이로 인해 혼동을 하여 잘못된 메서드 버전을 호출하게 될 수도 있습니다.

예제 1: 다음 코드는 사용자 인증을 위한 API를 정의합니다.

class AccessLevel{
  public static final int ROOT = 0;
  //...
  public static final int NONE = 9;
}
//...
class User {
  private static int access;
  public User(){
    access = AccessLevel.ROOT;
  }
  public static int getAccessLevel(){
    return access;
  }
  //...
}
class RegularUser extends User {
  private static int access;
  public RegularUser(){
    access = AccessLevel.NONE;
  }
  public static int getAccessLevel(){
    return access;
  }
  public static void escalatePrivilege(){
    access = AccessLevel.ROOT;
  }
  //...
}
//...
class SecureArea {
  //...
  public static void doRestrictedOperation(User user){
    if (user instanceof RegularUser){
      if (user.getAccessLevel() == AccessLevel.ROOT){
        System.out.println("doing a privileged operation");
      }else{
        throw new RuntimeException();
      }
    }
  }
}

이 코드는 처음 보기에는 아무 문제가 없는 것 같습니다. 그러나 User 또는 RegularUser 클래스가 아닌 user 인스턴스에 대해 getAccessLevel() 메서드를 호출하므로 이 조건에서는 항상 true가 반환됩니다. 그리고 이 if/else 블록 부분으로 진입하기 위해 instanceof를 사용했더라도 제한된 작업이 수행됩니다.

코드 정확성: serializable 클래스가 serialization 또는 deserialization 함수를 작성하지만 올바른 서명을 따르지 않는 경우 잘못된 Serializable 메서드 서명 이슈가 발생합니다.

  private void writeObject(java.io.ObjectOutputStream out) throws IOException;
  private void readObject(java.io.ObjectInputStream in) throws IOException, ClassNotFoundException;
  private void readObjectNoData() throws ObjectStreamException;

serialization에 필요한 메서드 서명이 아닌 서명을 사용하는 경우 serialization/deserialization 중에 메서드가 호출되지 않게 될 수 있습니다. 그러면 serialization/deserialization이 완료되지 않거나, 신뢰할 수 없는 코드가 개체에 접근할 수 있습니다.
발생(throw)하지 않은 예외가 있는 경우 serialization/deserialization이 실패하여 응용 프로그램이 중단되거나 그러한 개체가 부분적으로만 올바르게 생성되었을 수 있습니다. 이로 인해 디버깅하기 매우 어려운 취약점이 발생할 수 있습니다. 호출자가 이러한 예외를 캐치(catch)해야 프로그램이 중단되거나 개체가 부분적으로 생성되는 일 없이 그러한 잘못된 serialization/deserialization이 적절하게 처리될 수 있습니다.

Java Object Serialization Specification을 사용하면 개발자는 serialPersistentFields 배열에서 지정하여 클래스에 대해 Serializable 필드를 수동으로 정의할 수 있습니다. 이 기능은 serialPersistentFields가 private, static 및 final로 선언된 경우에만 작동합니다.

예제 1: 다음 serialPersistentFields 선언은 private, static 및 final이 아니기 때문에 Serializable 필드를 정의하는 데 사용되지 않습니다.

class List implements Serializable {
public ObjectStreamField[] serialPersistentFields = { new ObjectStreamField("myField", List.class) };
...
}

대부분의 경우에는 배열에 대한 Object.equals() 호출은 잘못된 것입니다. 이와 같이 호출하면 배열 요소가 아니라 배열 주소가 같은지를 확인하기 때문입니다. 일반적으로는 java.util.Arrays.equals()를 대신 호출해야 합니다.

예제 1: 다음 코드에서는 Object.equals() 함수를 사용하여 두 배열 확인을 시도합니다.

...
  int[] arr1 = new int[10];
  int[] arr2 = new int[10];
  ...
  if (arr1.equals(arr2)){
    //treat arrays as if identical elements
  }
...

특정 지점에서 한 배열을 다른 배열에 할당하는 경우가 아니면 이러한 코드는 거의 항상 실행되지 않습니다.

특정한 함수 패밀리는 일부 플래폼 및 다른 매크로에서 함수로써 구현됩니다. 호출되는 곳으로 전달되기 보다는 내부적으로 유지되는 공유 리소스를 함수가 의지하는 경우, 이 함수는 동일한 프로그램 범위에서 사용해야 하며 그렇지 않을 경우 공유 리소스에 접근할 수 없습니다.

예제 1: 다음 코드는 pthread_cleanup_push()를 사용하여 함수 routine을 호출 스레드의 정리 스택으로 푸시하고 반환합니다. pthread_cleanup_push()와 해당 파트너 함수인 pthread_cleanup_pop()은 IBM AIX가 아닌 플랫폼에서 매크로로 구현되므로 pthread_cleanup_push()에 의해 생성되는 데이터 구조는 이후의 pthread_cleanup_pop() 호출에 액세스할 수 없게 됩니다. 코드가 컴파일에 실패하거나 이러한 함수가 매크로로 구현되는 모든 플랫폼에서는 런타임 시 코드가 올바로 작동하지 않습니다.

void helper() {
   ...
   pthread_cleanup_push (routine, arg);
}

스택 메모리를 명시적으로 할당 해제합니다. 스택 버퍼를 정의하는 함수는 함수가 반환할 때 버퍼를 자동으로 할당 제거합니다.
예제 1:

void clean_up()
{
    char tmp[256];
    ...
    free(tmp);
    return;
}

명시적으로 스택 메모리를 해제하면 메모리 할당 데이터 구조를 손상시킬 수 있습니다. 비정상적으로 프로그래밍 종료되거나 데이터가 더 크게 손상될 수 있습니다.

이 메서드의 이름은 일반 Java 메서드 이름과 비슷하지만 철자가 틀렸거나 인수 목록이 의도한 메서드를 덮어쓰게 만듭니다.

예제 1: 다음 메서드는 Object.equals()를 오버라이드합니다.

public boolean equals(Object obj1, Object obj2) {
  ...
}

Object.equals()가 하나의 인수만 받기 때문에 Example 1의 메서드는 호출되지 않습니다.

.NET 런타임은 [Serializable] 속성을 선언하는 모든 개체의 serialization을 허용합니다. .NET 프레임워크에 의해 정의된 기본 serialization 메서드를 사용하여 클래스를 직렬화할 수 있으면 개체를 정확하게 직렬화해야 할 필요와 직렬화하기 위한 충분한 조건이 충족됩니다. 클래스가 사용자 지정 serialization 메서드를 사용해야 하는 경우 ISerializable 인터페이스도 구현해야 합니다. 그러나, 이 경우에도 클래스는 [Serializable] 속성을 선언해야 합니다.

예제 1:CustomStorage 클래스는 ISerializable 인터페이스를 구현합니다. 그러나, [Serializable] 속성의 선언이 실패하므로 직렬화되지 않습니다.

public class CustomStorage: ISerializable {
	...
}

HttpServletRequest을 전달하거나, HttpServletResponse를 리디렉션하거나 서블릿의 출력 스트림 버퍼를 플러시하면 연결된 스트림이 커밋됩니다. 추가 플러시 또는 리디렉션 등, 이어지는 버퍼 재설정 또는 스트림 커밋은 IllegalStateException으로 이어질 수 있습니다.

또한 Java 서블릿을 사용하면 ServletOutputStream 또는 PrintWriter 중 하나를 사용하여(두 가지 모두는 안 됨) 응답 스트림에 데이터를 쓸 수 있습니다. getOutputStream()을 호출한 후 getWriter()를 호출하거나 또는 그 반대의 경우에도 IllegalStateException이 발생합니다.



런타임 시, IllegalStateException은 응답 핸들러가 실행 완료되는 것을 막아 응답을 취소합니다. 이로 인해 서버 불안정이 발생할 수 있는데, 이는 서블릿이 잘못 구현되었다는 의미입니다.

예제 1: 다음 코드는 해당 출력 스트림 버퍼가 플러시되고 나면 서블릿 응답을 리디렉션합니다.

public class RedirectServlet extends HttpServlet {
    public void doGet(HttpServletRequest req, HttpServletResponse res) throws ServletException, IOException {
        ...
        OutputStream out = res.getOutputStream();
        ...
        // flushes, and thereby commits, the output stream
        out.flush();
        out.close();        // redirecting the response causes an IllegalStateException
        res.sendRedirect("http://www.acme.com");
    }
}

예제 2: 반대로 다음 코드는 요청이 전달되고 나면 PrintWriter의 버퍼에 쓰거나 플러시를 시도합니다.

public class FlushServlet extends HttpServlet {
    public void doGet(HttpServletRequest req, HttpServletResponse res) throws ServletException, IOException {
        ...
        // forwards the request, implicitly committing the stream
        getServletConfig().getServletContext().getRequestDispatcher("/jsp/boom.jsp").forward(req, res);
        ...

        // IllegalStateException; cannot redirect after forwarding
        res.sendRedirect("http://www.acme.com/jsp/boomboom.jsp");

        PrintWriter out = res.getWriter();

        // writing to an already-committed stream will not cause an exception,
        // but will not apply these changes to the final output, either
        out.print("Writing here does nothing");

        // IllegalStateException; cannot flush a response's buffer after forwarding the request
        out.flush();
        out.close();
    }
}

대부분의 경우 요청의 Content-Length 헤더를 설정한다는 것은 개발자가
서버로 전송되는 POST 데이터의 길이를 전달하고자 한다는 뜻입니다. 하지만 이 헤더는 0 또는
양의 정수여야 합니다.

예제 1: 다음 코드는 잘못된 Content-Length를 설정합니다.

  URL url = new URL("http://www.example.com");
  HttpURLConnection huc = (HttpURLConnection)url.openConnection();
  huc.setRequestProperty("Content-Length", "-1000");

inner class의 serialization을 수행하면 outer class도 serialization될 수 있어 정보가 누출될 수 있으며, outer class가 serializable이 아닌 경우에는 런타임 오류가 발생할 수 있습니다. 뿐만 아니라 inner class를 serialize하면 플랫폼 dependency가 발생할 수 있습니다. Java 컴파일러는 inner class를 구현하기 위해 가상 필드를 만드는데, 이러한 필드는 구현에 따라 다르며 컴파일러별로도 다를 수 있기 때문입니다.

예제 1: 다음 코드는 inner class의 serialization을 허용합니다.

  ...
  class User implements Serializable {
    private int accessLevel;
    class Registrator implements Serializable {
      ...
    }
  }

Example 1에서 inner class Registrator를 serialize하면 outer class User의 accessLevel 필드도 serialize됩니다.