Las pérdidas de recursos presentan dos causas habituales:

- Condiciones de error y otras circunstancias excepcionales.

- Confusión en cuanto a la parte del programa responsable de liberar el recurso.

La mayoría de los problemas de recursos no liberados provocan problemas generales de confiabilidad del software. Sin embargo, si un usuario malintencionado puede desencadenar de forma intencionada una pérdida de recursos, este podría lanzar un ataque de denegación de servicio agotando el conjunto de recursos.

Ejemplo 1: El siguiente código ejecuta una consulta de base de datos, pero no libera la instrucción ni los recursos de conexión.

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.

Las pérdidas de recursos presentan dos causas habituales:

- Condiciones de error y otras circunstancias excepcionales.

- Confusión en cuanto a la parte del programa responsable de liberar el recurso.

La mayoría de los problemas de recursos no liberados provocan problemas generales de confiabilidad del software. Sin embargo, si un usuario malintencionado puede activar de forma intencionada una pérdida de recursos, es posible que este pueda iniciar un ataque de denegación de servicio agotando el conjunto de recursos.

Ejemplo 1: El siguiente código ejecuta una consulta de base de datos, pero no libera la instrucción ni los recursos de conexión.

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

Las pérdidas de recursos presentan dos causas habituales:

- Condiciones de error y otras circunstancias excepcionales.

- Confusión en cuanto a la parte del programa responsable de liberar el recurso.

La mayoría de los problemas de recursos no liberados provocan problemas generales de confiabilidad del software. Sin embargo, si un usuario malintencionado puede activar de forma intencionada una pérdida de recursos, es posible que este pueda iniciar un ataque de denegación de servicio agotando el conjunto de recursos.

Ejemplo 1: En condiciones normales, el siguiente código ejecuta una consulta de base de datos, procesa los resultados devueltos por la base de datos y cierra el objeto de instrucción asignado. Sin embargo, si se produce una excepción al ejecutar el SQL o al procesar los resultados, el objeto de instrucción no se cerrará. Si esto ocurre con bastante frecuencia, la base de datos agotará los cursores disponibles y no podrá ejecutar ninguna otra consulta SQL.

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

Las pérdidas de recursos presentan dos causas habituales:

- Condiciones de error y otras circunstancias excepcionales.

- Confusión en cuanto a la parte del programa responsable de liberar el recurso.

La mayoría de los problemas de recursos no liberados provocan problemas generales de confiabilidad del software. Sin embargo, si un usuario malintencionado puede activar de forma intencionada una pérdida de recursos, es posible que este pueda iniciar un ataque de denegación de servicio agotando el conjunto de recursos.

Ejemplo 1: El siguiente código ejecuta una consulta de base de datos, pero no libera la instrucción ni los recursos de conexión.

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

Es posible que el programa no pueda liberar un recurso del sistema.

Las pérdidas de recursos presentan dos causas habituales:

- Condiciones de error y otras circunstancias excepcionales.

- Confusión en cuanto a la parte del programa responsable de liberar el recurso.

La mayoría de los problemas de recursos no liberados provocan problemas generales de confiabilidad del software. Sin embargo, si un usuario malintencionado puede activar de forma intencionada una pérdida de recursos, es posible que este pueda iniciar un ataque de denegación de servicio agotando el conjunto de recursos.

Ejemplo 1: El siguiente método nunca cierra el identificador de archivo que abre. El método finalize() de FileInputStream con el tiempo llama a close(), pero no hay ninguna garantía en cuanto al tiempo que pasará antes de que se llame al método finalize(). En un entorno muy activo, esto puede provocar que la JVM utilice todos los identificadores de archivo.

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

Es posible que el programa no pueda liberar un recurso del sistema.


Las pérdidas de recursos presentan dos causas habituales:

- Condiciones de error y otras circunstancias excepcionales.

- Confusión en cuanto a la parte del programa responsable de liberar el recurso.

La mayoría de los problemas de recursos no liberados provocan problemas generales de confiabilidad del software. Sin embargo, si un usuario malintencionado puede activar de forma intencionada una pérdida de recursos, es posible que este pueda iniciar un ataque de denegación de servicio agotando el conjunto de recursos.

