资源泄露至少有两种常见的原因：

- 错误状况及其他异常情况。

- 未明确程序的哪一部份负责释放资源。

大部分 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 问题只会导致常规软件可靠性问题，但如果攻击者能够故意触发资源泄漏，该攻击者就有可能通过耗尽资源池的方式发起拒绝服务攻击。

示例 1：以下代码在 performOperationInCriticalSection() 的前面创建一个锁，但从未释放过。

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

资源泄露至少有两种常见的原因：

- 错误状况及其他异常情况。

- 未明确程序的哪一部份负责释放资源。

大部分 Unreleased Resource 问题只会导致常规软件可靠性问题，但如果攻击者能够故意触发资源泄漏，该攻击者就有可能通过耗尽资源池的方式发起拒绝服务攻击。

示例 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 权限。

解决这种 access control 问题的一种方法是让 Worker 对象负责执行 access control 检查。下面是一段重新修改的代码示例：

    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 命令发送器，它使用反射来执行 Java 方法，该方法由读取自 CGI 请求中的数值进行验证。执行该代码允许攻击者调用在 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 权限。

解决这种 access control 问题的一种方法是让 Worker 对象负责执行 access control 检查。下面是一段重新修改的代码示例：

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 可以绕过安全访问检查，使系统容易受到远程攻击，因此应格外小心，确保不要在由反射返回的不可信任对象上调用这些 API。有关这些 Java API 的更多信息，请参见“Secure Coding Guidelines for the Java Programming Language”中的准则 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 权限。

解决这种 access control 问题的一种方法是让 Worker 对象负责执行 access control 检查。下面是一段重新修改的代码示例：

	$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() 来调用方法。审计和跟踪这些方法以及访问控制代码在这些方法中的使用方式是非常困难的，当考虑到这一点还将取决于所加载的其他库代码时，可能会使这个近乎不可完成的任务能够以这种方式正确地完成。

若攻击者可以为应用程序提供确定实例化哪个类或调用哪个方法的参数值，那么就有可能创建一个贯穿于整个应用程序的控制流路径，而该路径并非是应用程序开发者最初设计的。这种攻击途径可能使攻击者避开 authentication 或 access control 检测，或使应用程序以一种意想不到的方式运行。即使狡猾的攻击者只能控制传送给指定函数或构造函数的参数，也有可能会成功地发起攻击。

如果攻击者能够将文件上传到应用程序的类路径或者添加应用程序类路径的新入口，那么对应用程序来说，情况会非常糟糕。无论处于上面哪种情况，攻击者都能通过反射将新的行为引入应用程序，而这一行为往往可能是恶意的。
示例 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 权限。

解决这种 access control 问题的一种方法是让 Worker 对象负责执行 access control 检查。下面是一段重新修改的代码示例：

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 可以绕过安全访问检查，使系统容易受到远程攻击，因此应格外小心，确保不要在由反射返回的不可信任对象上调用这些 API。有关这些 Java API 的更多信息，请参见“Secure Coding Guidelines for the Java Programming Language”中的准则 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 权限。

解决这种 access control 问题的一种方法是让 Worker 对象负责执行 access control 检查。下面是一段重新修改的代码示例：

...
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 上更加容易犯错误。