리소스 누수는 최소한 두 가지 공통 원인이 있습니다.

- 오류 조건 및 기타 예외 상황

- 프로그램의 어떤 부분이 리소스 해제를 담당하고 있는지에 대한 혼란

대부분의 해제되지 않은 리소스 문제는 일반적으로 소프트웨어 신뢰도 문제를 일으키지만, 공격자가 의도적으로 리소스 누출을 일으킬 수 있는 경우 공격자가 리소스 풀을 고갈시켜 서비스 거부(DoS) 공격을 실행할 수 있습니다.

예제 1: 다음 코드는 데이터베이스 쿼리를 실행하지만 문 및 연결 리소스를 해제하지 않습니다.

DATA: result        TYPE demo_update,
      request       TYPE REF TO IF_HTTP_REQUEST,
      obj           TYPE REF TO CL_SQL_CONNECTION.           

TRY.
...
    obj = cl_sql_connection=>get_connection( `R/3*my_conn`).
    FINAL(sql) = NEW cl_sql_prepared_statement(
      statement = `INSERT INTO demo_update VALUES( ?, ?, ?, ?, ?, ? )`).

  CATCH cx_sql_exception INTO FINAL(exc).
    ...
ENDTRY.

리소스 누수는 최소한 두 가지 공통 원인이 있습니다.

- 오류 조건 및 기타 예외 상황

- 프로그램의 어떤 부분이 리소스 해제를 담당하고 있는지에 대한 혼란

대부분의 해제되지 않은 리소스 문제는 일반적으로 소프트웨어 신뢰도 문제를 일으키지만, 공격자가 의도적으로 리소스 누수를 일으킬 수 있는 경우 공격자가 리소스 풀을 고갈시켜 Denial of Service 공격을 실행할 수도 있습니다.

예제 1: 다음 코드는 데이터베이스 쿼리를 실행하지만 문 또는 연결 리소스를 해제하지 않습니다.

- void insertUser:(NSString *)name {
    ...
    sqlite3_stmt *insertStatement = nil;
    NSString *insertSQL = [NSString stringWithFormat:@INSERT INTO users (name, age) VALUES (?, ?)];
    const char *insert_stmt = [insertSQL UTF8String];
    ...
    if ((result = sqlite3_prepare_v2(database, insert_stmt,-1, &insertStatement, NULL)) != SQLITE_OK) {
        MyLog(@"%s: sqlite3_prepare error: %s (%d)", __FUNCTION__, sqlite3_errmsg(database), result);
        return;
    }
    if ((result = sqlite3_step(insertStatement)) != SQLITE_DONE) {
        MyLog(@"%s: step error: %s (%d)", __FUNCTION__, sqlite3_errmsg(database), result);
        return;
    } 
    ...
}

리소스 누출은 최소한 두 가지 공통 원인이 있습니다.

- 오류 조건 및 기타 예외 상황.

- 프로그램의 어떤 부분이 리소스 해제를 담당하고 있는지에 대한 혼란

대부분의 공개되지 않은 리소스 문제는 일반적인 소프트웨어 안정성 문제를 일으킵니다. 하지만 공격자가 의도적으로 리소스 누출을 일으킬 수 있는 경우 공격자가 리소스 풀을 고갈시켜 DoS(Denial of Service) 공격을 실행할 수도 있습니다.

예제 1: 일반적인 조건에서 다음 코드는 데이터베이스 쿼리를 실행하고 데이터베이스가 반환한 결과를 처리한 다음 할당된 statement 개체를 닫습니다. 하지만 SQL을 실행하거나 결과를 처리하는 동안 예외 사항이 발생하면 statement 개체는 닫히지 않습니다. 이런 일이 자주 발생하면 데이터베이스에 사용 가능한 커서가 부족하게 되어 SQL 쿼리를 더 이상 실행할 수 없습니다.

  Statement stmt = conn.createStatement();
  ResultSet rs = stmt.executeQuery(CXN_SQL);
  harvestResults(rs);
  stmt.close();

리소스 누수는 최소한 두 가지 공통 원인이 있습니다.

- 오류 조건 및 기타 예외 상황

- 프로그램의 어떤 부분이 리소스 해제를 담당하고 있는지에 대한 혼란

대부분의 해제되지 않은 리소스 문제는 일반적으로 소프트웨어 신뢰도 문제를 일으키지만, 공격자가 의도적으로 리소스 누수를 일으킬 수 있는 경우 공격자가 리소스 풀을 고갈시켜 Denial of Service 공격을 실행할 수도 있습니다.

예제 1: 다음 코드는 데이터베이스 쿼리를 실행하지만 문 및 연결 리소스를 해제하지 않습니다.

func insertUser(name:String, age:int) {
    let dbPath = URL(fileURLWithPath: Bundle.main.resourcePath ?? "").appendingPathComponent("test.sqlite").absoluteString
    
    var db: OpaquePointer?
    var stmt: OpaquePointer?

    if sqlite3_open(dbPath, &db) != SQLITE_OK {
        print("Error opening articles database.")
        return
    }
    
    let queryString = "INSERT INTO users (name, age) VALUES (?,?)"
    
    if sqlite3_prepare(db, queryString, -1, &stmt, nil) != SQLITE_OK{
        let errmsg = String(cString: sqlite3_errmsg(db)!)
        log("error preparing insert: \(errmsg)")
        return
    }

    if sqlite3_bind_text(stmt, 1, name, -1, nil) != SQLITE_OK{
        let errmsg = String(cString: sqlite3_errmsg(db)!)
        log("failure binding name: \(errmsg)")
        return
    }
    
    if sqlite3_bind_int(stmt, 2, age) != SQLITE_OK{
        let errmsg = String(cString: sqlite3_errmsg(db)!)
        log("failure binding name: \(errmsg)")
        return
    }

    if sqlite3_step(stmt) != SQLITE_DONE {
        let errmsg = String(cString: sqlite3_errmsg(db)!)
        log("failure inserting user: \(errmsg)")
        return
    }
}

