Os vazamentos de recursos têm pelo menos duas causas comuns:

- Condições de erro e outras circunstâncias excepcionais.

- Confusão acerca de qual parte do programa é responsável pela liberação do recurso.

A maioria dos problemas de recursos não liberados resulta em problemas gerais de confiabilidade de software. No entanto, se um invasor puder provocar intencionalmente um vazamento de recursos, ele poderá iniciar um ataque de negação de serviço esgotando o pool de recursos.

Exemplo 1: O código a seguir executa uma consulta de banco de dados, mas não libera a instrução ou os recursos de conexão.

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.

Vazamento de recursos têm pelo menos duas causas comuns:

- Condições de erro e outras circunstâncias excepcionais.

- Confusão acerca de qual parte do programa é responsável pela liberação do recurso.

A maioria dos problemas de recursos não liberados resulta em problemas gerais de confiabilidade de software. No entanto, se um invasor puder provocar intencionalmente um vazamento de recursos, talvez ele consiga lançar um ataque de negação de serviço esgotando o pool de recursos.

Exemplo 1: O código a seguir executa uma consulta de banco de dados, mas não libera a instrução ou os recursos de conexão.

- 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;
    } 
    ...
}

Vazamento de recursos têm pelo menos duas causas comuns:

- Condições de erro e outras circunstâncias excepcionais.

- Confusão acerca de qual parte do programa é responsável pela liberação do recurso.

A maioria dos problemas de recursos não liberados resulta em problemas gerais de confiabilidade de software. No entanto, se um invasor puder provocar intencionalmente um vazamento de recursos, talvez ele consiga lançar um ataque de negação de serviço esgotando o pool de recursos.

Exemplo 1: Em condições normais, o código a seguir executa uma consulta de banco de dados, processa os resultados retornados pelo banco de dados e fecha o objeto de instrução alocado. Porém, se ocorrer uma exceção durante a execução do SQL ou o processamento dos resultados, o objeto de instrução não será fechado. Se isso acontecer com frequência suficiente, o banco de dados ficará sem cursores disponíveis e não poderá executar mais consultas SQL.

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

Vazamento de recursos têm pelo menos duas causas comuns:

- Condições de erro e outras circunstâncias excepcionais.

- Confusão acerca de qual parte do programa é responsável pela liberação do recurso.

A maioria dos problemas de recursos não liberados resulta em problemas gerais de confiabilidade de software. No entanto, se um invasor puder provocar intencionalmente um vazamento de recursos, talvez ele consiga lançar um ataque de negação de serviço esgotando o pool de recursos.

Exemplo 1: O código a seguir executa uma consulta de banco de dados, mas não libera a instrução ou os recursos de conexão.

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
    }
}

O programa talvez não consiga liberar um recurso do sistema.

Vazamento de recursos têm pelo menos duas causas comuns:

- Condições de erro e outras circunstâncias excepcionais.

- Confusão acerca de qual parte do programa é responsável pela liberação do recurso.

A maioria dos problemas de recursos não liberados resulta em problemas gerais de confiabilidade de software. No entanto, se um invasor puder provocar intencionalmente um vazamento de recursos, talvez ele consiga lançar um ataque de negação de serviço esgotando o pool de recursos.

Exemplo 1: O método a seguir nunca fecha o identificador de arquivo que ele abre. O método finalize() para FileInputStream eventualmente chama close(), mas não há garantia de quanto tempo levará até que o método finalize() será invocado. Em um ambiente muito ativo, isso pode fazer com que a JVM use todos os seus identificadores de arquivo.

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);
  }
}

O programa talvez não consiga liberar um recurso do sistema.


Vazamento de recursos têm pelo menos duas causas comuns:

- Condições de erro e outras circunstâncias excepcionais.

- Confusão acerca de qual parte do programa é responsável pela liberação do recurso.

