資源洩漏至少有兩種常見原因：

- 錯誤條件以及其他異常情況。

- 不確定程式的哪一部份負責釋放資源。

大部分的 Unreleased Resource 問題都會導致一般軟體可靠性問題。但如果攻擊者蓄意觸發資源洩漏，就可以藉由耗盡資源集區的方式來發動 Denial of Service 攻擊。

範例 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.

資源洩漏至少有兩種常見原因：

- 錯誤條件以及其他異常情況。

- 不確定程式的哪一部份負責釋放資源。

大部分的 Unreleased Resource 問題都會導致一般軟體可靠性問題，但是如果攻擊者蓄意觸發資源洩漏的話，攻擊者就可能會藉由耗盡資源集區的方式來發動 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;
    } 
    ...
}

資源洩漏至少有兩種常見原因：

- 錯誤條件以及其他異常情況。

- 不確定程式的哪一部份負責釋放資源。

大部分的 Unreleased Resource 問題都會導致一般軟體可靠性問題，但是如果攻擊者蓄意觸發資源洩漏的話，攻擊者就可能會藉由耗盡資源集區的方式來發動 Denial of Service 攻擊。

範例 1：在正常條件下，以下程式碼會執行資料庫查詢，處理資料庫回傳的結果，最後關閉已配置的陳述式物件。但是如果在執行 SQL 或處理結果時發生異常，則不會關閉陳述式物件。如果這種情況時常發生的話，那麼資料庫將會用盡可用指標，並且無法再執行任何 SQL 查詢。

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

資源洩漏至少有兩種常見原因：

- 錯誤條件以及其他異常情況。

- 不確定程式的哪一部份負責釋放資源。

大部分的 Unreleased Resource 問題都會導致一般軟體可靠性問題，但是如果攻擊者蓄意觸發資源洩漏的話，攻擊者就可能會藉由耗盡資源集區的方式來發動 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
    }
}

程式可能會無法釋出系統資源。

資源洩漏至少有兩種常見原因：

- 錯誤條件以及其他異常情況。

- 不確定程式的哪一部份負責釋放資源。

大部分的 Unreleased Resource 問題都會導致一般軟體可靠性問題，但是如果攻擊者蓄意觸發資源洩漏的話，攻擊者就可能會藉由耗盡資源集區的方式來發動 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);
  }
}

程式可能會無法釋出系統資源。


資源洩漏至少有兩種常見原因：

- 錯誤條件以及其他異常情況。

- 不確定程式的哪一部份負責釋放資源。

大部分的 Unreleased Resource 問題都會導致一般軟體可靠性問題，但是如果攻擊者蓄意觸發資源洩漏的話，攻擊者就可能會藉由耗盡資源集區的方式來發動 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 );
...

程式可能會無法釋出系統資源。

資源洩漏至少有兩種常見原因：

- 錯誤條件以及其他異常情況。

- 不確定程式的哪一部份負責釋放資源。

大部分的 Unreleased Resource 問題都會導致一般軟體可靠性問題，但是如果攻擊者蓄意觸發資源洩漏的話，攻擊者就可能會藉由耗盡資源集區的方式來發動 Denial of Service 攻擊。

範例 1：下列方法絕對不會關閉它所開啟的檔案控制碼。

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

程式可能會無法釋出系統資源。


資源洩漏至少有兩種常見原因：

- 錯誤條件以及其他異常情況。

- 不確定程式的哪一部份負責釋放資源。

大部分的 Unreleased Resource 問題都會導致一般軟體可靠性問題，但是如果攻擊者蓄意觸發資源洩漏的話，攻擊者就可能會藉由耗盡資源集區的方式來發動 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)
        }
...

程式可能會無法釋出系統資源。

資源洩漏至少有兩種常見原因：

- 錯誤條件以及其他異常情況。

- 不確定程式的哪一部份負責釋放資源。

大部分的 Unreleased Resource 問題都會導致一般軟體可靠性問題，但是如果攻擊者蓄意觸發資源洩漏的話，攻擊者就可能會藉由耗盡資源集區的方式來發動 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;
}

程式可能會無法釋放鎖定。

資源洩漏至少有兩種常見原因：

- 錯誤條件以及其他異常情況。

- 不確定程式的哪一部分負責釋放資源。

