기본적으로 ASP.NET 서버는 HttpSessionState 개체, 해당 속성 및 메모리에서 참조하는 모든 개체를 저장합니다. 이 모델은 단일 시스템의 시스템 메모리가 수용할 수 있는 상태로 활성 세션 상태를 제한합니다. 이 제약의 범위를 넘어 용량을 확장하려면 전체적인 성능을 개선하기 위해 용량을 확장하고 여러 시스템 간의 복제를 허용하는 세션 상태 정보를 지속하도록 서버를 자주 구성해야 합니다. 해당 세션 상태를 유지하려면 저장된 모든 개체가 serializable 상태인 HttpSessionState를 서버가 직렬화해야 합니다.

세션을 올바로 직렬화하려면 응용 프로그램이 세션 속성으로 저장하는 모든 개체에 대해 [Serializable] 속성을 선언해야 합니다. 또한, 개체가 사용자 지정 serialization 메서드를 사용해야 하는 경우 ISerializable 인터페이스도 구현해야 합니다.

예제 1: 다음 클래스는 자신을 세션에 추가하지만 serializable 상태가 아니므로 세션을 올바로 직렬화할 수 없습니다.

public class DataGlob {
   String GlobName;
   String GlobValue;

   public void AddToSession(HttpSessionState session) {
     session["glob"] = this;
   }
}

여러 스레드가 리소스를 잠그려고 할 경우, 잠금 상태에 있는 동안 sleep()을 호출하면 다른 모든 스레드는 리소스가 해제되기를 기다리게 될 수 있어 성능이 저하되거나 교착 상태(deadlock)가 될 수 있습니다.

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

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

많은 재능있는 개발자들이 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].

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

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

   ...
   pthread_mutex_lock(&count_mutex);

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

응용 프로그램이 임시 파일을 너무 자주 필요로 하기 때문에 C 라이브러리와 Windows(R) API에 이를 생성하기 위한 다양한 메커니즘이 많이 있습니다. 이 함수 대부분이 다양한 형태의 공격에 취약합니다.
예제 1: 다음 코드는 네트워크에서 수집한 중간 데이터를 처리하기 전에 저장하기 위해 임시 파일을 사용합니다.

...
if (tmpnam_r(filename)){
	FILE* tmp = fopen(filename,"wb+");
	while((recv(sock,recvbuf,DATA_SIZE, 0) > 0)&&(amt!=0))
		amt = fwrite(recvbuf,1,DATA_SIZE,tmp);
}
...

안전하지 않은 방법으로 임시 파일을 만든다는 점 외에는 별다른 특징이 없는 이 코드는 바로 그 점 때문에 수많은 다양한 공격에 취약합니다. 다음 섹션에서 이런 함수들 때문에 생긴 취약점에 대해 설명합니다. 임시 파일 생성과 관련한 가장 심각한 보안 문제는 Unix 기반 운영 체제에서 발생하지만, Windows 응용 프로그램도 같은 위험을 안고 있습니다. 이 섹션에서는 Unix 및 Windows 시스템의 임시 파일 생성에 대해 모두 다룹니다.

방법과 동작은 시스템마다 다를 수 있지만 각각이 야기하는 근본적인 위험은 대체로 일정합니다. 안전한 코어 언어 함수에 대한 정보 및 안전한 임시 파일 생성 방법에 관한 조언은 권고 사항 섹션을 참조하십시오.

임시 파일 생성을 지원하도록 설계된 함수는 단순히 파일 이름만 제공하는지 또는 실제로 새 파일을 여는지에 따라 두 그룹으로 나눌 수 있습니다.

그룹 1 - "고유한" 파일 이름:

임시 파일 생성 프로세스를 지원하도록 설계된 첫 번째 그룹의 C 라이브러리 및 WinAPI 함수는 프로그램이 열 새 임시 파일에 고유한 파일 이름을 만들어 프로세스를 지원합니다. 이 그룹에는 Windows API의 GetTempFileName() 함수뿐 아니라 tmpnam(), tempnam(), mktemp() 및 이에 상응하는, 앞에 _(밑줄)이 붙은 C++ 함수 등의 C 라이브러리가 있습니다 이 그룹의 함수는 속성 상 선택한 파일 이름에 대한 경쟁 조건(race condition)이 발생합니다. 함수가 파일 이름 선택 시점에 이름이 고유하다는 것은 보장하지만 이름을 선택한 후 응용 프로그램이 파일을 열기 전에 다른 프로세서나 공격자가 같은 이름의 파일을 생성하는 것을 방지하는 메커니즘이 없습니다. 같은 함수의 다른 호출로 인해 발생하는 자연스러운 충돌의 위험 외에도 이들 함수가 생성한 파일 이름이 추측하기 어려울 만큼 무작위성이 보장되지 않기 때문에 공격자가 악의적으로 충돌을 일으킬 수 있습니다.

선택한 이름의 파일이 만들어지면 파일을 여는 방법에 따라 파일의 기존 내용 또는 접근 권한이 그대로 유지될 수 있습니다. 임시 파일의 기존 내용이 악성인 경우, 공격자는 응용 프로그램이 임시 파일에서 데이터를 읽을 때 위험한 데이터를 응용 프로그램에 삽입하게 됩니다. 공격자가 완화된 접근 권한의 임시 파일을 미리 만들게 되면 응용 프로그램이 임시 파일에 저장한 데이터에 접근, 수정 및 손상시킬 수 있습니다. Unix 기반 시스템에서는 공격자가 임시 파일을 다른 중요한 파일의 링크로 미리 만드는 경우 훨씬 심각한 공격이 될 수 있습니다. 이때 응용 프로그램이 임시 파일을 자르거나 임시 파일에 데이터를 쓰는 경우, 모르는 사이에 공격자 대신 시스템을 손상시키는 작업을 수행할 수 있습니다. 이는 프로그램을 높은 권한으로 실행할 때 특히 위험해집니다.

마지막으로 최선의 방법은 O_CREAT 및 O_EXCL 플래그를 사용한 open() 호출 또는 CREATE_NEW 속성을 사용한 CreateFile() 호출로 파일을 여는 것입니다. 이 방법은 파일이 이미 있을 때는 파일을 열지 않기 때문에 앞서 설명한 종류의 공격을 예방할 수 있습니다. 하지만 공격자가 임시 파일 이름의 순서를 정확하게 예측할 수 있는 경우 응용 프로그램이 필요한 임시 저장소를 여는 것을 막아 Denial Of Service(DoS) 공격을 일으킬 수 있습니다. 이런 종류의 공격은 이들 함수가 생성하는 파일의 이름 선택에 사용된 무작위성의 수준이 낮은 것을 감안하면 어렵지 않게 실행할 수 있습니다.

그룹 2 - "고유한" 파일:

두 번째 그룹의 C 라이브러리 함수는 고유한 파일 이름을 생성할 뿐 아니라 파일을 여는 방식으로 일부 임시 파일 관련 보안 문제를 해결하려 합니다. 이 그룹에는 tmpfile() 및 이에 상응하는, 앞에 _(밑줄)이 붙은 C++ 함수뿐 아니라 동작 기능이 좀 더 우수한 C 라이브러리 함수 mkstemp() 등의 C 라이브러리 함수가 있습니다.