A maioria dos problemas de recursos não liberados resulta em problemas gerais de confiabilidade de software. No entanto, se um invasor puder provocar intencionalmente um vazamento de recursos, talvez ele consiga lançar um ataque de negação de serviço esgotando o pool de recursos.

Exemplo 1: Este método nunca fecha o fluxo a partir do qual ele lê.

...
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 );
...

O programa talvez não consiga liberar um recurso do sistema.

Os vazamentos de recursos têm pelo menos duas causas comuns:

- Condições de erro e outras circunstâncias excepcionais.

- Confusão acerca de qual parte do programa é responsável pela liberação do recurso.

A maioria dos problemas de recursos não liberados resulta em problemas gerais de confiabilidade de software. No entanto, se um invasor puder provocar intencionalmente um vazamento de recursos, talvez ele consiga lançar um ataque de negação de serviço esgotando o pool de recursos.

Exemplo 1: O método a seguir nunca fecha o identificador de arquivo que ele abre.

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

O programa talvez não consiga liberar um recurso do sistema.


Vazamento de recursos têm pelo menos duas causas comuns:

- Condições de erro e outras circunstâncias excepcionais.

- Confusão acerca de qual parte do programa é responsável pela liberação do recurso.

A maioria dos problemas de recursos não liberados resulta em problemas gerais de confiabilidade de software. No entanto, se um invasor puder provocar intencionalmente um vazamento de recursos, talvez ele consiga lançar um ataque de negação de serviço esgotando o pool de recursos.

Exemplo 1: Este método nunca fecha o fluxo a partir do qual ele lê.

...
        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)
        }
...

O programa talvez não consiga liberar um recurso do sistema.

Vazamento de recursos têm pelo menos duas causas comuns:

- Condições de erro e outras circunstâncias excepcionais.

- Confusão acerca de qual parte do programa é responsável pela liberação do recurso.

A maioria dos problemas de recursos não liberados resulta em problemas gerais de confiabilidade de software. No entanto, se um invasor puder provocar intencionalmente um vazamento de recursos, talvez ele consiga lançar uma negação de serviço esgotando o pool de recursos.

Exemplo 1: A função a seguir destruirá a variável de condição alocada se ocorrer um erro. Se o processo durar muito, ele poderá ficar sem identificadores de arquivo.

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;
}

O programa talvez não consiga liberar um bloqueio.

Os vazamentos de recursos têm pelo menos duas causas comuns:

- Condições de erro e outras circunstâncias excepcionais.

- Confusão sobre qual parte do programa é responsável pela liberação do recurso.

A maioria dos problemas de recursos não liberados resulta em problemas gerais de confiabilidade de software. No entanto, se um invasor puder desencadear intencionalmente um vazamento de recursos, ele poderá iniciar um denial of service esgotando o pool de recursos ou causando um deadlock.

Exemplo 1: O programa a seguir não liberará um bloqueio de registro em um arquivo se ocorrer um erro.

  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
  .

O programa talvez não consiga liberar um recurso do sistema.

Vazamento de recursos têm pelo menos duas causas comuns:

- Condições de erro e outras circunstâncias excepcionais.

- Confusão acerca de qual parte do programa é responsável pela liberação do recurso.

A maioria dos problemas de recursos não liberados resulta em problemas gerais de confiabilidade de software. No entanto, se um invasor puder provocar intencionalmente um vazamento de recursos, talvez ele consiga lançar uma negação de serviço esgotando o pool de recursos.

Exemplo 1: O código a seguir estabelece um bloqueio antes de performOperationInCriticalSection(), mas não consegue liberá-lo quando uma exceção é lançada nesse método.

ReentrantLock  myLock = new ReentrantLock ();

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

Os vazamentos de recursos têm pelo menos duas causas comuns:

- Condições de erro e outras circunstâncias excepcionais.

- Confusão acerca de qual parte do programa é responsável pela liberação do recurso.