大部分的 Unreleased Resource 問題都會導致一般軟體可靠性問題，如果攻擊者蓄意觸發資源洩漏的話，就可能會藉由耗盡資源集區的方式來發動 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
  .

程式可能會無法釋出系統資源。

資源洩漏至少有兩種常見原因：

- 錯誤條件以及其他異常情況。

- 不確定程式的哪一部份負責釋放資源。

大部分的 Unreleased Resource 問題都會導致一般軟體可靠性問題，但是如果攻擊者蓄意觸發資源洩漏的話，攻擊者就可能會藉由耗盡資源集區的方式來發動 Denial of Service。

範例 1：下列程式碼在 performOperationInCriticalSection() 之前建立鎖定，但如果該方法拋出異常，就無法釋放該鎖定。

ReentrantLock  myLock = new ReentrantLock ();

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

資源洩漏至少有兩種常見原因：

- 錯誤條件以及其他異常情況。

- 不確定程式的哪一部份負責釋放資源。

大部分的 Unreleased Resource 問題都會導致一般軟體可靠性問題。如果攻擊者蓄意觸發資源洩漏的話，就可以藉由耗盡資源集區的方式來發動 Denial of Service 攻擊。

範例 1：以下程式碼在 performOperationInCriticalSection() 之前建立鎖定，但從未釋放該鎖定。

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

資源洩漏至少有兩種常見原因：

- 錯誤條件以及其他異常情況。

- 不確定程式的哪一部份負責釋放資源。

大部分的 Unreleased Resource 問題都會導致一般軟體可靠性問題。如果攻擊者蓄意觸發資源洩漏的話，就可以藉由耗盡資源集區的方式來發動 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：以下動作方法向外部 Web 服務發起非同步要求，並設定 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 的常見原因是為了實作自己的指令發送器。以下範例顯示使用反映的 JNI 指令發送器從 CGI 要求中讀取數值來執行 Java 方法。執行此程式碼使得攻擊者可以呼叫任何在 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 檢查，或者使得應用程式以無法預期的方式運作。即使可以控制傳送給指定方法或建構函式的引數，老謀深算的攻擊者還是可能會取得成功發動攻擊的必要條件。

如果攻擊者可能將檔案上傳到應用程式的類別路徑中的位置，或將新項目新增到應用程式的類別路徑，則將導致應用程式陷入完全的困境。無論是以上哪種情況，攻擊者可能使用反映作用，將新的、可能的惡意行為引入應用程式。
範例 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 介面，將會在指派到 ao 之前拋出 ClassCastException。但是如果建構函式執行了有利於攻擊者的作業，則傷害可能已經造成。雖然這種情況在簡易的應用程式中的影響相對不大，但是對於日趨複雜的較大型應用程式而言，做出攻擊者可以找到一個建構函式來作為攻擊一部分的假設也十分合理。

如果使用即時呼叫者的類別載入器檢查執行工作的特定 Java API，是針對反映呼叫返回的不可信賴物件而叫用，存取檢查可能會在程式碼執行鏈中進一步受到危害。這些 Java API 會略過 SecurityManager 檢查，確保執行鏈中的所有呼叫者都具備必要的安全權限。請注意，應確保不針對反映呼叫返回的不可信賴物件叫用這些 API，因為他們會略過安全存取檢查，從而使系統易於受遠端攻擊者的攻擊。如需有關這些 Java API 的詳細資訊，請參閱適用於 Java 程式語言的安全編碼規範之第 9 條。

如果攻擊者可以提供值，且應用程式會使用這些值來決定要個體化的類別或要叫用的方法，那麼攻擊者就可能可以透過應用程式，建立非應用程式開發者指定的控制流路徑。這種攻擊途徑可能會讓攻擊者避開 Authentication 或 Access Control 檢查，或者使得應用程式以無法預期的方式運作。

範例 1：程式設計師使用選取器 API 的常見原因是為了執行自己的指令發送器。以下範例顯示使用反映的 Objective-C 指令發送器從自訂 URL 架構要求中讀取一個數值來執行任意方法。執行此程式碼可讓攻擊者呼叫任何符合 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 檢查，或者使得應用程式以無法預期的方式運作。即使可以控制傳送給指定方法或建構函式的引數，老謀深算的攻擊者還是可能會取得成功發動攻擊的必要條件。

