safe_mode가 활성화되면 safe_mode_exec_dir 옵션은 지정된 디렉터리에서만 명령을 실행하도록 PHP를 제한합니다. safe_mode_exec_dir 항목이 없으면 보안 취약점이 발생하지 않지만 이 추가 사항으로 인해 다른 취약점과 함께 공격자에 의해 익스플로이트되어 익스플로이트가 더 위험해질 수 있습니다.

open_basedir 구성 옵션이 있는 경우 이 구성 옵션은 PHP 프로그램이 php.ini에 지정된 디렉터리 트리 외부의 파일에 대해 작업을 수행하지 못하도록 합니다. 작업 디렉터리가 .으로 지정된 경우에는 공격자가 chdir()을 사용하여 작업 디렉터리를 변경할 가능성이 있습니다.

open_basedir 옵션이 전반적으로 보안에 이득이 되지만 이 옵션을 구현하면 공격자가 특정 환경에서 해당 제한 사항을 무시할 수 있는 race condition을 겪을 수 있습니다[2]. 검사 시점/사용 시점(TOCTOU) race condition은 PHP가 접근 권한 검사를 수행하는 시점과 파일을 여는 시점 사이에 존재합니다. 다른 언어의 file system race condition과 마찬가지로 이 race condition을 사용하면 공격자가 access control 검사를 통과한 파일에 대한 심볼릭 링크를 테스트에 실패한 다른 심볼릭 링크로 바꿔 보호된 파일에 대한 접근 권한을 얻을 수 있습니다.

이러한 공격에 대한 취약점은 접근 검사를 수행하는 시점과 파일을 여는 시점 사이에 발생합니다. 호출이 빈번하게 수행되더라도 오늘날의 운영 체제는 프로세스가 CPU 사용을 중단하기 전에 얼마 만큼의 코드를 실행할지 보장할 수 없습니다. 공격자는 익스플로이트에 쉽게 성공하기 위해 다양한 수법을 동원하여 기회의 폭(시간 간격)을 확대하지만 폭이 좁을 때에도 익스플로이트 시도가 성공할 때까지 여러 번 반복합니다.

register_globals 옵션을 활성화하면 PHP가 모든 EGPCS(환경, GET, POST, 쿠키 및 서버) 변수를 전역으로 등록할 수 있습니다. 이는 모든 PHP 프로그램의 모든 범위에 접근할 수 있습니다. 이 옵션을 사용하면 프로그래머가 주로 사용하는 최초 값을 조금은 알아보기 힘든 프로그램을 작성하도록 하여 시작 환경에서 예상치 못한 동작을 일으키거나 악의적인 환경에 있는 공격자에게 문을 열어주게 됩니다. register_globals가 위험한 보안 해석으로 인정되어 이 옵션은 PHP 4.2.0에서 기본적으로 비활성화되었으며 PHP 6에서는 더 이상 사용되지 않거나 제거되었습니다.

예제 1: 다음 코드는 cross-site scripting에 취약합니다. 프로그래머는 $username 값이 서버에서 제어하는 세션에서 오지만 공격자가 요청 매개 변수로 $username의 악의적인 값을 제공할 수 있다고 가정합니다. register_globals가 활성화되면 이 코드에 공격자가 전송한 악의적인 값이 생성된 동적 HTML 콘텐트로 포함됩니다.

<?php
if (isset($username)) {
    echo "Hello <b>$username</b>";
} else {
    echo "Hello <b>Guest</b><br />";
    echo "Would you like to login?";

}
?>

safe_mode 옵션은 PHP의 가장 중요한 security features 중 하나입니다. safe_mode가 비활성화되면 PHP는 이를 호출한 사용자의 권한이 있는 파일에서 동작합니다. 이는 주로 권한 있는 사용자입니다. safe_mode가 비활성화된 PHP를 구성하면 보안 취약점이 발생하지 않지만 이 추가 사항으로 인해 다른 취약점과 함께 공격자에 의해 익스플로이트되어 익스플로이트가 더 위험해질 수 있습니다.

session.use_trans_sid를 활성화하면 PHP가 URL의 세션 ID를 전달하게 됩니다. 이는 공격자가 활성 세션을 하이재킹하거나 공격자의 제어 하에 이미 기존 세션을 사용하는 사용자를 속이는 것을 더 쉽게 만듭니다.