프로그램이 시스템 리소스를 해제하지 못할 수도 있습니다.

리소스 누출은 최소한 두 가지 공통 원인이 있습니다.

- 오류 조건 및 기타 예외 상황.

- 프로그램의 어떤 부분이 리소스 해제를 담당하고 있는지에 대한 혼란

대부분의 공개되지 않은 리소스 문제는 일반적인 소프트웨어 안정성 문제를 일으킵니다. 하지만 공격자가 의도적으로 리소스 누출을 일으킬 수 있는 경우 공격자가 리소스 풀을 고갈시켜 DoS(Denial of Service) 공격을 실행할 수도 있습니다.

예제 1: 다음 메서드는 자신이 연 파일 핸들을 닫지 않습니다. FileInputStream의 finalize() 메서드는 결국 close()를 호출하지만 finalize() 메서드를 호출하기까지 시간이 얼마나 걸릴지 장담할 수 없습니다. 사용량이 많은 환경에서는 이로 인해 JVM이 파일 핸들을 모두 소진시키는 결과를 초래할 수도 있습니다.

private void processFile(String fName) throws FileNotFoundException, IOException {
  FileInputStream fis = new FileInputStream(fName);
  int sz;
  byte[] byteArray = new byte[BLOCK_SIZE];
  while ((sz = fis.read(byteArray)) != -1) {
    processBytes(byteArray, sz);
  }
}

프로그램이 시스템 리소스를 해제하지 못할 수도 있습니다.


리소스 누출은 최소한 두 가지 공통 원인이 있습니다.

- 오류 조건 및 기타 예외 상황.

- 프로그램의 어떤 부분이 리소스 해제를 담당하고 있는지에 대한 혼란

대부분의 공개되지 않은 리소스 문제는 일반적인 소프트웨어 안정성 문제를 일으킵니다. 하지만 공격자가 의도적으로 리소스 누출을 일으킬 수 있는 경우 공격자가 리소스 풀을 고갈시켜 DoS(Denial of Service) 공격을 실행할 수도 있습니다.

예제 1: 다음 메서드는 읽어들이는 스트림을 닫지 않습니다.

...
CFIndex numBytes;
do {
    UInt8 buf[bufferSize];
    numBytes = CFReadStreamRead(readStream, buf, sizeof(buf));
    if( numBytes > 0 ) {
        handleBytes(buf, numBytes);
    } else if( numBytes < 0 ) {
        CFStreamError error = CFReadStreamGetError(readStream);
        reportError(error);
    }
} while( numBytes > 0 );
...

프로그램이 시스템 리소스를 해제하지 못할 수도 있습니다.

리소스 누수는 최소한 두 가지 공통 원인이 있습니다.

- 오류 조건 및 기타 예외 상황

- 프로그램의 어떤 부분이 리소스 해제를 담당하고 있는지에 대한 혼란

대부분의 해제되지 않은 리소스 문제는 일반적으로 소프트웨어 신뢰도 문제를 일으키지만, 공격자가 의도적으로 리소스 누수를 일으킬 수 있는 경우 공격자가 리소스 풀을 고갈시켜 Denial of Service 공격을 실행할 수도 있습니다.

예제 1: 다음 메서드는 자신이 연 파일 핸들을 닫지 않습니다.

def readFile(filename: String): Unit = {
    val data = Source.fromFile(fileName).getLines.mkString
    // Use the data
}

프로그램이 시스템 리소스를 해제하지 못할 수도 있습니다.


리소스 누수는 최소한 두 가지 공통 원인이 있습니다.

- 오류 조건 및 기타 예외 상황

- 프로그램의 어떤 부분이 리소스 해제를 담당하고 있는지에 대한 혼란

대부분의 해제되지 않은 리소스 문제는 일반적으로 소프트웨어 신뢰도 문제를 일으키지만, 공격자가 의도적으로 리소스 누수를 일으킬 수 있는 경우 공격자가 리소스 풀을 고갈시켜 Denial of Service 공격을 실행할 수도 있습니다.

예제 1: 다음 메서드는 읽어오는 스트림을 닫지 않습니다.

...
        func leak(reading input: InputStream) {
            input.open()
            let bufferSize = 1024
            let buffer = UnsafeMutablePointer<UInt8>.allocate(capacity: bufferSize)
            while input.hasBytesAvailable {
                let read = input.read(buffer, maxLength: bufferSize)
            }
            buffer.deallocate(capacity: bufferSize)
        }
...

프로그램이 시스템 리소스를 해제하지 못할 수도 있습니다.

리소스 누출은 최소한 두 가지 공통 원인이 있습니다.

- 오류 조건 및 기타 예외 상황.

- 프로그램의 어떤 부분이 리소스 해제를 담당하고 있는지에 대한 혼란

대부분의 공개되지 않은 리소스 문제는 일반적으로 소프트웨어 안정성 문제를 일으킵니다. 하지만 공격자가 의도적으로 리소스 누출을 일으킬 수 있는 경우 공격자가 리소스 풀을 고갈시켜 DoS(Denial of Service)를 실행할 수도 있습니다.

예제 1: 다음 함수는 오류가 발생하는 경우 할당되는 조건 변수를 소멸시킵니다. 프로세스가 수명이 긴 경우 프로세스에서 파일 핸들 부족이 발생할 수 있습니다.