tmpfile() 형식의 함수는 "wb+" 플래그가 전달되면(즉, 읽기/쓰기 모드의 이진 파일로 전달되면) 고유한 파일 이름을 생성하고 fopen()과 같은 방식으로 파일을 엽니다. 파일이 이미 있으면, 앞에서 언급한 고유한 파일 이름 선택과 이후의 선택한 파일 열기 사이에 존재하는 경쟁 조건(race condition) 관련 보안 문제를 해결하기 위해 tmpfile()은 크기 0으로 파일을 자릅니다. 하지만 이 동작으로 함수의 보안 문제를 해결하지는 못합니다. 첫째, 공격자는 대체로 tmpfile()이 연 파일이 보유하고 있을 완화된 접근 권한으로 파일을 미리 만들 수 있습니다. 뿐만 아니라, Unix 기반 시스템에서 공격자가 파일을 다른 중요한 파일의 링크로 미리 만드는 경우, 응용 프로그램은 높은 권한을 사용하여 해당 파일을 잘라 공격자 대신 시스템을 손상시킬 수 있습니다. 마지막으로 tmpfile()이 새 파일을 만들게 되면 해당 파일에 적용되는 접근 권한이 운영 체제 별로 다르기 때문에 공격자가 사용할 파일 이름을 미리 예측할 수 없는 경우에도 응용 프로그램 데이터가 취약해질 수 있습니다.

결국 임시 파일을 만드는 안전한 방법은 mkstemp()입니다. 이 함수는 사용자가 제공한 파일 이름 템플릿과 무작위로 생성된 일련의 문자를 기반으로 고유한 파일을 만들고 엽니다. 그런 파일을 만들 수 없는 경우 작업은 실패하고 -1을 반환합니다. 요즘의 시스템에서는 0600 모드를 사용하여 파일을 엽니다. 즉, 파일은 사용자가 접근 권한을 명시적으로 변경하는 경우를 제외하고 외부에서 조작할 수 없습니다. 하지만 mkstemp()도 예측 가능한 파일 이름 사용에서 자유롭지 못하며 공격자가 사용할 파일 이름을 예측하고 미리 만들어 mkstemp()가 실패하게 만들면 응용 프로그램이 denial of service 공격에 취약해질 수 있습니다.

세션을 더 오래 열어둘수록, 공격자가 사용자 계정을 손상시킬 수 있는 기회는 더 커집니다. 세션이 활성화 상태라면 공격자는 사용자의 암호를 무차별 대입하거나 사용자의 무선 암호화 키를 불법으로 복제하거나 열려 있는 브라우저에서 세션을 제멋대로 쓸 수도 있습니다. 또한 세션 초과 시간이 더 길어지면 메모리가 해제되지 못하도록 하여 결국 충분히 많은 세션이 만들어지는 경우 denial of service가 발생됩니다.

예제 1: 다음 예제의 코드는 최대 비활성 간격을 음수 값으로 설정하여 세션이 무기한으로 활성 상태를 유지하도록 합니다.

...
HttpSession sesssion = request.getSession(true);
sesssion.setMaxInactiveInterval(-1);
...

웹 응용 프로그램을 통해 응용 프로그램 컨테이너를 종료하려 하는 것은 좋은 방법이 아닙니다. 종료 메서드 호출은 제거되지 않은 leftover debug code의 일부분이거나 Non-J2EE 응용 프로그램에서 가져온 코드일 것입니다.

J2EE 응용 프로그램은 여러 JVM을 이용하여 응용 프로그램 안정성과 성능을 개선합니다. 최종 사용자에게 여러 JVM을 하나의 응용 프로그램으로 보이게 하기 위해, J2EE 컨테이너는 여러 JVM에 HttpSession 개체를 복제하여 한 JVM을 사용할 수 없게 되면 다른 JVM이 개입하여 역할을 대신하기 때문에 응용 프로그램의 흐름이 중단되지 않습니다.

세션 복제가 제대로 동작하려면 응용 프로그램이 세션에 속성으로 저장한 값이 Serializable 인터페이스를 구현해야 합니다.

예제 1: 다음 클래스는 자신을 세션에 추가하지만 serializable 상태가 아니므로 세션을 더 이상 복제할 수 없습니다.

public class DataGlob {
   String globName;
   String globValue;

   public void addToSession(HttpSession session) {
     session.setAttribute("glob", this);
   }
}