A maioria dos problemas de recursos não liberados resulta em problemas gerais de confiabilidade de software. No entanto, se um invasor puder provocar intencionalmente um vazamento de recursos, talvez ele inicie uma negação de serviço esgotando o pool de recursos.

Exemplo 1: O código a seguir estabelece um bloqueio antes de performOperationInCriticalSection(), mas nunca o libera.

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

Os vazamentos de recursos têm pelo menos duas causas comuns:

- Condições de erro e outras circunstâncias excepcionais.

- Confusão acerca de qual parte do programa é responsável pela liberação do recurso.

A maioria dos problemas de recursos não liberados resulta em problemas gerais de confiabilidade de software. No entanto, se um invasor puder provocar intencionalmente um vazamento de recursos, talvez ele inicie uma negação de serviço esgotando o pool de recursos.

Exemplo 1: O código a seguir estabelece um bloqueio antes de performOperationInCriticalSection(), mas nunca o libera.

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

Se um invasor puder fornecer valores que, em seguida, forem usados pelo aplicativo para determinar qual classe instanciar ou qual método invocar, existirá o potencial de que esse invasor crie caminhos de fluxo de controle através do aplicativo que não foram planejados pelos desenvolvedores desse aplicativo. Esse vetor de ataque pode permitir que o invasor ignore verificações de autenticação ou controle de acesso ou, em outros casos, pode fazer com que o aplicativo se comporte de maneira inesperada. Até mesmo a capacidade de controlar os argumentos transmitidos a um determinado método ou construtor pode proporcionar a um invasor astuto a vantagem necessária para organizar um ataque bem-sucedido.

Exemplo 1: Um motivo comum pelo qual os programadores utilizam a tecnologia de reflexão é para implementar seus próprios expedidores de comandos. O seguinte exemplo mostra um expedidor de comandos que não usa reflexão:

    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);

Um programador pode refatorar esse código para usar a reflexão, da seguinte maneira:

    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);

Inicialmente, a refatoração parece oferecer diversas vantagens. Há menos linhas de código, os blocos if/else foram totalmente eliminados e agora é possível adicionar novos tipos de comando sem modificar o expedidor de comandos.

No entanto, a refatoração permite que um invasor instancie qualquer objeto que implementa a interface Worker. Se o expedidor de comandos ainda for responsável pelo controle de acesso, sempre que os programadores criarem uma nova classe que implementa a interface Worker, eles deverão se lembrar de modificar o código de controle de acesso do expedidor. Se o código de controle de acesso não for modificado, algumas classes Worker não terão controle de acesso.

Uma maneira de resolver esse problema de controle de acesso é tornar o objeto Worker responsável pela execução da verificação de controle de acesso. Veja a seguir um exemplo do código novamente refatorado:

    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);

Embora seja uma melhoria, isso incentiva uma abordagem descentralizada ao controle de acesso, facilitando erros de controle de acesso por parte dos programadores.

Se um invasor puder fornecer valores que o aplicativo usará para determinar qual classe instanciar ou qual método invocar, o invasor poderá criar caminhos de fluxo de controle inesperados por meio do aplicativo. Isso pode permitir que o invasor ignore as verificações de autenticação ou controle de acesso ou, possivelmente, faça com que o aplicativo se comporte de maneira inesperada.

Exemplo 1: O método de ação a seguir inicia uma solicitação assíncrona para um serviço da Web externo e define a propriedade continuationMethod, que determina o nome do método a ser chamado ao receber uma resposta.

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;
}

Essa implementação permite que a propriedade continuationMethod seja definida por parâmetros de solicitação de tempo de execução, o que permite que invasores chamem qualquer função que corresponda ao nome.

Se um invasor puder fornecer valores que, em seguida, forem usados pelo aplicativo para determinar qual classe instanciar ou qual método invocar, existirá o potencial de que esse invasor crie caminhos de fluxo de controle através do aplicativo que não foram planejados pelos desenvolvedores desse aplicativo. Esse vetor de ataque pode permitir que o invasor ignore verificações de autenticação ou controle de acesso ou, em outros casos, pode fazer com que o aplicativo se comporte de maneira inesperada.