int helper(char* fName)
{
   int status;
   ...
   pthread_cond_init (&count_threshold_cv, NULL);
   pthread_mutex_init(&count_mutex, NULL);

   status = perform_operation();
   if (status) {
      printf("%s", "cannot perform operation");
      return OPERATION_FAIL;
   }

   pthread_mutex_destroy(&count_mutex);
   pthread_cond_destroy(&count_threshold_cv);

   return OPERATION_SUCCESS;
}

프로그램에서 잠금을 해제하지 못할 수 있습니다.

리소스 누수는 최소한 두 가지 공통 원인이 있습니다.

- 오류 조건 및 기타 예외 상황

- 프로그램의 어떤 부분이 리소스 해제를 담당하고 있는지에 대한 혼란

대부분의 해제되지 않은 리소스 문제는 일반적으로 소프트웨어 신뢰도 문제를 일으키지만, 공격자가 의도적으로 리소스 누수를 유발할 수 있는 경우 공격자는 리소스 풀을 삭제하거나 교착 상태를 야기하여 Denial of Service 공격을 시작할 수 있습니다.

예제 1: 다음 프로그램은 오류 발생 시 파일의 레코드 잠금을 해제하지 않습니다.

  CALL "CBL_GET_RECORD_LOCK"
      USING file-handle
            record-offset
            record-length
            reserved
  END-CALL

  IF return-code NOT = 0
      DISPLAY "Error!"
      GOBACK
  ELSE
      PERFORM write-data
      IF ws-status-code NOT = 0
          DISPLAY "Error!"
          GOBACK
      ELSE
           DISPLAY "Success!"
      END-IF
  END-IF

  CALL "CBL_FREE_RECORD_LOCK"
      USING file-handle
            record-offset
            record-length
            reserved
  END-CALL

  GOBACK
  .

프로그램이 시스템 리소스를 해제하지 못할 수도 있습니다.

리소스 누출은 최소한 두 가지 공통 원인이 있습니다.

- 오류 조건 및 기타 예외 상황.

- 프로그램의 어떤 부분이 리소스 해제를 담당하고 있는지에 대한 혼란

대부분의 공개되지 않은 리소스 문제는 일반적으로 소프트웨어 안정성 문제를 일으킵니다. 하지만 공격자가 의도적으로 리소스 누출을 일으킬 수 있는 경우 공격자가 리소스 풀을 고갈시켜 DoS(Denial of Service)를 실행할 수도 있습니다.

예제 1: 다음 코드는 performOperationInCriticalSection() 앞에 잠금을 설정하지만 해당 메서드에서 예외가 발생한 경우 잠금을 해제하지 못합니다.

ReentrantLock  myLock = new ReentrantLock ();

myLock.lock();
performOperationInCriticalSection();
myLock.unlock();

리소스 누수는 최소한 두 가지 공통 원인이 있습니다.

- 오류 조건 및 기타 예외 상황

- 프로그램의 어떤 부분이 리소스 해제를 담당하고 있는지에 대한 혼란

대부분의 해제되지 않은 리소스 문제는 일반적으로 소프트웨어 신뢰도 문제를 일으키지만, 공격자가 의도적으로 리소스 누수를 일으킬 수 있는 경우 공격자가 리소스 풀을 고갈시켜 Denial of Service 공격을 실행할 수도 있습니다.

예제 1: 다음 코드는 performOperationInCriticalSection() 앞에 잠금을 설정하지만 절대 해제하지 않습니다.

os_unfair_lock lock1 = OS_UNFAIR_LOCK_INIT;
os_unfair_lock_lock(&lock1);
performOperationInCriticalSection();

리소스 누수는 최소한 두 가지 공통 원인이 있습니다.

- 오류 조건 및 기타 예외 상황

- 프로그램의 어떤 부분이 리소스 해제를 담당하고 있는지에 대한 혼란

대부분의 해제되지 않은 리소스 문제는 일반적으로 소프트웨어 신뢰도 문제를 일으키지만, 공격자가 의도적으로 리소스 누수를 일으킬 수 있는 경우 공격자가 리소스 풀을 고갈시켜 Denial of Service 공격을 실행할 수도 있습니다.

예제 1: 다음 코드는 performOperationInCriticalSection() 앞에 잠금을 설정하지만 절대 해제하지 않습니다.

let lock1 = OSAllocatedUnfairLock()
lock1.lock()
performOperationInCriticalSection();

공격자가 응용 프로그램이 인스턴스화할 클래스 또는 호출할 메서드를 결정하는 데 사용할 값을 제공하게 되면 응용 프로그램을 통해 응용 프로그램 개발자가 의도하지 않은 제어 흐름 경로를 만들 가능성이 있습니다. 이 공격은 공격자가 authentication 또는 access control 검사를 무시하거나 응용 프로그램이 오작동을 일으키도록 합니다. 임의의 메서드나 생성자에게 전달되는 인수를 제어하는 기능도 교활한 공격자에게 공격을 성공시키는 데 필요한 유리한 조건을 제공할 수 있습니다.

예제 1: 프로그래머가 리플렉션 기술을 사용하는 공통된 이유는 자신만의 명령 디스패처를 구현하기 위해서입니다. 다음 예제는 리플렉션을 사용하지 않는 명령 디스패처를 보여줍니다.

    var params:Object = LoaderInfo(this.root.loaderInfo).parameters;
    var ctl:String = String(params["ctl"]);
    var ao:Worker;
    if (ctl == "Add) {
      ao = new AddCommand();
    } else if (ctl == "Modify") {
      ao = new ModifyCommand();
    } else {
      throw new UnknownActionError();
    }
    ao.doAction(params);