Ejemplo 1: el siguiente método nunca cierra la secuencia de la que lee.

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

Es posible que el programa no pueda liberar un recurso del sistema.

Las pérdidas de recursos presentan dos causas habituales:

- Condiciones de error y otras circunstancias excepcionales.

- Confusión en cuanto a la parte del programa responsable de liberar el recurso.

La mayoría de los problemas de recursos no liberados provocan problemas generales de confiabilidad del software. Sin embargo, si un usuario malintencionado puede activar de forma intencionada una pérdida de recursos, es posible que este pueda iniciar un ataque de denegación de servicio agotando el conjunto de recursos.

Ejemplo 1: El siguiente método nunca cierra el identificador de archivo que abre.

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

Es posible que el programa no pueda liberar un recurso del sistema.


Las pérdidas de recursos presentan dos causas habituales:

- Condiciones de error y otras circunstancias excepcionales.

- Confusión en cuanto a la parte del programa responsable de liberar el recurso.

La mayoría de los problemas de recursos no liberados provocan problemas generales de confiabilidad del software. Sin embargo, si un usuario malintencionado puede activar de forma intencionada una pérdida de recursos, es posible que este pueda iniciar un ataque de denegación de servicio agotando el conjunto de recursos.

Ejemplo 1: El método siguiente nunca cierra la secuencia de la que lee.

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

Es posible que el programa no pueda liberar un recurso del sistema.

Las pérdidas de recursos presentan dos causas habituales:

- Condiciones de error y otras circunstancias excepcionales.

- Confusión en cuanto a la parte del programa responsable de liberar el recurso.

La mayoría de los problemas de recursos no liberados provocan problemas generales de confiabilidad del software. Sin embargo, si un usuario malintencionado puede activar de forma intencionada una pérdida de recursos, es posible que este pueda iniciar un ataque de denegación de servicio agotando el conjunto de recursos.

Ejemplo 1: La función siguiente no destruye la variable de condición que asigna si se produce un error. Si el proceso se alarga en el tiempo, puede quedarse sin identificadores de archivo.

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

Es posible que el programa no pueda liberar un bloqueo.

Las pérdidas de recursos presentan dos causas habituales:

- Condiciones de error y otras circunstancias excepcionales.

- Confusión sobre qué parte del programa es responsable de liberar el recurso.

La mayoría de los problemas de recursos no liberados provocan problemas generales de confiabilidad del software. Sin embargo, si un atacante puede desencadenar de forma intencionada una pérdida de recursos, el atacante podría lanzar una denegación de servicio agotando el conjunto de recursos o provocando un interbloqueo.

Ejemplo 1: El siguiente programa no libera un bloqueo de registro en un archivo si se produce un error.

  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
  .

Es posible que el programa no pueda liberar un recurso del sistema.

Las pérdidas de recursos presentan dos causas habituales:

- Condiciones de error y otras circunstancias excepcionales.

- Confusión en cuanto a la parte del programa responsable de liberar el recurso.

La mayoría de los problemas de recursos no liberados provocan problemas generales de confiabilidad del software. Sin embargo, si un usuario malintencionado puede activar de forma intencionada una pérdida de recursos, es posible que este pueda iniciar un ataque de denegación de servicio agotando el conjunto de recursos.

Ejemplo 1: el siguiente código establece un bloqueo antes de performOperationInCriticalSection(), pero no puede liberar el bloqueo si se genera una excepción en ese método.

ReentrantLock  myLock = new ReentrantLock ();

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

Las pérdidas de recursos presentan dos causas habituales:

- Condiciones de error y otras circunstancias excepcionales.

- Confusión en cuanto a la parte del programa responsable de liberar el recurso.

La mayoría de los problemas de recursos no liberados provocan problemas generales de confiabilidad del software. Sin embargo, si un usuario malintencionado puede desencadenar de forma intencionada una pérdida de recursos, este puede lanzar una denegación de servicio, agotando el conjunto de recursos.