매개변수가 브라우저 기록, 북마크, 로그 파일 및 기타 크게 노출된 위치에 자주 나타나기 때문에 URL에 전달된 매개 변수는 POST 매개 변수 및 쿠키 값보다 더 잘 보입니다. 공격자가 시스템의 활성 세션에 대한 암호 세션 ID를 아는 경우, 사용자의 세션을 하이재킹하기 위해 프로그램에 세션 ID를 제공할 수 있습니다.

세션 하이재킹 외에도 URL에서 세션 ID가 노출되면 session fixation 공격을 용이하게 합니다. Session fixation 취약점의 일반적인 익스플로이트에서 공격자는 웹 응용 프로그램에 대한 새 세션을 만들어 관련 세션 ID를 기록합니다. 그런 다음 공격자는 기록한 세션 ID를 사용하여 피해자가 서버에 대해 인증을 받도록 하고 공격자는 활성 세션을 통해 피해자의 계정에 대한 접근 권한을 얻습니다. URL에서 세션 ID를 전달하면 공격자가 전자 메일 또는 다른 대중 매체 메커니즘을 통해 손상된 세션 ID를 피해자에게 포함하는 URL을 전달하여 많은 피해를 입힐 수 있습니다.

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

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

예제 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)하지 못한 경우, 암시적으로 이 가정 중 하나에 따라 동작하는 것으로 볼 수 있습니다.

Unhandled SSL exception 취약점은 다음 경우에 발생합니다.

1. SSL 특정 예외가 발생합니다.

2. 예외 사항이 올바로 처리되지 않습니다.

SSL 특정 예외 javax.net.ssl.SSLHandshakeException, javax.net.ssl.SSLKeyException 및 javax.net.ssl.SSLPeerUnverifiedException 모두 SSL 연결과 관련된 중요한 오류를 전달합니다. 이러한 오류가 올바로 처리되지 않는 경우, 이 연결은 예상치 못한 상태 및 잠재적 불안정 상태가 될 수 있습니다.

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

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

단일 로거 개체를 특정 클래스의 모든 개체 사이에 공유하고 프로그램 기간 중 같은 로거를 사용하는 것이 좋은 프로그래밍 습관입니다.

예제 1: 다음 문은 static이 아닌 로거를 선언하는 오류를 범합니다.

private final Logger logger =
            Logger.getLogger(MyClass.class);

좋은 로깅 습관은 각 클래스마다 하나의 로거를 사용하는 것입니다.

예제 1: 다음 코드는 multiple loggers를 선언하는 오류를 범합니다.

public class MyClass {
  private final static Logger good =
            Logger.getLogger(MyClass.class);
  private final static Logger bad =
            Logger.getLogger(MyClass.class);
  private final static Logger ugly =
            Logger.getLogger(MyClass.class);
  ...
}

예제 1: 개발자가 배우는 과정에서 작성하는 첫 Java 프로그램은 다음과 같습니다.

public class MyClass
  ...
    System.out.println("hello world");
  ...
}

대부분의 프로그래머가 Java의 수많은 노하우와 세부 사항을 배우게 되지만 상당수의 프로그래머가 이 첫 수업에 집착한 나머지 System.out.println()을 사용하여 표준 출력에 메시지를 쓰는 것을 그만두지 않습니다.

문제는 표준 출력이나 표준 오류에 직접 쓰는 것이 구조화되지 않은 형식의 로깅으로 이용되는 일이 잦다는 점입니다. 구조화된 로깅 기능은 로깅 수준, 단일 서식, 로거 ID, 타임스탬프 및 무엇보다 중요한, 로그 메시지를 올바른 위치에 보내는 기능 등의 기능을 제공합니다. 시스템 출력 스트림 사용이 로거를 올바로 사용하는 코드와 혼합되면 잘 기록되긴 했지만 중요한 정보가 누락된 로그가 생성됩니다.

개발자는 구조화된 로깅의 필요성을 폭넓게 이해하지만 상당수가 "운용 전" 개발 단계에서 시스템 출력 스트림을 계속 사용합니다. 검토 중인 코드가 초기 개발 단계를 지난 경우, System.out 또는 System.err 사용이 발견되면 이는 구조화된 로깅 시스템으로 옮겨가는 도중 실수한 것일 수 있습니다.