프로그래머가 이 코드를 다음과 같이 리플렉션을 사용하도록 리팩터링할 수 있습니다.

    var params:Object = LoaderInfo(this.root.loaderInfo).parameters;
    var ctl:String = String(params["ctl"]);
    var ao:Worker;
    var cmdClass:Class = getDefinitionByName(ctl + "Command") as Class;
    ao = new cmdClass();
    ao.doAction(params);

리팩터링은 처음에는 많은 장점이 있는 것처럼 보입니다. 코드 줄이 줄고 if/else 블록 전체가 사라질 뿐 아니라 이제는 명령 디스패처를 수정하지 않고 새 명령 유형을 추가하는 것도 가능합니다.

하지만 리팩터링은 공격자가 Worker 인터페이스를 구현하는 개체를 인스턴스화할 수 있습니다. 명령 디스패처가 access control을 계속 담당하는 경우, 프로그래머는 Worker 인터페이스를 구현하는 새 클래스를 만들 때마다 디스패처의 access control 코드를 수정해야 합니다. access control 코드를 수정하지 않으면 일부 Worker 클래스는 access control을 갖지 못합니다.

액세스 제어 문제를 해결하는 한 가지 방법은 Worker 개체가 액세스 제어 검사 수행을 담당하게 만드는 것입니다. 리팩터링된 코드의 예제는 다음과 같습니다.

    var params:Object = LoaderInfo(this.root.loaderInfo).parameters;
    var ctl:String = String(params["ctl"]);
    var ao:Worker;
    var cmdClass:Class = getDefinitionByName(ctl + "Command") as Class;
    ao = new cmdClass();
    ao.checkAccessControl(params);
    ao.doAction(params);

이 코드는 보다 개선되긴 했지만 분산된 방식으로 access control을 다루기 때문에 프로그래머가 access control 실수를 저지르기가 더 쉽습니다.

공격자는 응용 프로그램이 호출할 메서드나 인스턴스화할 클래스를 결정하는 데 사용하는 값을 제공할 수 있는 경우 응용 프로그램을 통과하는 예상치 못한 제어 흐름 경로를 생성할 수 있습니다. 그러면 인증 또는 액세스 제어 검사를 우회할 수도 있고, 응용 프로그램의 예상치 못한 동작을 야기할 수도 있습니다.

예제 1: 다음 작업 메서드는 외부 웹 서비스에 대한 비동기 요청을 시작하고 continuationMethod 속성을 설정합니다. 이 속성에 따라 응답 수신 시 호출할 메서드의 이름이 결정됩니다.

public Object startRequest() {
    Continuation con = new Continuation(40);

    Map<String,String> params = ApexPages.currentPage().getParameters();

    if (params.containsKey('contMethod')) {
        con.continuationMethod = params.get('contMethod');
    } else {
        con.continuationMethod = 'processResponse';
    }

    HttpRequest req = new HttpRequest();
    req.setMethod('GET');
    req.setEndpoint(LONG_RUNNING_SERVICE_URL);
    this.requestLabel = con.addHttpRequest(req);
    return con;
}

이 구현에서는 런타임 요청 매개변수로 continuationMethod 속성을 설정할 수 있으므로 공격자가 이름이 일치하는 어떤 함수든 호출할 수 있게 됩니다.

공격자가 응용 프로그램이 인스턴스화할 클래스 또는 호출할 메서드를 결정하는 데 사용할 값을 제공하게 되면 응용 프로그램을 통해 응용 프로그램 개발자가 의도하지 않은 제어 흐름 경로를 만들 가능성이 있습니다. 이 공격은 공격자가 authentication 또는 access control 검사를 무시하거나 응용 프로그램이 오작동을 일으키도록 합니다.

이런 상황은 공격자가 응용 프로그램 경로 또는 라이브러리 경로에 있는 위치에 파일을 업로드하게 되면 최악의 시나리오가 됩니다. 어느 쪽이든 공격자는 리플렉션을 사용하여 응용 프로그램에 새로운 악의적인 동작을 주입할 수 있습니다.
예제 1: 프로그래머가 리플렉션 API를 사용하는 공통된 이유는 자신만의 명령 디스패처를 구현하기 위해서입니다. 다음 예제는 리플렉션을 사용하여 CGI 요청에서 읽은 값으로 식별하는 Java 메서드를 실행하는 JNI 명령 디스패처를 보여줍니다. 이 구현으로 공격자는 clazz에 정의된 함수를 호출할 수 있습니다.

char* ctl = getenv("ctl");
...
jmethodID mid = GetMethodID(clazz, ctl, sig);
status = CallIntMethod(env, clazz, mid, JAVA_ARGS);
...

공격자가 응용 프로그램이 호출할 메서드 또는 검색할 필드 값을 결정하는 데 사용하는 값을 제공할 수 있는 경우 공격자는 응용 프로그램 개발자가 의도하지 않은 응용 프로그램을 통해 제어 흐름 경로를 생성할 잠재적 가능성이 있습니다. 이러한 공격은 인증 또는 액세스 제어 검사를 우회할 수도 있는 등 응용 프로그램의 예상치 못한 동작을 야기할 수도 있습니다.

예제 1: 이 예제에서 응용 프로그램은 명령줄 인수에서 호출할 함수의 이름을 검색합니다.

...
    func beforeExampleCallback(scope *Scope){
        input := os.Args[1]
        if input{
            scope.CallMethod(input)
        }
    }
...
    

예제 2: 이전 예제와 유사하게 응용 프로그램은 명령줄 인수에서 호출할 함수의 이름을 검색하기 위해 reflect 패키지를 사용합니다.

...
    input := os.Args[1]
	var worker WokerType
	reflect.ValueOf(&worker).MethodByName(input).Call([]reflect.Value{})
...