J2EE 표준은 일부 경우에 웹 응용 프로그램의 스레드 관리를 금지하는데 스레드 관리는 항상 오류 발생 가능성이 높습니다. 스레드 관리는 어려운 작업이고 예상치 못한 방식으로 응용 프로그램 컨테이너의 동작을 방해할 가능성이 큽니다. 컨테이너를 방해하지 않는 경우에도, 스레드 관리는 보통 발견하기 어렵고 교착 상태, 경쟁 조건(race condition), 및 기타 동기화 오류 등으로 진단되는 버그를 일으킵니다.

소프트웨어에 대한 대부분의 심각한 공격은 프로그래머의 가정 위반에서 비롯됩니다. 공격 후, 프로그래머의 가정은 취약하고 근거가 빈약해 보이지만 공격 전에는 많은 프로그래머가 열심히 자신의 가정을 옹호하게 마련입니다.

코드에서 흔히 발견되는 두 가지 의심스런 가정은 "이 메서드 호출은 절대 실패하지 않는다" 및 "이 호출이 실패해도 상관 없다"입니다. 프로그래머가 조건을 무시하는 경우 암시적으로 이 가정 중 하나에 따라 동작하는 것으로 볼 수 있습니다.

예제 1: 다음의 발췌된 코드는 CICS 트랜잭션 동안 발생할 수 있는 오류 조건을 무시합니다.

...
EXEC CICS
  INGNORE CONDITION ERROR
END-EXEC.
...

이러한 오류 조건으로 트랜잭션이 실패해도 프로그램은 아무 일도 없었던 것처럼 계속 실행됩니다. 프로그램은 특수한 상황을 나타내는 증거를 전혀 기록하지 않기 때문에 이후에 프로그램의 동작을 밝히려는 노력이 실패할 수 있습니다.

소프트웨어에 대한 대부분의 심각한 공격은 프로그래머의 가정 위반에서 비롯됩니다. 공격 후, 프로그래머의 가정은 취약하고 근거가 빈약해 보이지만 공격 전에는 많은 프로그래머가 열심히 자신의 가정을 옹호하게 마련입니다.

코드에서 흔히 발견되는 두 가지 의심스런 가정은 "이 메서드 호출은 절대 실패하지 않는다" 및 "이 호출이 실패해도 상관 없다"입니다. 프로그래머가 예외를 무시하는 경우 암시적으로 이 가정 중 하나에 따라 동작하는 것으로 볼 수 있습니다.

예제 1: 다음의 발췌된 코드는 doExchange()에서 아주 드물게 발생하는 예외 사항을 무시합니다.

try {
  doExchange();
}
catch (RareException e) {
  // this can never happen
}

RareException이 발생해도 프로그램은 아무 일도 없었던 것처럼 계속 실행됩니다. 프로그램은 특수한 상황을 나타내는 증거를 전혀 기록하지 않기 때문에 이후에 프로그램의 동작을 밝히려는 노력이 실패할 수 있습니다.

소프트웨어에 대한 대부분의 심각한 공격은 프로그래머의 가정 위반에서 비롯됩니다. 공격 후, 프로그래머의 가정은 취약하고 근거가 빈약해 보이지만 공격 전에는 많은 프로그래머가 열심히 자신의 가정을 옹호하게 마련입니다.

코드에서 흔히 발견되는 두 가지 의심스런 가정은 "이 함수 호출은 절대 실패하지 않는다" 및 "이 호출이 실패해도 상관 없다"입니다. 프로그래머가 예외를 무시하는 경우 암시적으로 이 가정 중 하나에 따라 동작하는 것으로 볼 수 있습니다.

예제 1: 다음 코드는 삽입 명령문을 실행하는 동안 발생할 수 있는 여러 가지 예외 사항들을 무시합니다.

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하여 catch 블록을 "압축"하면 특수 처리가 필요하거나 프로그램의 이 시점에서 catch되지 않아야 하는 예외 사항을 숨길 수 있습니다. 지나치게 광범위한 예외 사항을 catch하면 Java의 형식화된 예외 사항을 사용하는 의미가 사라지고 특히 프로그램이 커져서 새로운 형식의 예외 사항이 발생하기 시작하면 위험해질 수 있습니다. 새 예외 형식에는 주의를 기울이지 않기 때문입니다.