Essa situação torna-se um cenário apocalíptico quando o invasor pode carregar arquivos para um local que é exibido no caminho da biblioteca ou no caminho do aplicativo. Em qualquer uma dessas condições, o invasor pode usar o recurso de reflexão para introduzir no aplicativo um novo comportamento presumivelmente mal-intencionado.
Exemplo 1: Um motivo comum pelo qual os programadores utilizam a API de reflexão é para implementar seus próprios expedidores de comandos. O exemplo a seguir mostra um dispatcher de comandos JNI que usa a reflexão para executar um método Java identificado por um valor lido a partir de uma solicitação CGI. Essa implementação permite que um invasor chame qualquer função definida em clazz.

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

Se um invasor puder fornecer valores que o aplicativo usará para determinar qual método invocar ou qual valor de campo recuperar, haverá a possibilidade de o invasor criar caminhos de fluxo de controle por meio do aplicativo que não foram planejados pelos desenvolvedores do aplicativo. Esse vetor de ataque pode permitir que o invasor ignore as verificações de autenticação ou controle de acesso ou, caso contrário, fazer com que o aplicativo se comporte de maneira inesperada.

Exemplo 1: Neste exemplo, o aplicativo recupera o nome de uma função a ser chamada de um argumento da linha de comando.

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

Exemplo 2: De forma semelhante no exemplo anterior, o aplicativo usa o pacote reflect para obter o nome de uma função a ser chamada de um argumento da linha de comando.

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

Se um invasor puder fornecer valores que, em seguida, forem usados pelo aplicativo para determinar qual classe instanciar ou qual método invocar, existirá o potencial de que esse invasor crie caminhos de fluxo de controle através do aplicativo que não foram planejados pelos desenvolvedores desse aplicativo. Esse vetor de ataque pode permitir que o invasor ignore verificações de autenticação ou controle de acesso ou, em outros casos, pode fazer com que o aplicativo se comporte de maneira inesperada. Até mesmo a capacidade de controlar os argumentos transmitidos a um determinado método ou construtor pode proporcionar a um invasor astuto a vantagem necessária para organizar um ataque bem-sucedido.

Essa situação se transformará em um cenário apocalíptico se o invasor puder carregar arquivos em um local exibido no caminho de classe do aplicativo ou se puder adicionar novas entradas ao caminho de classe do aplicativo. Em qualquer uma dessas condições, o invasor pode usar o recurso de reflexão para introduzir no aplicativo um novo comportamento presumivelmente mal-intencionado.
Exemplo 1: Um motivo comum pelo qual os programadores utilizam a API de reflexão é para implementar seus próprios expedidores de comandos. O seguinte exemplo mostra um expedidor de comandos que não usa reflexão:

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);

Um programador pode refatorar esse código para usar a reflexão, da seguinte maneira:

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

Inicialmente, a refatoração parece oferecer diversas vantagens. Há menos linhas de código, os blocos if/else foram totalmente eliminados e agora é possível adicionar novos tipos de comando sem modificar o expedidor de comandos.

No entanto, a refatoração permite que um invasor instancie qualquer objeto que implementa a interface Worker. Se o expedidor de comandos ainda for responsável pelo controle de acesso, sempre que os programadores criarem uma nova classe que implementa a interface Worker, eles deverão se lembrar de modificar o código de controle de acesso do expedidor. Se o código de controle de acesso não for modificado, algumas classes Worker não terão controle de acesso.

Uma maneira de resolver esse problema de controle de acesso é tornar o objeto Worker responsável pela execução da verificação de controle de acesso. Veja a seguir um exemplo do código novamente refatorado:

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