Ejemplo 1: El siguiente código establece un bloqueo antes de performOperationInCriticalSection(), pero nunca lo libera.

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

Las pérdidas de recursos presentan dos causas habituales:

- Condiciones de error y otras circunstancias excepcionales.

- Confusión en cuanto a la parte del programa responsable de liberar el recurso.

La mayoría de los problemas de recursos no liberados provocan problemas generales de confiabilidad del software. Sin embargo, si un usuario malintencionado puede desencadenar de forma intencionada una pérdida de recursos, este puede lanzar una denegación de servicio, agotando el conjunto de recursos.

Ejemplo 1: El siguiente código establece un bloqueo antes de performOperationInCriticalSection(), pero nunca lo libera.

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

Si un usuario malintencionado puede suministrar los valores que la aplicación más tarde utiliza para determinar con qué clase se puede crear una instancia o qué método se puede invocar, existe la posibilidad de que el usuario malintencionado cree rutas de flujo de control a través de la aplicación que no han diseñado los desarrolladores de aplicaciones. Este tipo de ataque puede permitir que el usuario malintencionado eluda la autenticación o las comprobaciones del control de acceso, o bien que de cualquier otra manera, provoque que la aplicación se comporte de forma inesperada. Incluso la capacidad para controlar los argumentos pasados a un determinado método o constructor puede aportar a un usuario malintencionado y astuto el margen necesario para ejecutar un ataque con éxito.

Ejemplo 1: Un motivo común por el cual los programadores utilizan la tecnología de reflexión es el de implementar su propio distribuidor de comandos. El ejemplo siguiente muestra un distribuidor de comandos que no utiliza la reflexión:

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

Un programador podría refactorizar este código para utilizar la reflexión tal y como se muestra a continuación:

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

La refactorización al principio parece que ofrece una serie de ventajas. Hay menos líneas de código, los bloques if/else se han eliminado por completo y ahora es posible agregar nuevos tipos de comando sin modificar el distribuidor de comandos.

Sin embargo, la refactorización permite que un usuario malintencionado cree instancias de cualquier objeto que implemente la interfaz Worker. Si el distribuidor de comandos sigue siendo responsable del control de acceso, entonces cada vez que los programadores creen una nueva clase que implemente la interfaz Worker, no deben olvidar modificar el código de control de acceso del distribuidor. Si no pueden modificar el código de control de acceso, algunas clases Worker no tendrán ningún control de acceso.

Una manera de solucionar este problema de control de acceso es hacer que el objeto Worker sea responsable de realizar la comprobación de control de acceso. A continuación se muestra un ejemplo del código refactorizado:

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

Aunque esto es una mejora, fomenta un método descentralizado de controlar el acceso, lo que aumenta las posibilidades de que los programadores cometan errores de control de acceso.

Si un atacante puede proporcionar valores que posteriormente la aplicación use para determinar qué clase instanciar o qué método invocar, el atacante podría crear rutas de flujo de control inesperadas a través de la aplicación. Esto podría permitir al atacante eludir las verificaciones de autenticación o control de acceso o quizá hacer que la aplicación se comporte de manera inesperada.

Ejemplo 1: El siguiente método de acción inicia una solicitud asincrónica a un servicio web externo y establece la propiedad continuationMethod, que determina el nombre del método al que se llamará al recibir una respuesta.

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

Esta implementación permite que la propiedad continuationMethod se establezca mediante parámetros de solicitud de tiempo de ejecución, lo que permite a los atacantes llamar a cualquier función que coincida con el nombre.

Si un usuario malintencionado puede suministrar los valores que la aplicación más tarde utiliza para determinar con qué clase se puede crear una instancia o qué método se puede invocar, existe la posibilidad de que el usuario malintencionado cree rutas de flujo de control a través de la aplicación que no han diseñado los desarrolladores de aplicaciones. Este tipo de ataque puede permitir que el usuario malintencionado eluda la autenticación o las comprobaciones del control de acceso, o bien que de cualquier otra manera, provoque que la aplicación se comporte de forma inesperada.