예제 1: 다음 발췌된 코드는 세 가지 형식의 예외 사항을 동일한 방식으로 처리합니다.

  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: 다음 메서드는 세 가지 형식의 예외 사항이 발생합니다.

public void doExchange()
  throws IOException, InvocationTargetException,
         SQLException {
  ...
}

코드를 다음과 같이 쓰는 것이 깔끔해 보입니다.

public void doExchange()
  throws Exception {
  ...
}

하지만 이 방법은 호출자가 발생하는 예외 사항을 이해하고 처리하는 기능을 방해합니다. 또한 doExchange()의 이후 수정 버전에서 이전 예외 사항과 다르게 처리해야 하는 새 형식의 예외 사항을 도입하는 경우 이 요구 사항을 쉽게 적용할 수 없습니다.

프로그래머는 보통 다음 세 가지 경우에 NullPointerException을 캐치(catch)합니다.

1. 프로그램에 null 포인터 역참조가 있습니다. 결과로 생기는 예외를 catch하는 것이 근본 문제를 수정하는 것보다 쉽습니다.

2. 프로그램이 명시적으로 NullPointerException을 발생시켜 오류 조건을 알립니다.

3. 코드가 예기치 않은 입력을 테스트 중인 클래스에 제공하는 테스트 프로그램(test harness)의 일부입니다.

세 가지 중 마지막 경우만 허용됩니다.

예제 1: 다음 코드는 NullPointerException을 캐치하는 오류를 범합니다.

  try {
    mysteryMethod();
  }
  catch (NullPointerException npe) {
  }

프로그래머는 보통 다음 세 가지 경우에 NullReferenceException을 캐치(catch)합니다.

1. 프로그램에 null 포인터 역참조가 있습니다. 결과로 생기는 예외를 catch하는 것이 근본 문제를 수정하는 것보다 쉽습니다.

2. 프로그램이 명시적으로 NullReferenceException을 발생시켜 오류 조건을 알립니다.

3. 코드가 예기치 않은 입력을 테스트 중인 클래스에 제공하는 테스트 프로그램(test harness)의 일부입니다.

세 가지 중 마지막 경우만 허용됩니다.

예제 1: 다음 코드는 NullReferenceException을 캐치하는 오류를 범합니다.

  try {
    MysteryMethod();
  }
  catch (NullReferenceException npe) {
  }

finally 블록에 return 문이 있으면 try 블록에서 발생하는 예외 사항이 사라질 수 있습니다.

예제 1: 다음 발췌된 코드에서 전달된 true와 함께 두 번째 doMagic 호출에서 발생한 MagicException은 호출자에게 전달되지 않습니다. 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: 다음 코드에서 stmt.close()에 대한 호출은 FileNotFoundException이 발생할 때 무시됩니다.

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. 현재 페이지를 이스케이프 처리하기 전에 예외 사항이 올바르게 처리되지 않았습니다.

소프트웨어에 대한 대부분의 심각한 공격은 프로그래머의 가정 위반에서 비롯됩니다. 공격 후, 프로그래머의 가정은 취약하고 근거가 빈약해 보이지만 공격 전에는 많은 프로그래머가 열심히 자신의 가정을 옹호하게 마련입니다.

코드에서 흔히 발견되는 두 가지 의심스런 가정은 "이 작업은 절대 실패하지 않는다" 및 "이 작업이 실패해도 상관 없다"입니다. 프로그래머가 작업에 발생할 수 있는 예외 사항을 캐치(catch)하지 못한 경우, 암시적으로 이 가정 중 하나에 따라 동작하는 것으로 볼 수 있습니다.