Embora seja uma melhoria, isso incentiva uma abordagem descentralizada ao controle de acesso, facilitando erros de controle de acesso por parte dos programadores.

Esse código também destaca outro problema de segurança com o uso da reflexão para construir um expedidor de comandos. Um invasor pode invocar o construtor padrão para qualquer tipo de objeto. Na verdade, o invasor nem mesmo é impedido de acessar objetos que implementam a interface Worker; o construtor padrão para qualquer objeto no sistema pode ser invocado. Se o objeto não implementar a interface Worker, um ClassCastException será lançado antes da atribuição a ao, mas, se o construtor realizar operações que funcionarem a favor do invasor, os danos já terão sido feitos. Embora esse cenário seja relativamente favorável em aplicativos simples, em aplicativos maiores, nos quais a complexidade cresce exponencialmente, não é absurdo considerar que um invasor possa encontrar um construtor a ser otimizado como parte de um ataque.

As verificações de acesso também podem ficar comprometidas mais abaixo na cadeia a execução do código quando certas APIs Java que realizam tarefas usando a verificação de carregadores de classe do chamador imediato são invocadas em objetos não confiáveis retornados por chamadas de reflexão. Essas APIs Java ignoram a verificação de SecurityManager que garante que todos os chamadores na cadeia de execução tenham as permissões de segurança necessárias. É necessário ter cautela para garantir que essas APIs não sejam invocadas nos objetos não confiáveis retornados pela reflexão, pois elas podem ignorar verificações de acesso de segurança e deixar o sistema vulnerável a ataques remotos. Para obter mais informações sobre essas APIs Java, consulte a Orientação 9 das orientações para codificação segura da linguagem de programação Java.

Se um invasor puder fornecer valores que, em seguida, forem usados pelo aplicativo para determinar qual classe instanciar ou qual método invocar, existirá o potencial de que esse invasor crie caminhos de fluxo de controle através do aplicativo que não foram planejados pelos desenvolvedores desse aplicativo. Esse vetor de ataque pode permitir que o invasor ignore verificações de autenticação ou controle de acesso ou, em outros casos, pode fazer com que o aplicativo se comporte de maneira inesperada.

Exemplo 1: Uma razão comum pela qual os programadores usam a API do seletor é implementar o próprio despachante de comando deles. O exemplo a seguir mostra um dispatcher de comando Objective-C, que usa a reflexão para executar um método arbitrário identificado por um valor lido a partir de uma solicitação URL de esquema personalizado. Essa implementação permite a um invasor chamar qualquer função mediante a correspondência da assinatura do método definido na classe 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];
...

Se um invasor puder fornecer valores que, em seguida, forem usados pelo aplicativo para determinar qual classe instanciar ou qual método invocar, existirá o potencial de que esse invasor crie caminhos de fluxo de controle através do aplicativo que não foram planejados pelos desenvolvedores desse aplicativo. Esse vetor de ataque pode permitir que o invasor ignore verificações de autenticação ou controle de acesso ou, em outros casos, pode fazer com que o aplicativo se comporte de maneira inesperada. Até mesmo a capacidade de controlar os argumentos transmitidos a um determinado método ou construtor pode proporcionar a um invasor astuto a vantagem necessária para organizar um ataque bem-sucedido.

Essa situação se transformará em um cenário apocalíptico se o invasor puder carregar arquivos em um local exibido no caminho de classe do aplicativo ou se puder adicionar novas entradas ao caminho de classe do aplicativo. Em qualquer uma dessas condições, o invasor pode usar o recurso de reflexão para introduzir no aplicativo um novo comportamento presumivelmente mal-intencionado.
Exemplo 1: Um motivo comum pelo qual os programadores utilizam a API de reflexão é para implementar seus próprios expedidores de comandos. O seguinte exemplo mostra um expedidor de comandos que não usa reflexão:

$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);

Um programador pode refatorar esse código para usar a reflexão, da seguinte maneira:

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