Esta situación se convierte en una situación crítica si el atacante puede cargar archivos en una ubicación que aparezca en la ruta de la aplicación o la biblioteca. En cualquiera de estas situaciones, el atacante puede usar la reflexión para introducir un nuevo comportamiento presuntamente malicioso en la aplicación.
Ejemplo 1: Un motivo habitual por el que los programadores utilizan la API de reflexión consiste en implementar su propio distribuidor de comandos. En el siguiente ejemplo se muestra un distribuidor de comandos JNI que utiliza la reflexión para ejecutar un método de Java identificado por un valor leído desde una solicitud CGI. Esta implementación permite a un usuario malintencionado llamar a cualquier función definida en clazz.

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

Si un atacante puede proporcionar valores que la aplicación luego utiliza para determinar qué método invocar o qué valor de campo recuperar, existe la posibilidad de que el atacante cree rutas de flujo de control a través de la aplicación que no fueron previstas por los desarrolladores de la aplicación. Este vector de ataque podría permitir al atacante eludir las verificaciones de autenticación o control de acceso o, de lo contrario, hacer que la aplicación se comporte de manera inesperada.

Ejemplo 1: en este ejemplo, la aplicación recupera el nombre de una función a la que se va a llamar desde un argumento de la línea de comandos.

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

Ejemplo 2: Similar al ejemplo anterior, la aplicación utiliza el paquete reflect para recuperar el nombre de una función a la que se va a llamar desde un argumento de la línea de comandos.

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

Si un usuario malintencionado puede suministrar los valores que la aplicación más tarde utiliza para determinar con qué clase se puede crear una instancia o qué método se puede invocar, existe la posibilidad de que el usuario malintencionado cree rutas de flujo de control a través de la aplicación que no han diseñado los desarrolladores de aplicaciones. Este tipo de ataque puede permitir que el usuario malintencionado eluda la autenticación o las comprobaciones del control de acceso, o bien que de cualquier otra manera, provoque que la aplicación se comporte de forma inesperada. Incluso la capacidad para controlar los argumentos pasados a un determinado método o constructor puede aportar a un usuario malintencionado y astuto el margen necesario para ejecutar un ataque con éxito.

Esta situación pasa a ser crítica si el atacante puede cargar archivos en una ubicación que aparezca en la ruta de clase de la aplicación o añadir entradas a la ruta de clase de la aplicación. En cualquiera de estas situaciones, el atacante puede usar la reflexión para introducir un nuevo comportamiento presuntamente malicioso en la aplicación.
Ejemplo 1: Un motivo habitual por el que los programadores utilizan la API de reflexión consiste en implementar su propio distribuidor de comandos. El ejemplo siguiente muestra un distribuidor de comandos que no utiliza la reflexión:

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

Un programador podría refactorizar este código para utilizar la reflexión tal y como se muestra a continuación:

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

La refactorización al principio parece que ofrece una serie de ventajas. Hay menos líneas de código, los bloques if/else se han eliminado por completo y ahora es posible agregar nuevos tipos de comando sin modificar el distribuidor de comandos.

Sin embargo, la refactorización permite que un usuario malintencionado cree instancias de cualquier objeto que implemente la interfaz Worker. Si el distribuidor de comandos sigue siendo responsable del control de acceso, entonces cada vez que los programadores creen una nueva clase que implemente la interfaz Worker, no deben olvidar modificar el código de control de acceso del distribuidor. Si no pueden modificar el código de control de acceso, algunas clases Worker no tendrán ningún control de acceso.

Una manera de solucionar este problema de control de acceso es hacer que el objeto Worker sea responsable de realizar la comprobación de control de acceso. A continuación se muestra un ejemplo del código refactorizado:

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

Aunque esto es una mejora, fomenta un método descentralizado de controlar el acceso, lo que aumenta las posibilidades de que los programadores cometan errores de control de acceso.