공격자가 응용 프로그램이 인스턴스화할 클래스 또는 호출할 메서드를 결정하는 데 사용할 값을 제공하게 되면 응용 프로그램을 통해 응용 프로그램 개발자가 의도하지 않은 제어 흐름 경로를 만들 가능성이 있습니다. 이 공격은 공격자가 authentication 또는 access control 검사를 무시하거나 응용 프로그램이 오작동을 일으키도록 합니다. 임의의 메서드나 생성자에게 전달되는 인수를 제어하는 기능도 교활한 공격자에게 공격을 성공시키는 데 필요한 유리한 조건을 제공할 수 있습니다.

이런 상황은 공격자가 응용 프로그램의 classpath에 있는 위치에 파일을 업로드하거나 응용 프로그램의 classpath에 새 항목을 추가하게 되면 최악의 시나리오가 됩니다. 어느 쪽이든 공격자는 리플렉션을 사용하여 응용 프로그램에 새로운 악의적인 동작을 주입할 수 있습니다.
예제 1: 프로그래머가 리플렉션 API를 사용하는 공통된 이유는 자신만의 명령 디스패처를 구현하기 위해서입니다. 다음 예제는 리플렉션을 사용하지 않는 명령 디스패처를 보여줍니다.

String ctl = request.getParameter("ctl");
Worker ao = null;
if (ctl.equals("Add")) {
  ao = new AddCommand();
} else if (ctl.equals("Modify")) {
  ao = new ModifyCommand();
} else {
  throw new UnknownActionError();
}
ao.doAction(request);

프로그래머가 이 코드를 다음과 같이 리플렉션을 사용하도록 리팩터링할 수 있습니다.

    String ctl = request.getParameter("ctl");
    Class cmdClass = Class.forName(ctl + "Command");
    Worker ao = (Worker) cmdClass.newInstance();
    ao.doAction(request);

리팩터링은 처음에는 많은 장점이 있는 것처럼 보입니다. 코드 줄이 줄고 if/else 블록 전체가 사라질 뿐 아니라 이제는 명령 디스패처를 수정하지 않고 새 명령 유형을 추가하는 것도 가능합니다.

하지만 리팩터링은 공격자가 Worker 인터페이스를 구현하는 개체를 인스턴스화할 수 있습니다. 명령 디스패처가 access control을 계속 담당하는 경우, 프로그래머는 Worker 인터페이스를 구현하는 새 클래스를 만들 때마다 디스패처의 access control 코드를 수정해야 합니다. access control 코드를 수정하지 않으면 일부 Worker 클래스는 access control을 갖지 못합니다.

액세스 제어 문제를 해결하는 한 가지 방법은 Worker 개체가 액세스 제어 검사 수행을 담당하게 만드는 것입니다. 리팩터링된 코드의 예제는 다음과 같습니다.

String ctl = request.getParameter("ctl");
Class cmdClass = Class.forName(ctl + "Command");
Worker ao = (Worker) cmdClass.newInstance();
ao.checkAccessControl(request);
ao.doAction(request);

이 코드는 보다 개선되긴 했지만 분산된 방식으로 access control을 다루기 때문에 프로그래머가 access control 실수를 저지르기가 더 쉽습니다.

또한 이 코드는 리플렉션을 사용하여 명령 디스패처를 작성하는 데서 또 다른 보안 문제를 야기합니다. 공격자가 모든 종류의 개체에 대해 기본 생성자를 호출할 수 있습니다. 실제로 공격자는 Worker 인터페이스를 구현하는 개체에만 국한되어 있는 것은 아닙니다. 시스템의 모든 개체의 기본 생성자를 호출할 수 있습니다. 개체가 Worker 인터페이스를 구현하지 않는 경우 ClassCastException이 ao에 할당되기 전에 발생하지만 생성자가 공격자에게 유리한 작업을 수행하는 경우 이미 피해를 입은 것입니다. 이 시나리오는 간단한 응용 프로그램에서는 비교적 피해 정도가 약하지만 아주 복잡한 큰 응용 프로그램에서는 공격자가 얼마든지 생성자를 찾아 공격 도구로 이용할 수 있습니다.

즉각적인 호출자의 클래스 로더 검사 사용 작업을 수행하는 특정 Java API가 리플렉션 호출로 인해 반환된 신뢰할 수 없는 개체에서 호출되는 경우 접근 검사가 코드 실행 체인을 더욱 손상시킬수도 있습니다. 이러한 Java API는 실행 체인의 모든 호출자가 필요한 보안 권한을 갖도록 보장하는 SecurityManager 검사를 무시합니다. 리플렉션에 의해 반환된 신뢰할 수 없는 개체에서 API가 호출되지 않도록 주의해야 합니다. 이러한 API는 보안 접근 검사를 무시하고 시스템이 원격 공격에 취약해지도록 할 수 있기 때문입니다. 이러한 Java API에 대한 자세한 내용은 Secure Coding Guidelines for the Java Programming Language의 Guideline 9를 참조하십시오.

공격자가 응용 프로그램이 인스턴스화할 클래스 또는 호출할 메서드를 결정하는 데 사용할 값을 제공하게 되면 응용 프로그램을 통해 응용 프로그램 개발자가 의도하지 않은 제어 흐름 경로를 만들 가능성이 있습니다. 이 공격은 공격자가 authentication 또는 access control 검사를 무시하거나 응용 프로그램이 오작동을 일으키도록 합니다.

예제 1: 프로그래머가 선택기 API를 사용하는 일반적인 이유는 자신만의 명령 디스패처를 구현하기 위해서입니다. 다음 예제는 리플렉션을 사용하여 사용자 지정 URL 스키마 요청에서 읽은 값으로 식별하는 임의의 메서드를 실행하는 Objective-C 명령 디스패처를 보여 줍니다. 이 구현으로 공격자는 UIApplicationDelegate 클래스에 정의된 메서드 서명과 일치하는 함수를 호출할 수 있습니다.