Inicialmente, a refatoração parece oferecer diversas vantagens. Há menos linhas de código, os blocos if/else foram totalmente eliminados e agora é possível adicionar novos tipos de comando sem modificar o expedidor de comandos.

No entanto, a refatoração permite que um invasor instancie qualquer objeto que implementa a interface Worker. Se o expedidor de comandos ainda for responsável pelo controle de acesso, sempre que os programadores criarem uma nova classe que implementa a interface Worker, eles deverão se lembrar de modificar o código de controle de acesso do expedidor. Se o código de controle de acesso não for modificado, algumas classes Worker não terão controle de acesso.

Uma maneira de resolver esse problema de controle de acesso é tornar o objeto Worker responsável pela execução da verificação de controle de acesso. Veja a seguir um exemplo do código novamente refatorado:

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

Embora seja uma melhoria, isso incentiva uma abordagem descentralizada ao controle de acesso, facilitando erros de controle de acesso por parte dos programadores.

Esse código também destaca outro problema de segurança com o uso da reflexão para construir um expedidor de comandos. Um invasor pode invocar o construtor padrão para qualquer tipo de objeto. Na verdade, o invasor nem mesmo é impedido de acessar objetos que implementam a interface Worker; o construtor padrão para qualquer objeto no sistema pode ser invocado. Se o objeto não implementar a interface Worker, um ClassCastException será lançado antes da atribuição a $ao, mas, se o construtor realizar operações que funcionarem a favor do invasor, os danos já terão sido feitos. Embora esse cenário seja relativamente favorável em aplicativos simples, em aplicativos maiores, nos quais a complexidade cresce exponencialmente, não é absurdo considerar que um invasor possa encontrar um construtor a ser otimizado como parte de um ataque.

Se um invasor puder fornecer valores que, em seguida, forem usados pelo aplicativo para determinar qual classe instanciar ou qual método invocar, existirá o potencial de que esse invasor crie caminhos de fluxo de controle através do aplicativo que não foram planejados pelos desenvolvedores desse aplicativo. Esse vetor de ataque pode permitir que o invasor ignore verificações de autenticação ou controle de acesso ou, em outros casos, pode fazer com que o aplicativo se comporte de maneira inesperada. Até mesmo a capacidade de controlar os argumentos transmitidos a um determinado método ou construtor pode proporcionar a um invasor astuto a vantagem necessária para organizar um ataque bem-sucedido.

Essa situação se transformará em um cenário apocalíptico se o invasor puder carregar arquivos em um local exibido no caminho de classe do aplicativo ou se puder adicionar novas entradas ao caminho de classe do aplicativo. Em qualquer uma dessas condições, o invasor pode usar o recurso de reflexão para introduzir no aplicativo um novo comportamento presumivelmente mal-intencionado.

Se um invasor puder fornecer valores que, em seguida, forem usados pelo aplicativo para determinar qual classe instanciar ou qual método invocar, existirá o potencial de que esse invasor crie caminhos de fluxo de controle através do aplicativo que não foram planejados pelos desenvolvedores desse aplicativo. Esse vetor de ataque pode permitir ao invasor ignorar a autenticação, ignorar as verificações de controle de acesso ou, de outra maneira, fazer com que o aplicativo se comporte de maneira inesperada. Até mesmo a capacidade de controlar os argumentos transmitidos a um determinado método ou construtor pode proporcionar a um invasor astuto a vantagem necessária para organizar um ataque bem-sucedido.

Essa situação se tornará um cenário apocalíptico se o invasor puder carregar arquivos em um local exibido no caminho de carregamento do aplicativo ou adicionar novas entradas a esse caminho. Em qualquer uma dessas condições, o invasor pode usar o recurso de reflexão para introduzir no aplicativo um novo comportamento presumivelmente mal-intencionado.
Exemplo 1: Um motivo comum pelo qual os programadores utilizam a reflexão é para implementar seus próprios expedidores de comandos. O seguinte exemplo mostra um expedidor de comandos que não usa reflexão:

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