Este código también pone de manifiesto otro problema de seguridad relacionado con el uso de la reflexión para crear un distribuidor de comandos. Un atacante puede llamar al constructor predeterminado en relación con cualquier tipo de objeto. De hecho, el usuario malintencionado no está limitado solo a los objetos que implementan la interfaz de Worker; se puede llamar al constructor predeterminado de cualquier objeto del sistema. Si el objeto no implementa la interfaz de Worker, se generará una ClassCastException antes de la asignación a ao. Sin embargo, si el constructor realiza operaciones que trabajan a favor del usuario malintencionado, el daño ya estará hecho. Aunque este escenario es relativamente benigno en aplicaciones sencillas, en las aplicaciones de mayor tamaño en las que la complejidad crece exponencialmente, es razonable creer que un usuario malintencionado podría encontrar un constructor para aprovecharlo como parte de un ataque.

Las comprobaciones de acceso también pueden verse comprometidas más adelante en la cadena de ejecución de código si se llama a determinadas API de Java que realizan tareas mediante la comprobación del cargador de clases del autor de la llamada inmediato, en objetos poco confiables devueltos por las llamadas de reflexión. Estas API de Java omiten la comprobación de SecurityManager que garantiza que todos los autores de llamadas de la cadena de ejecución dispongan de los permisos de seguridad necesarios. Se debe tener cuidado para garantizar que se llame a estas API en los objetos que no son de confianza devueltos por la reflexión, ya que pueden omitir las comprobaciones de acceso de seguridad y dejar al sistema vulnerable frente a ataques remotos. Para obtener más información sobre estas API de Java, consulte la directriz 9 de The Secure Coding Guidelines for the Java Programming Language (Directrices de creación segura de código para el lenguaje de programación Java).

Si un usuario malintencionado puede suministrar los valores que la aplicación más tarde utiliza para determinar con qué clase se puede crear una instancia o qué método se puede invocar, existe la posibilidad de que el usuario malintencionado cree rutas de flujo de control a través de la aplicación que no han diseñado los desarrolladores de aplicaciones. Este tipo de ataque puede permitir que el usuario malintencionado eluda la autenticación o las comprobaciones del control de acceso, o bien que de cualquier otra manera, provoque que la aplicación se comporte de forma inesperada.

Ejemplo 1: Es un motivo común por el cual los programadores utilizan la API del selector para implementar su propio distribuidor de comandos. En el ejemplo siguiente se muestra un distribuidor de comandos de Objective-C que utiliza la reflexión para ejecutar un método arbitrario identificado por un valor de lectura a partir de una solicitud de esquema de URL personalizado. Esta implementación permite que un atacante llame a cualquier función que coincida con la firma del método definida en la clase 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];
...

Si un usuario malintencionado puede suministrar los valores que la aplicación más tarde utiliza para determinar con qué clase se puede crear una instancia o qué método se puede invocar, existe la posibilidad de que el usuario malintencionado cree rutas de flujo de control a través de la aplicación que no han diseñado los desarrolladores de aplicaciones. Este tipo de ataque puede permitir que el usuario malintencionado eluda la autenticación o las comprobaciones del control de acceso, o bien que de cualquier otra manera, provoque que la aplicación se comporte de forma inesperada. Incluso la capacidad para controlar los argumentos pasados a un determinado método o constructor puede aportar a un usuario malintencionado y astuto el margen necesario para ejecutar un ataque con éxito.

Esta situación pasa a ser crítica si el atacante puede cargar archivos en una ubicación que aparezca en la ruta de clase de la aplicación o añadir entradas a la ruta de clase de la aplicación. En cualquiera de estas situaciones, el atacante puede usar la reflexión para introducir un nuevo comportamiento presuntamente malicioso en la aplicación.
Ejemplo 1: Un motivo habitual por el que los programadores utilizan la API de reflexión consiste en implementar su propio distribuidor de comandos. El ejemplo siguiente muestra un distribuidor de comandos que no utiliza la reflexión:

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

Un programador podría refactorizar este código para utilizar la reflexión tal y como se muestra a continuación:

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

La refactorización al principio parece que ofrece una serie de ventajas. Hay menos líneas de código, los bloques if/else se han eliminado por completo y ahora es posible agregar nuevos tipos de comando sin modificar el distribuidor de comandos.