...
- (BOOL)application:(UIApplication *)application openURL:(NSURL *)url
  sourceApplication:(NSString *)sourceApplication annotation:(id)annotation  {

    NSString *query = [url query];
    NSString *pathExt = [url pathExtension];
    [self performSelector:NSSelectorFromString(pathExt) withObject:query];
...

공격자가 응용 프로그램이 인스턴스화할 클래스 또는 호출할 메서드를 결정하는 데 사용할 값을 제공하게 되면 응용 프로그램을 통해 응용 프로그램 개발자가 의도하지 않은 제어 흐름 경로를 만들 가능성이 있습니다. 이 공격은 공격자가 authentication 또는 access control 검사를 무시하거나 응용 프로그램이 오작동을 일으키도록 합니다. 임의의 메서드나 생성자에게 전달되는 인수를 제어하는 기능도 교활한 공격자에게 공격을 성공시키는 데 필요한 유리한 조건을 제공할 수 있습니다.

이런 상황은 공격자가 응용 프로그램의 classpath에 있는 위치에 파일을 업로드하거나 응용 프로그램의 classpath에 새 항목을 추가하게 되면 최악의 시나리오가 됩니다. 어느 쪽이든 공격자는 리플렉션을 사용하여 응용 프로그램에 새로운 악의적인 동작을 주입할 수 있습니다.
예제 1: 프로그래머가 리플렉션 API를 사용하는 공통된 이유는 자신만의 명령 디스패처를 구현하기 위해서입니다. 다음 예제는 리플렉션을 사용하지 않는 명령 디스패처를 보여줍니다.

$ctl = $_GET["ctl"];
$ao = null;
if (ctl->equals("Add")) {
  $ao = new AddCommand();
} else if ($ctl.equals("Modify")) {
  $ao = new ModifyCommand();
} else {
  throw new UnknownActionError();
}
$ao->doAction(request);

프로그래머가 이 코드를 다음과 같이 리플렉션을 사용하도록 리팩터링할 수 있습니다.

    $ctl = $_GET["ctl"];
    $args = $_GET["args"];
    $cmdClass = new ReflectionClass(ctl . "Command");
    $ao = $cmdClass->newInstance($args);
    $ao->doAction(request);

리팩터링은 처음에는 많은 장점이 있는 것처럼 보입니다. 코드 줄이 줄고 if/else 블록 전체가 사라질 뿐 아니라 이제는 명령 디스패처를 수정하지 않고 새 명령 유형을 추가하는 것도 가능합니다.

하지만 리팩터링은 공격자가 Worker 인터페이스를 구현하는 개체를 인스턴스화할 수 있습니다. 명령 디스패처가 access control을 계속 담당하는 경우, 프로그래머는 Worker 인터페이스를 구현하는 새 클래스를 만들 때마다 디스패처의 access control 코드를 수정해야 합니다. access control 코드를 수정하지 않으면 일부 Worker 클래스는 access control을 갖지 못합니다.

액세스 제어 문제를 해결하는 한 가지 방법은 Worker 개체가 액세스 제어 검사 수행을 담당하게 만드는 것입니다. 리팩터링된 코드의 예제는 다음과 같습니다.

	$ctl = $_GET["ctl"];
    $args = $_GET["args"];
    $cmdClass = new ReflectionClass(ctl . "Command");
    $ao = $cmdClass->newInstance($args);
	$ao->checkAccessControl(request);
	ao->doAction(request);

이 코드는 보다 개선되긴 했지만 분산된 방식으로 access control을 다루기 때문에 프로그래머가 access control 실수를 저지르기가 더 쉽습니다.

또한 이 코드는 리플렉션을 사용하여 명령 디스패처를 작성하는 데서 또 다른 보안 문제를 야기합니다. 공격자가 모든 종류의 개체에 대해 기본 생성자를 호출할 수 있습니다. 실제로 공격자는 Worker 인터페이스를 구현하는 개체에만 국한되어 있는 것은 아닙니다. 시스템의 모든 개체의 기본 생성자를 호출할 수 있습니다. 개체가 Worker 인터페이스를 구현하지 않는 경우 ClassCastException이 $ao에 할당되기 전에 발생하지만 생성자가 공격자에게 유리한 작업을 수행하는 경우 이미 피해를 입은 것입니다. 이 시나리오는 간단한 응용 프로그램에서는 비교적 피해 정도가 약하지만 아주 복잡한 큰 응용 프로그램에서는 공격자가 얼마든지 생성자를 찾아 공격 도구로 이용할 수 있습니다.

공격자가 응용 프로그램이 인스턴스화할 클래스 또는 호출할 메서드를 결정하는 데 사용할 값을 제공하게 되면 응용 프로그램을 통해 응용 프로그램 개발자가 의도하지 않은 제어 흐름 경로를 만들 가능성이 있습니다. 이 공격은 공격자가 authentication 또는 access control 검사를 무시하거나 응용 프로그램이 오작동을 일으키도록 합니다. 임의의 메서드나 생성자에게 전달되는 인수를 제어하는 기능도 교활한 공격자에게 공격을 성공시키는 데 필요한 유리한 조건을 제공할 수 있습니다.

이런 상황은 공격자가 응용 프로그램의 classpath에 있는 위치에 파일을 업로드하거나 응용 프로그램의 classpath에 새 항목을 추가하게 되면 최악의 시나리오가 됩니다. 어느 쪽이든 공격자는 리플렉션을 사용하여 응용 프로그램에 새로운 악의적인 동작을 주입할 수 있습니다.

공격자가 응용 프로그램이 인스턴스화할 클래스 또는 호출할 메서드를 결정하는 데 사용할 값을 제공하게 되면 응용 프로그램을 통해 응용 프로그램 개발자가 의도하지 않은 제어 흐름 경로를 만들 가능성이 있습니다. 이 공격은 공격자가 authentication을 우회하거나, access control 검사를 우회하거나, 응용 프로그램이 오작동을 일으키도록 합니다. 임의의 메서드나 생성자에게 전달되는 인수를 제어하는 기능도 교활한 공격자에게 공격을 성공시키는 데 필요한 유리한 조건을 제공할 수 있습니다.

이런 상황은 공격자가 응용 프로그램의 로드 경로에 있는 위치에 파일을 업로드하거나 응용 프로그램의 로드 경로에 새 항목을 추가하게 되면 최악의 시나리오가 됩니다. 어느 쪽이든 공격자는 리플렉션을 사용하여 응용 프로그램에 새로운 악의적인 동작을 주입할 수 있습니다.
예제 1: 프로그래머가 리플렉션을 사용하는 공통된 이유는 자신만의 명령 디스패처를 구현하기 위해서입니다. 다음 예제는 리플렉션을 사용하지 않는 명령 디스패처를 보여줍니다.

ctl = req['ctl']
if ctl=='add'
  addCommand(req)
elsif ctl=='modify'
  modifyCommand(req)
else
  raise UnknownCommandError.new
end

프로그래머가 이 코드를 다음과 같이 리플렉션을 사용하도록 리팩터링할 수 있습니다.

ctl = req['ctl']
ctl << "Command"
send(ctl)

리팩터링은 처음에는 많은 장점이 있는 것처럼 보입니다. 코드 줄이 줄고 if/else 블록 전체가 사라질 뿐 아니라 이제는 명령 디스패처를 수정하지 않고 새 명령 유형을 추가하는 것도 가능합니다.

하지만 리팩터링은 공격자가 "Command"라는 단어로 끝나는 모든 메서드를 실행할 수 있도록 허용합니다. 명령 디스패처가 access control을 계속 담당하는 경우, 프로그래머는 "Command"로 끝나는 새 메서드를 만들 때마다 디스패처의 access control 코드를 수정해야 합니다. 그런 뒤에도 이름이 비슷한 여러 메서드를 사용할 때의 일반적인 형태는 define_method()를 사용하여 이러한 메서드를 동적으로 생성하거나 missing_method()의 오버라이드를 통해 이를 호출하는 것입니다. 이를 감사 및 추적하고 access control 코드를 여기에 사용하는 방법은 매우 까다롭고 어떤 다른 라이브러리 코드가 로드되는지에 따라 달라진다는 점을 고려하면 이 방식은 올바르게 수행하기가 거의 불가능할 수 있습니다.

공격자가 응용 프로그램이 인스턴스화할 클래스 또는 호출할 메서드를 결정하는 데 사용할 값을 제공하게 되면 응용 프로그램을 통해 응용 프로그램 개발자가 의도하지 않은 제어 흐름 경로를 만들 가능성이 있습니다. 이 공격은 공격자가 authentication 또는 access control 검사를 무시하거나 응용 프로그램이 오작동을 일으키도록 합니다. 임의의 메서드나 생성자에게 전달되는 인수를 제어하는 기능도 교활한 공격자에게 공격을 성공시키는 데 필요한 유리한 조건을 제공할 수 있습니다.

이런 상황은 공격자가 응용 프로그램의 classpath에 있는 위치에 파일을 업로드하거나 응용 프로그램의 classpath에 새 항목을 추가하게 되면 최악의 시나리오가 됩니다. 어느 쪽이든 공격자는 리플렉션을 사용하여 응용 프로그램에 새로운 악의적인 동작을 주입할 수 있습니다.
예제 1: 프로그래머가 리플렉션 API를 사용하는 공통된 이유는 자신만의 명령 디스패처를 구현하기 위해서입니다. 다음 예제는 리플렉션을 사용하는 명령 디스패처를 보여줍니다.

def exec(ctl: String) = Action { request =>
    val cmdClass = Platform.getClassForName(ctl + "Command")
    Worker ao = (Worker) cmdClass.newInstance()
    ao.doAction(request)
    ...
}

리팩터링은 처음에는 많은 장점이 있는 것처럼 보입니다. 코드 줄이 줄고 if/else 블록 전체가 사라질 뿐 아니라 이제는 명령 디스패처를 수정하지 않고 새 명령 유형을 추가하는 것도 가능합니다.

하지만 리팩터링은 공격자가 Worker 인터페이스를 구현하는 개체를 인스턴스화할 수 있습니다. 명령 디스패처가 access control을 계속 담당하는 경우, 프로그래머는 Worker 인터페이스를 구현하는 새 클래스를 만들 때마다 디스패처의 access control 코드를 수정해야 합니다. access control 코드를 수정하지 않으면 일부 Worker 클래스는 access control을 갖지 못합니다.

액세스 제어 문제를 해결하는 한 가지 방법은 Worker 개체가 액세스 제어 검사 수행을 담당하게 만드는 것입니다. 리팩터링된 코드의 예제는 다음과 같습니다.

def exec(ctl: String) = Action { request =>
    val cmdClass = Platform.getClassForName(ctl + "Command")
    Worker ao = (Worker) cmdClass.newInstance()
    ao.checkAccessControl(request);
    ao.doAction(request)
    ...
}

이 코드는 보다 개선되긴 했지만 분산된 방식으로 access control을 다루기 때문에 프로그래머가 access control 실수를 저지르기가 더 쉽습니다.

또한 이 코드는 리플렉션을 사용하여 명령 디스패처를 작성하는 데서 또 다른 보안 문제를 야기합니다. 공격자가 모든 종류의 개체에 대해 기본 생성자를 호출할 수 있습니다. 실제로 공격자는 Worker 인터페이스를 구현하는 개체에만 국한되어 있는 것은 아닙니다. 시스템의 모든 개체의 기본 생성자를 호출할 수 있습니다. 개체가 Worker 인터페이스를 구현하지 않는 경우 ClassCastException이 ao에 할당되기 전에 발생하지만 생성자가 공격자에게 유리한 작업을 수행하는 경우 이미 피해를 입은 것입니다. 이 시나리오는 간단한 응용 프로그램에서는 비교적 피해 정도가 약하지만 아주 복잡한 큰 응용 프로그램에서는 공격자가 얼마든지 생성자를 찾아 공격 도구로 이용할 수 있습니다.

즉각적인 호출자의 클래스 로더 검사 사용 작업을 수행하는 특정 Java API가 리플렉션 호출로 인해 반환된 신뢰할 수 없는 개체에서 호출되는 경우 접근 검사가 코드 실행 체인을 더욱 손상시킬 수도 있습니다. 이러한 Java API는 실행 체인의 모든 호출자가 필요한 보안 권한을 갖도록 보장하는 SecurityManager 검사를 무시합니다. 리플렉션에 의해 반환된 신뢰할 수 없는 개체에서 API가 호출되지 않도록 주의해야 합니다. 이러한 API는 보안 접근 검사를 무시하고 시스템이 원격 공격에 취약해지도록 할 수 있기 때문입니다. 이러한 Java API에 대한 자세한 내용은 Secure Coding Guidelines for the Java Programming Language의 Guideline 9를 참조하십시오.

공격자가 응용 프로그램이 인스턴스화할 클래스 또는 호출할 메서드를 결정하는 데 사용할 값을 제공하게 되면 응용 프로그램을 통해 응용 프로그램 개발자가 의도하지 않은 제어 흐름 경로를 만들 가능성이 있습니다. 이 공격은 공격자가 authentication 또는 access control 검사를 무시하거나 응용 프로그램이 오작동을 일으키도록 합니다.

예제 1: 프로그래머가 선택기 API를 사용하는 일반적인 이유는 자신만의 명령 디스패처를 구현하기 위해서입니다. 다음 예제는 리플렉션을 사용하여 사용자 지정 URL 스키마 요청에서 읽은 값으로 식별하는 임의의 메서드를 실행하는 Swift 명령 디스패처를 보여 줍니다. 이 구현으로 공격자는 UIApplicationDelegate 클래스에 정의된 메서드 서명과 일치하는 함수를 호출할 수 있습니다.

func application(app: UIApplication, openURL url: NSURL, options: [String : AnyObject]) -> Bool {
    ...
    let query = url.query
    let pathExt = url.pathExtension
    let selector = NSSelectorFromString(pathExt!)
    performSelector(selector, withObject:query)
    ...
}

공격자가 응용 프로그램이 인스턴스화할 클래스 또는 호출할 메서드를 결정하는 데 사용할 값을 제공하게 되면 응용 프로그램을 통해 응용 프로그램 개발자가 의도하지 않은 제어 흐름 경로를 만들 가능성이 있습니다. 이 공격은 공격자가 authentication 또는 access control 검사를 무시하거나 응용 프로그램이 오작동을 일으키도록 합니다. 임의의 메서드나 생성자에게 전달되는 인수를 제어하는 기능도 교활한 공격자에게 공격을 성공시키는 데 필요한 유리한 조건을 제공할 수 있습니다.

예제 1: 프로그래머가 CallByName을 사용하는 공통된 이유는 자신만의 명령 디스패처를 구현하기 위해서입니다. 다음 예제는 CallByName 함수를 사용하지 않는 명령 디스패처를 보여줍니다.

...
Dim ctl As String
Dim ao As new Worker
ctl = Request.Form("ctl")
If String.Compare(ctl,"Add") = 0 Then
	ao.DoAddCommand Request
Else If String.Compare(ctl,"Modify") = 0 Then
	ao.DoModifyCommand Request
Else
	App.EventLog "No Action Found", 4
End If
...

프로그래머가 이 코드를 다음과 같이 리플렉션을 사용하도록 리팩터링할 수 있습니다.

...
Dim ctl As String
Dim ao As Worker
ctl = Request.Form("ctl")
CallByName ao, ctl, vbMethod, Request
...

리팩터링은 처음에는 많은 장점이 있는 것처럼 보입니다. 코드 줄이 줄고 if/else 블록 전체가 사라질 뿐 아니라 이제는 명령 디스패처를 수정하지 않고 새 명령 유형을 추가하는 것도 가능합니다.

하지만 리팩터링은 공격자가 Worker 개체에 의해 구현되는 메서드를 호출할 수 있습니다. 명령 디스패처가 access control을 계속 담당하는 경우, 프로그래머는 Worker 클래스 내의 새 메서드를 만들 때마다 디스패처의 access control 코드를 수정해야 합니다. access control 코드를 수정하지 않으면 일부 Worker 메서드는 access control을 갖지 못합니다.

액세스 제어 문제를 해결하는 한 가지 방법은 Worker 개체가 액세스 제어 검사 수행을 담당하게 만드는 것입니다. 리팩터링된 코드의 예제는 다음과 같습니다.

...
Dim ctl As String
Dim ao As Worker
ctl = Request.Form("ctl")
If ao.checkAccessControl(ctl,Request) = True Then
	CallByName ao, "Do" & ctl & "Command", vbMethod, Request
End If
...

이 코드는 보다 개선되긴 했지만 분산된 방식으로 access control을 다루기 때문에 프로그래머가 access control 실수를 저지르기가 더 쉽습니다.