Um programador pode refatorar esse código para usar a reflexão, da seguinte maneira:

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

Inicialmente, a refatoração parece oferecer diversas vantagens. Há menos linhas de código, os blocos if/else foram totalmente eliminados e agora é possível adicionar novos tipos de comando sem modificar o expedidor de comandos.

No entanto, a refatoração permite a um invasor executar qualquer método que termine com a palavra "Command". Caso o distribuidor de comando ainda seja responsável pelo controle de acesso, sempre que os programadores criarem um novo método que termine com "Command", eles deverão se lembrar de modificar o código de controle de acesso do despachante. Mesmo assim, a prática comum quando se tem vários métodos de nome semelhante pode ser criá-los dinamicamente ao usar define_method(), ou pode ser chamá-los ao substituir missing_method(). Fazer a auditoria e o rastreio desses métodos assim como de que maneira o código de controle é utilizado com eles é muito difícil e, ao considerar essa situação, ela também dependerá de quais outros códigos de biblioteca estão carregados; isso fará com que essa tarefa seja quase impossível de realizar corretamente.

Se um invasor puder fornecer valores que, em seguida, forem usados pelo aplicativo para determinar qual classe instanciar ou qual método invocar, existirá o potencial de que esse invasor crie caminhos de fluxo de controle através do aplicativo que não foram planejados pelos desenvolvedores desse aplicativo. Esse vetor de ataque pode permitir que o invasor ignore verificações de autenticação ou controle de acesso ou, em outros casos, pode fazer com que o aplicativo se comporte de maneira inesperada. Até mesmo a capacidade de controlar os argumentos transmitidos a um determinado método ou construtor pode proporcionar a um invasor astuto a vantagem necessária para organizar um ataque bem-sucedido.

Essa situação se transformará em um cenário apocalíptico se o invasor puder carregar arquivos em um local exibido no caminho de classe do aplicativo ou se puder adicionar novas entradas ao caminho de classe do aplicativo. Em qualquer uma dessas condições, o invasor pode usar o recurso de reflexão para introduzir no aplicativo um novo comportamento presumivelmente mal-intencionado.
Exemplo 1: Um motivo comum pelo qual os programadores utilizam a API de reflexão é para implementar seus próprios expedidores de comandos. O exemplo a seguir mostra um expedidor de comandos que usa reflexão:

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

Inicialmente, a refatoração parece oferecer diversas vantagens. Há menos linhas de código, os blocos if/else foram totalmente eliminados e agora é possível adicionar novos tipos de comando sem modificar o expedidor de comandos.

No entanto, a refatoração permite que um invasor instancie qualquer objeto que implementa a interface Worker. Se o expedidor de comandos ainda for responsável pelo controle de acesso, sempre que os programadores criarem uma nova classe que implementa a interface Worker, eles deverão se lembrar de modificar o código de controle de acesso do expedidor. Se o código de controle de acesso não for modificado, algumas classes Worker não terão controle de acesso.

Uma maneira de resolver esse problema de controle de acesso é tornar o objeto Worker responsável pela execução da verificação de controle de acesso. Veja a seguir um exemplo do código novamente refatorado:

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

Embora seja uma melhoria, isso incentiva uma abordagem descentralizada ao controle de acesso, facilitando erros de controle de acesso por parte dos programadores.

Esse código também destaca outro problema de segurança com o uso da reflexão para construir um expedidor de comandos. Um invasor pode invocar o construtor padrão para qualquer tipo de objeto. Na verdade, o invasor nem mesmo é impedido de acessar objetos que implementam a interface Worker; o construtor padrão para qualquer objeto no sistema pode ser invocado. Se o objeto não implementar a interface Worker, um ClassCastException será lançado antes da atribuição a ao, mas, se o construtor realizar operações que funcionarem a favor do invasor, os danos já terão sido feitos. Embora esse cenário seja relativamente favorável em aplicativos simples, em aplicativos maiores, nos quais a complexidade cresce exponencialmente, não é absurdo considerar que um invasor possa encontrar um construtor a ser otimizado como parte de um ataque.