如果攻擊者可能將檔案上傳到應用程式的類別路徑中的位置，或將新項目新增到應用程式的類別路徑，則將導致應用程式陷入完全的困境。無論是以上哪種情況，攻擊者可能使用反映作用，將新的、可能的惡意行為引入應用程式。
範例 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 介面，將會在指派到 $ao 之前拋出 ClassCastException。但是如果建構函式執行了有利於攻擊者的作業，則傷害可能已經造成。雖然這種情況在簡易的應用程式中的影響相對不大，但是對於日趨複雜的較大型應用程式而言，做出攻擊者可以找到一個建構函式來作為攻擊一部分的假設也十分合理。

如果攻擊者可以提供值，且應用程式會使用這些值來決定要個體化的類別或要叫用的方法，那麼攻擊者就可能可以透過應用程式，建立非應用程式開發者指定的控制流路徑。這種攻擊途徑可能會讓攻擊者避開 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" 結束的方法。如果指令發送器仍然負責存取控制，那麼無論程式設計師何時建立以 "Command" 結束的新方法，他們都必須記得要去修改發送器的存取控制程式碼。即使這樣，如果您有多個命名類似的方法，常見的作法是使用 define_method() 動態建立這些方法，或可透過取代 missing_method() 來呼叫這些方法。很難稽核和追蹤這些方法以及存取控制程式碼與之搭配使用的方式，考慮執行這些作業的時間取決於載入的其他程式庫程式碼，因此，想要以此種方式正確地執行這些作業更是難上加難。

如果攻擊者可以提供值，且應用程式會使用這些值來決定要個體化的類別或要叫用的方法，那麼攻擊者就可能可以透過應用程式，建立非應用程式開發者指定的控制流路徑。這種攻擊途徑可能會讓攻擊者避開驗證或存取控制檢查，或者使得應用程式以無法預期的方式運作。即使可以控制傳送給指定方法或建構函式的引數，老謀深算的攻擊者還是可能會取得成功發動攻擊的必要條件。

如果攻擊者可能將檔案上傳到應用程式的類別路徑中的位置，或將新項目新增到應用程式的類別路徑，則將導致應用程式陷入完全的困境。無論是以上哪種情況，攻擊者可能使用反映作用，將新的、可能的惡意行為引入應用程式。
範例 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 介面的物件。如果指令發送器仍然負責存取控制，則無論程式設計師何時建立實作 Worker 介面的新類別，他們都必須記得要去修改發送器的存取控制程式碼。如果他們無法修改存取控制程式碼，則部分 Worker 類別將不會擁有任何存取控制。

處理存取控制問題的其中一個方法，就是讓 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 介面，將會在指派到 ao 之前拋出 ClassCastException。但是如果建構函式執行了有利於攻擊者的作業，則傷害可能已經造成。雖然這種情況在簡易的應用程式中的影響相對不大，但是對於日趨複雜的較大型應用程式而言，做出攻擊者可以找到一個建構函式來作為攻擊一部分的假設也十分合理。

如果使用即時呼叫者的類別載入器檢查執行工作的特定 Java API，是針對反映呼叫返回的不可信賴物件而叫用，存取檢查可能會在程式碼執行鏈中進一步受到危害。這些 Java API 會略過 SecurityManager 檢查，確保執行鏈中的所有呼叫者都具備必要的安全權限。請注意，應確保不針對反映呼叫返回的不可信賴物件叫用這些 API，因為他們會略過安全存取檢查，從而使系統易於受遠端攻擊者的攻擊。如需有關這些 Java API 的詳細資訊，請參閱適用於 Java 程式語言的安全編碼規範之第 9 條。

如果攻擊者可以提供值，且應用程式會使用這些值來決定要個體化的類別或要叫用的方法，那麼攻擊者就可能可以透過應用程式，建立非應用程式開發者指定的控制流路徑。這種攻擊途徑可能會讓攻擊者避開 Authentication 或 Access Control 檢查，或者使得應用程式以無法預期的方式運作。

範例 1：程式設計師使用選取器 API 的常見原因是為了執行自己的指令發送器。以下範例顯示使用反映的 Swift 指令發送器從自訂 URL 架構要求中讀取一個數值來執行任意方法。執行此程式碼可讓攻擊者呼叫任何符合 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 的錯誤。