Sin embargo, la refactorización permite que un usuario malintencionado cree instancias de cualquier objeto que implemente la interfaz Worker. Si el distribuidor de comandos sigue siendo responsable del control de acceso, entonces cada vez que los programadores creen una nueva clase que implemente la interfaz Worker, no deben olvidar modificar el código de control de acceso del distribuidor. Si no pueden modificar el código de control de acceso, algunas clases Worker no tendrán ningún control de acceso.

Una manera de solucionar este problema de control de acceso es hacer que el objeto Worker sea responsable de realizar la comprobación de control de acceso. A continuación se muestra un ejemplo del código refactorizado:

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

Aunque esto es una mejora, fomenta un método descentralizado de controlar el acceso, lo que aumenta las posibilidades de que los programadores cometan errores de control de acceso.

Este código también pone de manifiesto otro problema de seguridad relacionado con el uso de la reflexión para crear un distribuidor de comandos. Un atacante puede llamar al constructor predeterminado en relación con cualquier tipo de objeto. De hecho, el usuario malintencionado no está limitado solo a los objetos que implementan la interfaz de Worker; se puede llamar al constructor predeterminado de cualquier objeto del sistema. Si el objeto no implementa la interfaz de Worker, se generará una ClassCastException antes de la asignación a $ao. Sin embargo, si el constructor realiza operaciones que trabajan a favor del usuario malintencionado, el daño ya estará hecho. Aunque este escenario es relativamente benigno en aplicaciones sencillas, en las aplicaciones de mayor tamaño en las que la complejidad crece exponencialmente, es razonable creer que un usuario malintencionado podría encontrar un constructor para aprovecharlo como parte de un ataque.

Si un usuario malintencionado puede suministrar los valores que la aplicación más tarde utiliza para determinar con qué clase se puede crear una instancia o qué método se puede invocar, existe la posibilidad de que el usuario malintencionado cree rutas de flujo de control a través de la aplicación que no han diseñado los desarrolladores de aplicaciones. Este tipo de ataque puede permitir que el usuario malintencionado eluda la autenticación o las comprobaciones del control de acceso, o bien que de cualquier otra manera, provoque que la aplicación se comporte de forma inesperada. Incluso la capacidad para controlar los argumentos pasados a un determinado método o constructor puede aportar a un usuario malintencionado y astuto el margen necesario para ejecutar un ataque con éxito.

Esta situación pasa a ser crítica si el atacante puede cargar archivos en una ubicación que aparezca en la ruta de clase de la aplicación o añadir entradas a la ruta de clase de la aplicación. En cualquiera de estas situaciones, el atacante puede usar la reflexión para introducir un nuevo comportamiento presuntamente malicioso en la aplicación.

Si un usuario malintencionado puede suministrar los valores que la aplicación más tarde utiliza para determinar con qué clase se puede crear una instancia o qué método se puede invocar, existe la posibilidad de que el usuario malintencionado cree rutas de flujo de control a través de la aplicación que no han diseñado los desarrolladores de aplicaciones. Este tipo de ataque puede permitir que el usuario malintencionado eluda la autenticación o las comprobaciones del control de acceso, o bien hacer que la aplicación se comporte de forma inesperada. Incluso la capacidad para controlar los argumentos pasados a un determinado método o constructor puede aportar a un usuario malintencionado y astuto el margen necesario para ejecutar un ataque con éxito.

Esta situación pasa a ser crítica si el atacante puede cargar archivos en una ubicación que aparezca en la ruta de carga de la aplicación o añadir entradas a la ruta de carga de la aplicación. En cualquiera de estas situaciones, el atacante puede usar la reflexión para introducir un nuevo comportamiento presuntamente malicioso en la aplicación.
Ejemplo 1: Un motivo común por el cual los programadores utilizan la reflexión es el de implementar su propio distribuidor de comandos. El ejemplo siguiente muestra un distribuidor de comandos que no utiliza la reflexión:

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