As verificações de acesso também podem ficar comprometidas mais abaixo na cadeia a execução do código quando certas APIs Java que realizam tarefas usando a verificação de carregadores de classe do chamador imediato são invocadas em objetos não confiáveis retornados por chamadas de reflexão.Essas APIs Java ignoram a verificação de SecurityManager que garante que todos os chamadores na cadeia de execução tenham as permissões de segurança necessárias.É necessário ter cautela para garantir que essas APIs não sejam invocadas nos objetos não confiáveis retornados pela reflexão, pois elas podem ignorar verificações de acesso de segurança e deixar o sistema vulnerável a ataques remotos.Para obter mais informações sobre essas APIs Java, consulte a Orientação 9 das orientações para codificação segura da linguagem de programação Java.

Se um invasor puder fornecer valores que, em seguida, forem usados pelo aplicativo para determinar qual classe instanciar ou qual método invocar, existirá o potencial de que esse invasor crie caminhos de fluxo de controle através do aplicativo que não foram planejados pelos desenvolvedores desse aplicativo. Esse vetor de ataque pode permitir que o invasor ignore verificações de autenticação ou controle de acesso ou, em outros casos, pode fazer com que o aplicativo se comporte de maneira inesperada.

Exemplo 1: Uma razão comum pela qual os programadores usam a API do seletor é implementar o próprio despachante de comando deles. O exemplo a seguir mostra um dispatcher de comando Swift que usa a reflexão para executar um método arbitrário identificado por um valor lido de uma solicitação de esquema de URL personalizada. Essa implementação permite a um invasor chamar qualquer função mediante a correspondência da assinatura do método definido na classe 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)
    ...
}

Se um invasor puder fornecer valores que, em seguida, forem usados pelo aplicativo para determinar qual classe instanciar ou qual método invocar, existirá o potencial de que esse invasor crie caminhos de fluxo de controle através do aplicativo que não foram planejados pelos desenvolvedores desse aplicativo. Esse vetor de ataque pode permitir que o invasor ignore verificações de autenticação ou controle de acesso ou, em outros casos, pode fazer com que o aplicativo se comporte de maneira inesperada. Até mesmo a capacidade de controlar os argumentos transmitidos a um determinado método ou construtor pode proporcionar a um invasor astuto a vantagem necessária para organizar um ataque bem-sucedido.

Exemplo 1: Um motivo comum pelo qual os programadores utilizam o CallByName é para implementar o próprio dispatcher de comandos. O seguinte exemplo mostra um dispatcher de comandos que não utiliza a função 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
...

Um programador pode refatorar esse código para usar a reflexão, da seguinte maneira:

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

Inicialmente, a refatoração parece oferecer diversas vantagens. Há menos linhas de código, os blocos if/else foram totalmente eliminados e agora é possível adicionar novos tipos de comando sem modificar o expedidor de comandos.

No entanto, a refatoração permite que um invasor chame qualquer método implementado pelo objeto Worker. Se o dispatcher de comandos ainda for responsável pelo controle de acesso, sempre que os programadores criarem um novo método na classe Worker, eles deverão se lembrar de modificar o código de controle de acesso do dispatcher. Se eles não conseguirem modificar o código de controle de acesso, alguns métodos Worker não terão nenhum controle de acesso.

Uma maneira de resolver esse problema de controle de acesso é tornar o objeto Worker responsável pela execução da verificação de controle de acesso. Veja a seguir um exemplo do código novamente refatorado:

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

Embora seja uma melhoria, isso incentiva uma abordagem descentralizada ao controle de acesso, facilitando erros de controle de acesso por parte dos programadores.