Un programador podría refactorizar este código para utilizar la reflexión tal y como se muestra a continuación:

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

La refactorización al principio parece que ofrece una serie de ventajas. Hay menos líneas de código, los bloques if/else se han eliminado por completo y ahora es posible agregar nuevos tipos de comando sin modificar el distribuidor de comandos.

Sin embargo, la refactorización permite a un usuario malintencionado ejecutar cualquier método que termine con la palabra "Command". Si el distribuidor de comandos sigue siendo responsable del control de acceso, siempre que los programadores creen un nuevo método que termine con "Command", deberán acordarse de modificar el código de control de acceso del distribuidor. Incluso entonces, el procedimiento habitual cuando hay varios métodos con nombres similares puede ser crearlos dinámicamente mediante define_method() o llamarlos mediante el reemplazo de missing_method(). Auditar y realizar un seguimiento de estos métodos y de cómo se utiliza el código de control de acceso con ellos resulta muy difícil, y si consideramos que también depende de qué código de biblioteca se cargue, realizar esta tarea correctamente puede convertirse en una misión imposible.

Si un usuario malintencionado puede suministrar los valores que la aplicación más tarde utiliza para determinar con qué clase se puede crear una instancia o qué método se puede invocar, existe la posibilidad de que el usuario malintencionado cree rutas de flujo de control a través de la aplicación que no han diseñado los desarrolladores de aplicaciones. Este tipo de ataque puede permitir que el usuario malintencionado eluda la autenticación o las comprobaciones del control de acceso, o bien que de cualquier otra manera, provoque que la aplicación se comporte de forma inesperada. Incluso la capacidad para controlar los argumentos pasados a un determinado método o constructor puede aportar a un usuario malintencionado y astuto el margen necesario para ejecutar un ataque con éxito.

Esta situación pasa a ser crítica si el atacante puede cargar archivos en una ubicación que aparezca en la ruta de clase de la aplicación o añadir entradas a la ruta de clase de la aplicación. En cualquiera de estas situaciones, el atacante puede usar la reflexión para introducir un nuevo comportamiento presuntamente malicioso en la aplicación.
Ejemplo 1: Un motivo habitual por el que los programadores utilizan la API de reflexión consiste en implementar su propio distribuidor de comandos. El ejemplo siguiente muestra un distribuidor de comandos que utiliza la reflexión:

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

La refactorización al principio parece que ofrece una serie de ventajas. Hay menos líneas de código, los bloques if/else se han eliminado por completo y ahora es posible agregar nuevos tipos de comando sin modificar el distribuidor de comandos.

Sin embargo, la refactorización permite que un usuario malintencionado cree instancias de cualquier objeto que implemente la interfaz Worker. Si el distribuidor de comandos sigue siendo responsable del control de acceso, entonces cada vez que los programadores creen una nueva clase que implemente la interfaz Worker, no deben olvidar modificar el código de control de acceso del distribuidor. Si no pueden modificar el código de control de acceso, algunas clases Worker no tendrán ningún control de acceso.

Una manera de solucionar este problema de control de acceso es hacer que el objeto Worker sea responsable de realizar la comprobación de control de acceso. A continuación se muestra un ejemplo del código refactorizado:

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

Aunque esto es una mejora, fomenta un método descentralizado de controlar el acceso, lo que aumenta las posibilidades de que los programadores cometan errores de control de acceso.

Este código también pone de manifiesto otro problema de seguridad relacionado con el uso de la reflexión para crear un distribuidor de comandos. Un atacante puede llamar al constructor predeterminado en relación con cualquier tipo de objeto. De hecho, el usuario malintencionado no está limitado solo a los objetos que implementan la interfaz de Worker; se puede llamar al constructor predeterminado de cualquier objeto del sistema. Si el objeto no implementa la interfaz de Worker, se generará una ClassCastException antes de la asignación a ao. Sin embargo, si el constructor realiza operaciones que trabajan a favor del usuario malintencionado, el daño ya estará hecho. Aunque este escenario es relativamente benigno en aplicaciones sencillas, en las aplicaciones de mayor tamaño en las que la complejidad crece exponencialmente, es razonable creer que un usuario malintencionado podría encontrar un constructor para aprovecharlo como parte de un ataque.

Las comprobaciones de acceso también pueden verse comprometidas más adelante en la cadena de ejecución de código si se llama a determinadas API de Java que realizan tareas mediante la comprobación del cargador de clases del autor de la llamada inmediato, en objetos poco confiables devueltos por las llamadas de reflexión. Estas API de Java omiten la comprobación de SecurityManager que garantiza que todos los autores de llamadas de la cadena de ejecución dispongan de los permisos de seguridad necesarios. Se debe tener cuidado para garantizar que se llame a estas API en los objetos que no son de confianza devueltos por la reflexión, ya que pueden omitir las comprobaciones de acceso de seguridad y dejar al sistema vulnerable frente a ataques remotos. Para obtener más información sobre estas API de Java, consulte la directriz 9 de The Secure Coding Guidelines for the Java Programming Language (Directrices de creación segura de código para el lenguaje de programación Java).

Si un usuario malintencionado puede suministrar los valores que la aplicación más tarde utiliza para determinar con qué clase se puede crear una instancia o qué método se puede invocar, existe la posibilidad de que el usuario malintencionado cree rutas de flujo de control a través de la aplicación que no han diseñado los desarrolladores de aplicaciones. Este tipo de ataque puede permitir que el usuario malintencionado eluda la autenticación o las comprobaciones del control de acceso, o bien que de cualquier otra manera, provoque que la aplicación se comporte de forma inesperada.

Ejemplo 1: Es un motivo común por el cual los programadores utilizan la API del selector para implementar su propio distribuidor de comandos. En el ejemplo siguiente se muestra un distribuidor de comandos de Swift que utiliza la reflexión para ejecutar un método arbitrario identificado por un valor de lectura a partir de una solicitud de esquema de URL personalizado. Esta implementación permite que un atacante llame a cualquier función que coincida con la firma del método definida en la clase 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)
    ...
}

Si un usuario malintencionado puede suministrar los valores que la aplicación más tarde utiliza para determinar con qué clase se puede crear una instancia o qué método se puede invocar, existe la posibilidad de que el usuario malintencionado cree rutas de flujo de control a través de la aplicación que no han diseñado los desarrolladores de aplicaciones. Este tipo de ataque puede permitir que el usuario malintencionado eluda la autenticación o las comprobaciones del control de acceso, o bien que de cualquier otra manera, provoque que la aplicación se comporte de forma inesperada. Incluso la capacidad para controlar los argumentos pasados a un determinado método o constructor puede aportar a un usuario malintencionado y astuto el margen necesario para ejecutar un ataque con éxito.

Ejemplo 1: Un motivo común por el cual los programadores utilizan CallByName es el de implementar su propio distribuidor de comandos. En el ejemplo siguiente se muestra un distribuidor de comandos que no utiliza la función 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
...

Un programador podría refactorizar este código para utilizar la reflexión tal y como se muestra a continuación:

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

La refactorización al principio parece que ofrece una serie de ventajas. Hay menos líneas de código, los bloques if/else se han eliminado por completo y ahora es posible agregar nuevos tipos de comando sin modificar el distribuidor de comandos.

Sin embargo, la refactorización permite a un usuario malintencionado llamar a cualquier método implementado por el objeto Worker. Si el distribuidor de comandos sigue siendo responsable del control de acceso, siempre que los programadores creen un nuevo método dentro de la clase Worker, deberán acordarse de modificar el código de control de acceso del distribuidor. Si no pueden modificar el código de control de acceso, algunos métodos de Worker no tendrán ningún control de acceso.

Una manera de solucionar este problema de control de acceso es hacer que el objeto Worker sea responsable de realizar la comprobación de control de acceso. A continuación se muestra un ejemplo del código refactorizado:

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

Aunque esto es una mejora, fomenta un método descentralizado de controlar el acceso, lo que aumenta las posibilidades de que los programadores cometan errores de control de acceso.