Se producen pérdidas de información internas cuando los datos del sistema o la información de depuración se envían a un archivo local, a una consola o a una pantalla mediante impresión o creación de registros.

Ejemplo 1: El siguiente código imprime un seguimiento de pila en una consola "Debug" o en un archivo de registro:

  try {
    ...
  }
  catch(e:Error) {
    trace(e.getStackTrace());
  }

En función de la configuración del sistema, esta información se puede volcar en una consola, escribir en un archivo de registro o mostrar a un usuario. En algunos casos el mensaje de error indica al usuario malintencionado con precisión a qué tipo de ataque es vulnerable el sistema. Por ejemplo, un mensaje de error de base de datos puede revelar que la aplicación es vulnerable a ataques de SQL injection. Otros mensajes de error pueden revelar más pistas evasivas acerca del sistema. En el Example 1, la ruta de búsqueda podría implicar información sobre el tipo de sistema operativo, las aplicaciones instaladas en el sistema y cuánto esfuerzo han puesto los administradores a la hora de configurar el programa.

Se producen pérdidas de información internas cuando los datos del sistema o la información de depuración se envían a un archivo local, a una consola o a una pantalla mediante impresión o creación de registros.

Ejemplo 1: El siguiente código escribe un mensaje de excepción en el registro de depuración:

try {
    ...
} catch (Exception e) {
    System.Debug(LoggingLevel.ERROR, e.getMessage());
}

El mensaje de error podría permitir a un adversario realizar un plan de ataque. Por ejemplo, un mensaje de error de base de datos puede revelar que la aplicación es vulnerable a ataques de SQL injection. Otros mensajes de error pueden revelar más pistas evasivas acerca del sistema.

Se producen pérdidas de información internas cuando los datos del sistema o la información de depuración se envían a un archivo local, a una consola o a una pantalla mediante impresión o creación de registros.
Ejemplo 1: el siguiente código crea una cadena de conexión a base de datos, la utiliza para establecer una nueva conexión a la base de datos y la escribe en la consola.

string cs="database=northwind;server=mySQLServer...";
SqlConnection conn=new SqlConnection(cs);
...
Console.Writeline(cs);

En función de la configuración del sistema, esta información se puede volcar en una consola, escribir en un archivo de registro o mostrar a un usuario. En algunos casos, el mensaje de error indica al atacante a qué tipo de ataque específico es vulnerable el sistema. Por ejemplo, un mensaje de error de base de datos puede revelar que la aplicación es vulnerable a ataques de inyección de SQL. Otros mensajes de error pueden revelar más pistas evasivas acerca del sistema. En el Example 1, la información perdida podría implicar información sobre el tipo de sistema operativo, las aplicaciones instaladas en el sistema y cuánto esfuerzo han hecho los administradores para configurar el programa.

Se producen fugas de información internas cuando los datos del sistema o la información de depuración se envían mediante creación de registros o impresión a un archivo local, a una consola o a una pantalla.
Ejemplo 1: El siguiente código imprime la variable de entorno de ruta en la secuencia de error estándar:

  char* path = getenv("PATH");
  ...
  fprintf(stderr, "cannot find exe on path %s\n", path);

En función de la configuración del sistema, esta información se puede volcar en una consola, escribir en un archivo de registro o mostrar a un usuario. En algunos casos, el mensaje de error indica al usuario malintencionado con precisión a qué tipo de ataque será vulnerable el sistema. Por ejemplo, un mensaje de error de base de datos puede revelar que la aplicación es vulnerable a ataques de SQL injection. Otros mensajes de error pueden revelar más pistas evasivas acerca del sistema. En el Example 1, la ruta de búsqueda podría implicar información sobre el tipo de sistema operativo, las aplicaciones instaladas en el sistema y cuánto esfuerzo han puesto los administradores a la hora de configurar el programa.

Se producen fugas de información internas cuando los datos del sistema o la información de depuración se envían mediante creación de registros o impresión a un archivo local, a una consola o a una pantalla.
Ejemplo: el siguiente código solicita un volcado de transacciones de todas las áreas de almacenamiento relacionadas con la tarea, la tabla de control del terminal y un área de datos especificados:

...
EXEC CICS DUMP TRANSACTION
  DUMPCODE('name')
  FROM (data-area)
  LENGTH (data-value)
END-EXEC.
...

En función de la configuración del sistema, esta información se puede volcar en una consola, escribir en un archivo de registro o mostrar a un usuario. En algunos casos el mensaje de error indica al usuario malintencionado con precisión a qué tipo de ataque es vulnerable el sistema. Por ejemplo, un mensaje de error de base de datos puede revelar que la aplicación es vulnerable a ataques de SQL Injection. Otros mensajes de error pueden revelar más pistas evasivas acerca del sistema.

Se producen fugas de información internas cuando los datos del sistema o la información de depuración se envían a un archivo local, a una consola o a una pantalla mediante impresión o creación de registros.

Ejemplo: el código siguiente escribe en un archivo del sistema de archivos local:

<cfscript>
    try { 
        obj = CreateObject("person"); 
    } 
    catch(any excpt) { 
        f = FileOpen("c:\log.txt", "write"); 
        FileWriteLine(f, "#excpt.Message#");
        FileClose(f);
    }
</cfscript>

Esta información se escribe en un archivo de registro. En algunos casos, el mensaje ofrece al usuario malintencionado información precisa sobre los tipos de ataque a los que es vulnerable el sistema. Por ejemplo, un mensaje de error de base de datos puede revelar que la aplicación es vulnerable a ataques de SQL Injection. Otros mensajes de error pueden revelar más pistas evasivas acerca del sistema.

Se producen pérdidas de información internas cuando los datos del sistema o la información de depuración se envían a un archivo local, a una consola o a una pantalla mediante impresión o creación de registros.

Ejemplo 1: El siguiente código escribe una excepción en un archivo local:

  final file = await File('example.txt').create();
  final raf = await file.open(mode: FileMode.write);
  final data = String.fromEnvironment("PASSWORD");
  raf.writeString(data);

En función de la configuración del sistema, esta información se puede volcar en una consola, escribir en un archivo de registro o mostrar a un usuario. En algunos casos, el mensaje de error indica al atacante a qué tipo de ataque específico es vulnerable el sistema. Por ejemplo, un mensaje de error de base de datos puede revelar que la aplicación es vulnerable a ataques de SQL injection. Otros mensajes de error pueden revelar más pistas evasivas acerca del sistema. En el Example 1, la información perdida podría implicar información sobre el tipo de sistema operativo, las aplicaciones instaladas en el sistema y cuánto esfuerzo han hecho los administradores para configurar el programa.

Las pérdidas de información también son motivo de preocupación en los entornos informáticos móviles.

Se producen fugas de información internas cuando se envían datos del sistema o información de depuración mediante un registro o una impresión en un archivo local, una consola o una pantalla.
Ejemplo 1: El siguiente código imprime la variable de entorno de ruta en la secuencia de error estándar:

  path := os.Getenv("PATH")
  ...
  log.Printf("Cannot find exe on path %s\n", path)

En función de la configuración del sistema, esta información se puede volcar en una consola, escribir en un archivo de registro o mostrar a un usuario. En algunos casos, el mensaje de error indica al atacante a qué tipo de ataque específico es vulnerable el sistema. Por ejemplo, un mensaje de error de base de datos puede revelar que la aplicación es vulnerable a ataques de iSQL Injection. Otros mensajes de error pueden revelar pistas más evasivas acerca del sistema. En el Example 1, la ruta de búsqueda podría implicar información sobre el tipo de sistema operativo, las aplicaciones instaladas en el sistema y cuánto esfuerzo han puesto los administradores a la hora de configurar el programa.

Se producen pérdidas de información externas cuando los datos del sistema o la información de depuración salen del programa a un equipo remoto mediante un socket o una conexión de red. Las pérdidas externas pueden ayudar a los usuarios malintencionados al revelar datos específicos de los sistemas operativos, nombres de rutas de acceso completos, la existencia de nombres de usuario o las ubicaciones de los archivos de configuración, y son más graves que las pérdidas de información internas, a las que los usuarios malintencionados tienen más dificultades para acceder.

Ejemplo 1: el siguiente código genera pérdidas de información de Excepción en la respuesta HTTP:

protected void doPost (HttpServletRequest req, HttpServletResponse res) throws IOException {
    ...
    PrintWriter out = res.getWriter();
    try {
        ...
    } catch (Exception e) {
      out.println(e.getMessage());
    }
}

Esta información se puede exponer a un usuario remoto. En algunos casos, el mensaje de error indica al atacante a qué tipo de ataque específico es vulnerable el sistema. Por ejemplo, un mensaje de error de base de datos puede revelar que la aplicación es vulnerable a ataques de inyección de SQL. Otros mensajes de error pueden revelar más pistas evasivas acerca del sistema. En el Example 1, la información perdida podría implicar información sobre el tipo de sistema operativo, las aplicaciones instaladas en el sistema y cuánto esfuerzo han hecho los administradores para configurar el programa.

Las pérdidas de información también son motivo de preocupación en los entornos informáticos móviles. En las plataformas móviles, las aplicaciones se descargan desde diversos orígenes y se ejecutan junto con otras aplicaciones en el mismo dispositivo. La probabilidad de ejecutar un malware junto a una aplicación de banca es bastante alta, de modo que los autores de aplicaciones deben tener cuidado con la información que incluyen en los mensajes dirigidos a otras aplicaciones que se ejecutan en el dispositivo.

Ejemplo 2: El siguiente código difunde el seguimiento de pila de una excepción detectada a todos los destinatarios de Android registrados.

...
try {
  ...
} catch (Exception e) {
    String exception = Log.getStackTraceString(e);
    Intent i = new Intent();
    i.setAction("SEND_EXCEPTION");
    i.putExtra("exception", exception);
    view.getContext().sendBroadcast(i);
}
...

Se trata de otra situación específica de las plataformas móviles. La mayoría de los dispositivos móviles ahora implementa un protocolo de transmisión de datos en proximidad (NFC) para compartir rápidamente la información entre dispositivos utilizando la comunicación de radio. Funciona cuando se colocan dispositivos cerca los unos de los otros o tocándose. Aunque el campo de la comunicación de NFC está limitado a unos pocos centímetros, sí son posibles las escuchas, la modificación de datos y otros tipos de ataques, ya que NFC por sí solo no es garantía de una comunicación segura.

Ejemplo 3: la plataforma Android tiene compatibilidad con NFC. El código siguiente crea un mensaje que se inserta en otro dispositivo dentro del campo de alcance.

...
public static final String TAG = "NfcActivity";
private static final String DATA_SPLITTER = "__:DATA:__";
private static final String MIME_TYPE = "application/my.applications.mimetype";
...
TelephonyManager tm = (TelephonyManager)Context.getSystemService(Context.TELEPHONY_SERVICE);
String VERSION = tm.getDeviceSoftwareVersion();
...
NfcAdapter nfcAdapter = NfcAdapter.getDefaultAdapter(this);
if (nfcAdapter == null)
  return;

String text = TAG + DATA_SPLITTER + VERSION;
NdefRecord record = new NdefRecord(NdefRecord.TNF_MIME_MEDIA,
            MIME_TYPE.getBytes(), new byte[0], text.getBytes());
NdefRecord[] records = { record };
NdefMessage msg = new NdefMessage(records);
nfcAdapter.setNdefPushMessage(msg, this);
...

Un mensaje con formato de intercambio de datos NFC (NDEF) contiene datos escritos, un URI o una carga de aplicación personalizada. Si el mensaje contiene información sobre la aplicación, como su nombre, el tipo MIME o la versión de software del dispositivo, esta información se podría filtrar a una persona que esté escuchando.

Se producen pérdidas de información internas cuando los datos del sistema o la información de depuración se envían a un archivo local, a una consola o a una pantalla mediante impresión o creación de registros.

Ejemplo 1: el siguiente código escribe una excepción en una secuencia de error estándar:

var http = require('http');
...

http.request(options, function(res){
  ...
}).on('error', function(e){
  console.log('There was a problem with the request: ' + e);
});
...

En función de la configuración del sistema, esta información se puede volcar en una consola, escribir en un archivo de registro o mostrar a un usuario. En algunos casos, el mensaje de error indica al atacante a qué tipo de ataque específico es vulnerable el sistema. Por ejemplo, un mensaje de error de base de datos puede revelar que la aplicación es vulnerable a ataques de inyección de SQL. Otros mensajes de error pueden revelar más pistas evasivas acerca del sistema. En el Example 1, la información perdida podría implicar información sobre el tipo de sistema operativo, las aplicaciones instaladas en el sistema y cuánto esfuerzo han hecho los administradores para configurar el programa.

Se producen pérdidas de información internas cuando los datos del sistema o la información de depuración se envían a un archivo local, a una consola o a una pantalla mediante impresión o creación de registros.

Ejemplo 1: el siguiente código escribe una excepción en una secuencia de error estándar:

try {
    ...
} catch (e: Exception) {
    e.printStackTrace()
}

En función de la configuración del sistema, esta información se puede volcar en una consola, escribir en un archivo de registro o mostrar a un usuario. En algunos casos, el mensaje de error indica al atacante a qué tipo de ataque específico es vulnerable el sistema. Por ejemplo, un mensaje de error de base de datos puede revelar que la aplicación es vulnerable a ataques de inyección de SQL. Otros mensajes de error pueden revelar más pistas evasivas acerca del sistema. En el Example 1, la información perdida podría implicar información sobre el tipo de sistema operativo, las aplicaciones instaladas en el sistema y cuánto esfuerzo han hecho los administradores para configurar el programa.

Las pérdidas de información también son motivo de preocupación en los entornos informáticos móviles.

Ejemplo 2: El siguiente código registra el seguimiento de pila de una excepción detectada en la plataforma Android.

...
try {
  ...
} catch (e: Exception) {
    Log.e(TAG, Log.getStackTraceString(e))
}
...

Se producen fugas de información internas cuando los datos del sistema o la información de depuración se envían mediante creación de registros o impresión a un archivo local, a una consola o a una pantalla.
Ejemplo 1: el siguiente código genera fugas de información en el registro del sistema:

...
NSString* deviceID = [[UIDevice currentDevice] name];

NSLog(@"DeviceID: %@", deviceID);
...

En el mundo móvil, surgen otras áreas de preocupación sobre el mantenimiento de la información del sistema cuando se pierde o se roba un dispositivo. Una vez en posesión de un dispositivo iOS, un atacante puede acceder a gran cantidad de datos conectando el dispositivo por USB. Los archivos de tipo Lista de propiedades de iOS y las bases de datos de SQLite son fácilmente accesibles y pueden revelar información personal. Como regla general, la información relacionada con la privacidad no debe almacenarse sin protección en el sistema de archivos.

Ejemplo 2: el siguiente código añade una entrada deviceID a la lista de valores predeterminados de usuario y los almacena seguidamente en un archivo Lista de propiedades.

...
NSString* deviceID = [[UIDevice currentDevice] name];

[defaults setObject:deviceID forKey:@"deviceID"];
[defaults synchronize];
...

El código del Example 2 almacena información del sistema del dispositivo móvil en un archivo Lista de propiedades que se almacena desprotegido en el dispositivo. Aunque muchos desarrolladores confían en los archivos Lista de propiedades como ubicaciones de almacenamiento seguro para cualquier dato y para todos los datos, no se debería depender de ellos implícitamente, en concreto cuando la información y privacidad del sistema son una preocupación, ya que los archivos Lista de propiedades los puede leer cualquiera que esté en posesión del dispositivo.

En función de la configuración del sistema, esta información se puede volcar en una consola, escribir en un archivo de registro o mostrar a un usuario. En algunos casos, el mensaje de error indica al usuario malintencionado con precisión a qué tipo de ataque será vulnerable el sistema. Por ejemplo, un mensaje de error de base de datos puede revelar que la aplicación es vulnerable a ataques de SQL Injection. Otros mensajes de error pueden revelar más pistas evasivas acerca del sistema.

Se producen pérdidas de información internas cuando los datos del sistema o la información de depuración se envían a un archivo local, a una consola o a una pantalla mediante impresión o creación de registros.

Ejemplo 1: el siguiente código escribe una excepción en una secuencia de error estándar:

<?php
    ...
    echo "Server error! Printing the backtrace";
    debug_print_backtrace();
    ...
?>

En función de la configuración del sistema, esta información se puede volcar en una consola, escribir en un archivo de registro o mostrar a un usuario. En algunos casos, el mensaje de error indica al atacante a qué tipo de ataque específico es vulnerable el sistema. Por ejemplo, un mensaje de error de base de datos puede revelar que la aplicación es vulnerable a ataques de inyección de SQL. Otros mensajes de error pueden revelar más pistas evasivas acerca del sistema. En el Example 1, la información perdida podría implicar información sobre el tipo de sistema operativo, las aplicaciones instaladas en el sistema y cuánto esfuerzo han hecho los administradores para configurar el programa.

Se producen pérdidas de información internas cuando los datos del sistema o la información de depuración se envían a un archivo local, a una consola o a una pantalla mediante impresión o creación de registros.

Ejemplo 1: El siguiente código escribe una excepción en una secuencia de salida estándar:

    try:
        ...
    except:
        print(sys.exc_info()[2])

Esta información se vuelca en una consola. En algunos casos, el mensaje de error indica al atacante a qué tipo de ataque específico es vulnerable el sistema. Por ejemplo, un mensaje de error de base de datos puede revelar que la aplicación es vulnerable a ataques de inyección de SQL. Otros mensajes de error pueden revelar más pistas evasivas acerca del sistema. En el Example 1, la información perdida podría implicar información sobre el tipo de sistema operativo, las aplicaciones instaladas en el sistema y cuánto esfuerzo han hecho los administradores para configurar el programa.

Se producen pérdidas de información internas cuando los datos del sistema o la información de depuración se envían a un archivo local, a una consola o a una pantalla mediante impresión o creación de registros.

Ejemplo 1: el siguiente código escribe una excepción en una secuencia de error estándar:

...
begin
  log = Logger.new(STDERR)
  ...
rescue Exception
    log.info("Exception: " + $!)
...
end

En función de la configuración del sistema, esta información se puede volcar en una consola, escribir en un archivo de registro o mostrar a un usuario. En algunos casos, el mensaje de error indica al atacante a qué tipo de ataque específico es vulnerable el sistema. Por ejemplo, un mensaje de error de base de datos puede revelar que la aplicación es vulnerable a ataques de inyección de SQL. Otros mensajes de error pueden revelar más pistas evasivas acerca del sistema. En el Example 1, la información perdida podría implicar información sobre el tipo de sistema operativo, las aplicaciones instaladas en el sistema y cuánto esfuerzo han hecho los administradores para configurar el programa. Por supuesto, otro problema con el Example 1 es recuperar la Exception raíz en vez de un tipo específico de error/excepción, lo que significa que filtrará todas las excepciones, causando potencialmente otros efectos secundarios no considerados.

Se producen pérdidas de información internas cuando los datos del sistema o la información de depuración se envían a un archivo local, a una consola o a una pantalla mediante impresión o creación de registros.

Ejemplo 1: El siguiente código imprime información del sistema en una secuencia de salida estándar:

...
println(Properties.osName)
...

En función de la configuración del sistema, esta información se puede volcar en una consola, escribir en un archivo de registro o mostrar a un usuario. En algunos casos, el mensaje de error indica al atacante a qué tipo de ataque específico es vulnerable el sistema. Por ejemplo, un mensaje de error de base de datos puede revelar que la aplicación es vulnerable a ataques de inyección de SQL. Otros mensajes de error pueden revelar más pistas evasivas acerca del sistema. En el Example 1, la información perdida podría implicar información sobre el tipo de sistema operativo, las aplicaciones instaladas en el sistema y cuánto esfuerzo han hecho los administradores para configurar el programa.

Se producen fugas de información internas cuando los datos del sistema o la información de depuración se envían mediante creación de registros o impresión a un archivo local, a una consola o a una pantalla.



En el mundo móvil, surgen otras áreas de preocupación sobre el mantenimiento de la información del sistema cuando se pierde o se roba un dispositivo. Una vez en posesión de un dispositivo iOS, un atacante puede acceder a gran cantidad de datos conectando el dispositivo por USB. Los archivos de tipo Lista de propiedades de iOS y las bases de datos de SQLite son fácilmente accesibles y pueden revelar información personal. Como regla general, la información relacionada con la privacidad no debe almacenarse sin protección en el sistema de archivos.

Ejemplo: El siguiente código imprime el identificador del dispositivo en los registros del sistema:

let deviceName = UIDevice.currentDevice().name
...
NSLog("Device Identifier: %@", deviceName)

En función de la configuración del sistema, esta información se puede volcar en una consola, escribir en un archivo de registro o mostrar a un usuario. En algunos casos, el mensaje de error indica al usuario malintencionado con precisión a qué tipo de ataque será vulnerable el sistema. Por ejemplo, un mensaje de error de base de datos puede revelar que la aplicación es vulnerable a ataques de SQL Injection. Otros mensajes de error pueden revelar más pistas evasivas acerca del sistema.

Se producen pérdidas de información internas cuando los datos del sistema o la información de depuración se envían a un archivo local, a una consola o a una pantalla mediante impresión o creación de registros.

Ejemplo: El siguiente código envía un objeto ASPError a un depurador de secuencia de comandos, como Microsoft Script Debugger:

...
Debug.Write Server.GetLastError()
...

En algunos casos el mensaje de error indica al usuario malintencionado con precisión a qué tipo de ataque es vulnerable el sistema. Por ejemplo, un mensaje de error de base de datos puede revelar que la aplicación es vulnerable a ataques de SQL Injection. Otros mensajes de error pueden revelar pistas más indirectas acerca del sistema, tales como información acerca del tipo de sistema operativo, las aplicaciones instaladas en el sistema y cuánto cuidado han puesto los administradores al configurar el programa.

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

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: 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. 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: los programadores utilizan a menudo la reflexión para implementar distribuidores de comandos. En el siguiente ejemplo se muestra un distribuidor de comandos que no utiliza la reflexión:

...
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 New 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 se encarga del control de acceso, cada vez que los programadores creen un número método en la clase Worker, deben acordarse de modificar la lógica de control de acceso del distribuidor. Si esta lógica de control de acceso se queda obsoleta, algunos métodos 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 New 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.

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

La inyección de la entidad externa de XML (XXE) se produce cuando:

1. Los datos entran en un programa desde un origen que no es de confianza.

2. Los datos se escriben en un elemento <ENTITY> de la definición de tipo de documento (DTD, Document Type Definition) en un documento XML.

Normalmente, las aplicaciones utilizan XML para almacenar datos y enviar mensajes. Cuando se utiliza para almacenar datos, los documentos XML se tratan a menudo como bases de datos y es posible que contengan información confidencial. Los mensajes XML normalmente se utilizan en los servicios web y también pueden usarse para transmitir información confidencial. Incluso se pueden utilizar mensajes XML para enviar credenciales de autenticación.

La semántica de los documentos y mensajes XML se puede modificar si un atacante tiene la capacidad de escribir XML sin formato. En los casos más benignos, es posible que un atacante pueda ser capaz de insertar referencias a entidades anidadas y hacer que un analizador XML consuma cada vez mayores cantidades de recursos de la CPU. En los casos más nefastos de inyección de entidad externa de XML, un atacante puede ser capaz de agregar elementos XML que expongan el contenido de los recursos del sistema de archivos locales o que revelen la existencia de recursos de red interna.

Ejemplo 1:aquí se muestra parte del código Objective-C que es vulnerable a ataques de XXE:

- (void) parseSomeXML: (NSString *) rawXml {

    BOOL success;
    NSData *rawXmlConvToData = [rawXml dataUsingEncoding:NSUTF8StringEncoding];
    NSXMLParser *myParser = [[NSXMLParser alloc] initWithData:rawXmlConvToData];
    [myParser setShouldResolveExternalEntities:YES];
    [myParser setDelegate:self];
}

Supongamos que un usuario malintencionado es capaz de controlar rawXml de tal forma que el código XML sea similar al siguiente:

 <?xml version="1.0" encoding="ISO-8859-1"?>
 <!DOCTYPE foo [
   <!ELEMENT foo ANY >
   <!ENTITY xxe SYSTEM "file:///c:/boot.ini" >]><foo>&xxe;</foo>

Cuando el servidor evalúe el XML, el elemento <foo> incluirá el contenido del archivo boot.ini.

Los ataques de entidades externas de XML se benefician de una función de XML para crear documentos de forma dinámica en el momento de procesamiento. Una entidad XML permite la inclusión de datos de forma dinámica desde un recurso dado. Las entidades externas permiten a un documento XML incluir datos desde un URI externo. A menos que se configure de otra forma, las entidades externas fuerzan al analizador de XML a acceder al recurso que especifica el URI, como por ejemplo un archivo del equipo local o de un sistema remoto. Este comportamiento expone la aplicación a ataques de entidades externas (XXE) de XML, los cuales se pueden utilizar para llevar a cabo una denegación de servicio del sistema local, obtener acceso no autorizado a archivos del equipo local, explorar equipos remotos y denegar el servicio de sistemas remotos.

En el siguiente documento XML se muestra un ejemplo de un ataque XXE.

<?xml version="1.0" encoding="ISO-8859-1"?>
 <!DOCTYPE foo [
  <!ELEMENT foo ANY >
  <!ENTITY xxe SYSTEM "file:///dev/random" >]><foo>&xxe;</foo>

Este ejemplo puede producir el bloqueo del servidor (en un sistema UNIX) en caso de que el analizador de XML intente sustituir la entidad que tenga el contenido del archivo /dev/random.

Los ataques de entidades externas de XML se benefician de una característica de XML para crear documentos de forma dinámica en tiempo de ejecución. Una entidad XML permite la inclusión de datos de forma dinámica desde un recurso dado. Las entidades externas permiten a un documento XML incluir datos desde un URI externo. A menos que se configure de otra forma, las entidades externas fuerzan al analizador de XML a acceder al recurso que especifica el URI, como, por ejemplo, un archivo del equipo local o de un sistema remoto. Este comportamiento expone la aplicación a ataques de entidades externas (XXE) de XML, que permite a los atacantes llevar a cabo una denegación de servicio del sistema local, obtener acceso no autorizado a archivos del equipo local, explorar equipos remotos y denegar el servicio de sistemas remotos.


Ejemplo 1: El siguiente documento XML muestra un ejemplo de ataque XXE.

<?xml version="1.0" encoding="ISO-8859-1"?>
 <!DOCTYPE foo [
  <!ELEMENT foo ANY >
  <!ENTITY xxe SYSTEM "file:///dev/random" >]><foo>&xxe;</foo>

Este ejemplo podría bloquear el servidor (en un sistema UNIX) si el analizador XML intenta sustituir la entidad con el contenido del archivo /dev/random.

La inyección de la entidad externa de XML (XXE) se produce cuando:

1. Los datos entran en un programa desde un origen que no es de confianza.

2. Los datos se escriben en un elemento <ENTITY> de la DTD (Document Type Definition) en un documento XML.

Normalmente, las aplicaciones utilizan XML para almacenar datos y enviar mensajes. Cuando se utiliza para almacenar datos, los documentos XML se tratan a menudo como bases de datos y es posible que contengan información confidencial. Los mensajes XML normalmente se utilizan en los servicios web y también pueden usarse para transmitir información confidencial. Incluso se pueden utilizar mensajes XML para enviar credenciales de autenticación.

La semántica de los documentos y mensajes XML se puede modificar si un atacante tiene la capacidad de escribir XML sin formato. En los casos más benignos, es posible que un atacante pueda ser capaz de insertar referencias a entidades anidadas y hacer que un analizador XML consuma cada vez mayores cantidades de recursos de la CPU. En los casos más nefastos de inyección de entidad externa de XML, un atacante puede ser capaz de agregar elementos XML que expongan el contenido de los recursos del sistema de archivos locales o que revelen la existencia de recursos de red interna.

Ejemplo 1:aquí se muestra parte del código que es vulnerable a ataques de XXE:

- (void) parseSomeXML: (NSString *) rawXml {

    BOOL success;
    NSData *rawXmlConvToData = [rawXml dataUsingEncoding:NSUTF8StringEncoding];
    NSXMLParser *myParser = [[NSXMLParser alloc] initWithData:rawXmlConvToData];
    [myParser setShouldResolveExternalEntities:YES];
    [myParser setDelegate:self];
}

Supongamos que un usuario malintencionado es capaz de controlar rawXml de tal forma que el código XML sea similar al siguiente:

 <?xml version="1.0" encoding="ISO-8859-1"?>
 <!DOCTYPE foo [
   <!ELEMENT foo ANY >
   <!ENTITY xxe SYSTEM "file:///c:/boot.ini" >]><foo>&xxe;</foo>

Cuando el servidor evalúe el XML, el elemento <foo> incluirá el contenido del archivo boot.ini.

La inyección de la entidad externa de XML (XXE) se produce cuando:

1. Los datos entran en un programa desde un origen que no es de confianza.

2. Los datos se escriben en un documento XML.

Normalmente, las aplicaciones utilizan XML para almacenar datos y enviar mensajes. Cuando se utiliza para almacenar datos, los documentos XML se tratan a menudo como bases de datos y es posible que contengan información confidencial. Los mensajes XML normalmente se utilizan en los servicios web y también pueden usarse para transmitir información confidencial. Incluso se pueden utilizar mensajes XML para enviar credenciales de autenticación.

La semántica de los documentos y mensajes XML se puede modificar si un atacante tiene la capacidad de escribir XML sin formato. En los casos más benignos, es posible que un atacante pueda insertar referencias a entidades anidadas y hacer que un analizador XML consuma cada vez mayores cantidades de recursos de la CPU. En los casos más nefastos de inyección de entidad externa de XML, un atacante puede ser capaz de agregar elementos XML que exponen el contenido de los recursos del sistema de archivos locales, revelen la existencia de recursos de red interna o expongan el mismo contenido back-end.

Ejemplo 1:aquí se muestra parte del código que es vulnerable a ataques de XXE:

Supongamos que un usuario malintencionado es capaz de controlar el XML de entrada al siguiente código:

...
<?php
$goodXML = $_GET["key"];
$doc = simplexml_load_string($goodXml);
echo $doc->testing;
?>
...

Ahora imaginemos que el usuario malintencionado pasa el siguiente código XML al código del Example 2:

<?xml version="1.0" encoding="ISO-8859-1"?>
 <!DOCTYPE foo [
   <!ELEMENT foo ANY >
   <!ENTITY xxe SYSTEM "file:///c:/boot.ini" >]><foo>&xxe;</foo>

Cuando se procesa el código XML, el contenido del elemento <foo> se rellena con el contenido del archivo boot.ini del sistema. El atacante podría utilizar los elementos XML que se devuelven al cliente para extraer datos u obtener información sobre la existencia de recursos de red.

Los ataques de entidades externas de XML se benefician de una característica de XML para crear documentos de forma dinámica en tiempo de ejecución. Una entidad XML permite la inclusión de datos de forma dinámica desde un recurso dado. Las entidades externas permiten a un documento XML incluir datos desde un URI externo. A menos que se configure de otra forma, las entidades externas fuerzan al analizador de XML a acceder al recurso que especifica el URI, como, por ejemplo, un archivo del equipo local o de un sistema remoto. Este comportamiento expone la aplicación a ataques de entidades externas (XXE) de XML, que los atacantes pueden utilizar para llevar a cabo una denegación de servicio del sistema local, obtener acceso no autorizado a archivos del equipo local, explorar equipos remotos y denegar el servicio de sistemas remotos.


Ejemplo 1: en el siguiente documento XML se muestra un ejemplo de ataque XXE.

<?xml version="1.0" encoding="ISO-8859-1"?>
 <!DOCTYPE foo [
  <!ELEMENT foo ANY >
  <!ENTITY xxe SYSTEM "file:///dev/random" >]><foo>&xxe;</foo>

Este ejemplo puede producir el bloqueo del servidor (en un sistema UNIX) en caso de que el analizador de XML intente sustituir la entidad que tenga el contenido del archivo /dev/random.

Los ataques de entidades externas de XML se benefician de una función de XML para crear documentos de forma dinámica en el momento de procesamiento. Una entidad XML permite la inclusión de datos de forma dinámica desde un recurso dado. Las entidades externas permiten a un documento XML incluir datos desde un URI externo. A menos que se configure de otra forma, las entidades externas fuerzan al analizador de XML a acceder al recurso que especifica el URI, como por ejemplo un archivo del equipo local o de un sistema remoto. Este comportamiento expone la aplicación a ataques de entidades externas (XXE) de XML, los cuales se pueden utilizar para llevar a cabo una denegación de servicio del sistema local, obtener acceso no autorizado a archivos del equipo local, explorar equipos remotos y denegar el servicio de sistemas remotos.

En el siguiente documento XML se muestra un ejemplo de un ataque XXE.

<?xml version="1.0" encoding="ISO-8859-1"?>
 <!DOCTYPE foo [
  <!ELEMENT foo ANY >
  <!ENTITY xxe SYSTEM "file:///etc/passwd" >]><foo>&xxe;</foo>

El documento XML de ejemplo leerá el contenido de /etc/passwd y lo incluirá en el documento.

Ejemplo 1: El siguiente código usa un analizador de XML no seguro para procesar la entrada que no es de confianza de una solicitud HTTP.

def readFile() = Action { request =>
    val xml = request.cookies.get("doc")
    val doc = XMLLoader.loadString(xml)
    ...
}

La inyección de la entidad externa de XML (XXE) se produce cuando:

1. Los datos entran en un programa desde un origen que no es de confianza.

2. Los datos se escriben en un elemento <ENTITY> de la definición de tipo de documento (DTD, Document Type Definition) en un documento XML.

Normalmente, las aplicaciones utilizan XML para almacenar datos y enviar mensajes. Cuando se utiliza para almacenar datos, los documentos XML se tratan a menudo como bases de datos y es posible que contengan información confidencial. Los mensajes XML normalmente se utilizan en los servicios web y también pueden usarse para transmitir información confidencial. Incluso se pueden utilizar mensajes XML para enviar credenciales de autenticación.

La semántica de los documentos y mensajes XML se puede modificar si un atacante tiene la capacidad de escribir XML sin formato. En los casos más benignos, es posible que un atacante pueda ser capaz de insertar referencias a entidades anidadas y hacer que un analizador XML consuma cada vez mayores cantidades de recursos de la CPU. En los casos más nefastos de inyección de entidad externa de XML, un atacante puede ser capaz de agregar elementos XML que expongan el contenido de los recursos del sistema de archivos locales o que revelen la existencia de recursos de red interna.

Ejemplo 1:aquí se muestra parte del código que es vulnerable a ataques de XXE:

func parseXML(xml: String) {
    parser = NSXMLParser(data: rawXml.dataUsingEncoding(NSUTF8StringEncoding)!)
    parser.delegate = self
    parser.shouldResolveExternalEntities = true
    parser.parse()
}

Supongamos que un usuario malintencionado es capaz de controlar el contenido de rawXml de tal forma que el código XML sea similar al siguiente:

 <?xml version="1.0" encoding="ISO-8859-1"?>
 <!DOCTYPE foo [
   <!ELEMENT foo ANY >
   <!ENTITY xxe SYSTEM "file:///c:/boot.ini" >]><foo>&xxe;</foo>

Cuando el servidor evalúe el XML, el elemento <foo> incluirá el contenido del archivo boot.ini.

La inserción XML se produce cuando:

1. Los datos entran en un programa desde un origen que no es de confianza.


2. Los datos se escriben en un documento XML.

Normalmente, las aplicaciones utilizan XML para almacenar datos y enviar mensajes. Cuando se utiliza para almacenar datos, los documentos XML se tratan a menudo como bases de datos y es posible que contengan información confidencial. Los mensajes XML normalmente se utilizan en los servicios web y también pueden usarse para transmitir información confidencial. Incluso se pueden utilizar mensajes XML para enviar credenciales de autenticación.

La semántica de los documentos y mensajes XML se puede modificar si un atacante tiene la capacidad de escribir XML sin formato. En el caso menos malicioso, un atacante podría insertar etiquetas extrañas y hacer que un analizador XML iniciase una excepción. En casos más nefastos de inyección de código XML, un atacante puede ser capaz de añadir elementos XML que cambien las credenciales de autenticación o modifiquen los precios de una base de datos de comercio electrónico en XML. En algunos casos, la inyección de código XML puede dar lugar a Cross-Site Scripting o evaluación de código dinámico.

Ejemplo 1:

Supongamos que un atacante puede controlar shoes en el siguiente documento XML.

<order>
   <price>100.00</price>
   <item>shoes</item>
</order>

Ahora, suponga que este documento XML está incluido en una solicitud de servicio web back-end para realizar un pedido de un par de zapatos. Supongamos que el atacante modifica su solicitud y sustituye shoes por shoes</item><price>1.00</price><item>shoes. El nuevo documento XML sería:

<order>
    <price>100.00</price>
    <item>shoes</item><price>1.00</price><item>shoes</item>
</order>

Cuando se utilizan analizadores SAX, el valor de la segunda etiqueta <price> anula el valor de la primera etiqueta <price>. Esto permite que el atacante compre un par de zapatos de 100 $ a 1 $.

La inyección XML se produce cuando sucede lo siguiente:

1. Los datos se introducen en un programa desde un origen que no es de confianza.

2. Los datos se escriben en un documento XML.

Normalmente, las aplicaciones utilizan XML para almacenar datos y enviar mensajes. Cuando se utiliza para almacenar datos, los documentos XML se tratan a menudo como bases de datos y es posible que contengan información confidencial. Los mensajes XML normalmente se utilizan en los servicios web y también pueden usarse para transmitir información confidencial. Incluso se pueden utilizar mensajes XML para enviar credenciales de autenticación.

La semántica de los documentos y mensajes XML se puede modificar si un atacante tiene la capacidad de escribir XML sin formato. En el caso menos malicioso, un atacante puede insertar etiquetas extrañas y hacer que un analizador XML genere una excepción. En casos más nefastos de inyección XML, un atacante puede agregar elementos XML que cambien las credenciales de autenticación o modifiquen los precios de una base de datos de comercio electrónico en XML. En ocasiones, la inyección XML puede dar lugar a scripts de sitios o una evaluación de código dinámico.

Ejemplo 1:

Supongamos que un atacante puede controlar shoes en el siguiente documento XML:

<order>
   <price>100.00</price>
   <item>shoes</item>
</order>

Ahora, supongamos que este XML está incluido en una solicitud de servicio web back-end para realizar un pedido de un par de zapatos. Supongamos que el atacante modifica su solicitud y sustituye shoes por shoes</item><price>1.00</price><item>shoes. El XML nuevo tendría este aspecto:

<order>
    <price>100.00</price>
    <item>shoes</item><price>1.00</price><item>shoes</item>
</order>

Cuando se utilizan analizadores SAX, el valor de la segunda etiqueta <price> anula el valor de la primera etiqueta <price>. Esto permite que el atacante compre un par de zapatos de $ 100 a $ 1.

La inserción XML se produce cuando:

1. Los datos entran en un programa desde un origen que no es de confianza.

2. Los datos se escriben en un documento XML.

Normalmente, las aplicaciones utilizan XML para almacenar datos y enviar mensajes. Cuando se utiliza para almacenar datos, los documentos XML se tratan a menudo como bases de datos y es posible que contengan información confidencial. Los mensajes XML normalmente se utilizan en los servicios web y también pueden usarse para transmitir información confidencial. Incluso se pueden utilizar mensajes XML para enviar credenciales de autenticación.

La semántica de los documentos y mensajes XML se puede modificar si un atacante tiene la capacidad de escribir XML sin formato. En el caso menos malicioso, un atacante podría insertar etiquetas extrañas y hacer que un analizador XML iniciase una excepción. En casos más nefastos de inyección de código XML, un atacante puede ser capaz de añadir elementos XML que cambien las credenciales de autenticación o modifiquen los precios de una base de datos de comercio electrónico en XML. En algunos casos, la inyección de código XML puede dar lugar a Cross-Site Scripting o evaluación de código dinámico.

Ejemplo 1:

Supongamos que un atacante puede controlar shoes en el siguiente documento XML.

<order>
   <price>100.00</price>
   <item>shoes</item>
</order>

Ahora, suponga que este documento XML está incluido en una solicitud de servicio web back-end para realizar un pedido de un par de zapatos. Supongamos que el atacante modifica su solicitud y sustituye shoes por shoes</item><price>1.00</price><item>shoes. El nuevo documento XML sería:

<order>
    <price>100.00</price>
    <item>shoes</item><price>1.00</price><item>shoes</item>
</order>

Cuando se utilizan analizadores SAX, el valor de la segunda etiqueta <price> anula el valor de la primera etiqueta <price>. Esto permite que el atacante compre un par de zapatos de 100 $ a 1 $.

La inserción XML se produce cuando:

1. Los datos entran en un programa desde un origen que no es de confianza.


2. Los datos se escriben en un documento XML.

Normalmente, las aplicaciones utilizan XML para almacenar datos y enviar mensajes. Cuando se utiliza para almacenar datos, los documentos XML se tratan a menudo como bases de datos y es posible que contengan información confidencial. Los mensajes XML normalmente se utilizan en los servicios web y también pueden usarse para transmitir información confidencial. Incluso se pueden utilizar mensajes XML para enviar credenciales de autenticación.

La semántica de los documentos y mensajes XML se puede modificar si un atacante tiene la capacidad de escribir XML sin formato. En el caso menos malicioso, un atacante podría insertar etiquetas extrañas y hacer que un analizador XML iniciase una excepción. En casos más nefastos de inyección de código XML, un atacante puede ser capaz de añadir elementos XML que cambien las credenciales de autenticación o modifiquen los precios de una base de datos de comercio electrónico en XML. En algunos casos, la inyección de código XML puede dar lugar a Cross-Site Scripting o evaluación de código dinámico.

Ejemplo 1:

Supongamos que un atacante puede controlar shoes en el siguiente documento XML:

<order>
   <price>100.00</price>
   <item>shoes</item>
</order>

Ahora, suponga que este documento XML está incluido en una solicitud de servicio web back-end para realizar un pedido de un par de zapatos. Supongamos que el atacante modifica su solicitud y sustituye shoes por shoes</item><price>1.00</price><item>shoes. El nuevo documento XML sería:

<order>
    <price>100.00</price>
    <item>shoes</item><price>1.00</price><item>shoes</item>
</order>

Esto puede permitir que el atacante compre un par de zapatos de 100 $ a 1 $.

La inserción XML se produce cuando:

1. Los datos entran en un programa desde un origen que no es de confianza.


2. Los datos se escriben en un documento XML.

Normalmente, las aplicaciones utilizan XML para almacenar datos y enviar mensajes. Cuando se utiliza para almacenar datos, los documentos XML se tratan a menudo como bases de datos y es posible que contengan información confidencial. Los mensajes XML normalmente se utilizan en los servicios web y también pueden usarse para transmitir información confidencial. Incluso se pueden utilizar mensajes XML para enviar credenciales de autenticación.

La semántica de los documentos y mensajes XML se puede modificar si un atacante tiene la capacidad de escribir XML sin formato. En el caso menos malicioso, un atacante podría insertar etiquetas extrañas y hacer que un analizador XML iniciase una excepción. En casos más nefastos de inyección de código XML, un atacante puede ser capaz de añadir elementos XML que cambien las credenciales de autenticación o modifiquen los precios de una base de datos de comercio electrónico en XML. En algunos casos, la inyección de código XML puede dar lugar a Cross-Site Scripting o evaluación de código dinámico.

Ejemplo 1:

Supongamos que un atacante puede controlar shoes en el siguiente documento XML.

<order>
   <price>100.00</price>
   <item>shoes</item>
</order>

Ahora, suponga que este documento XML está incluido en una solicitud de servicio web back-end para realizar un pedido de un par de zapatos. Supongamos que el atacante modifica su solicitud y sustituye shoes por shoes</item><price>1.00</price><item>shoes. El nuevo documento XML sería:

<order>
    <price>100.00</price>
    <item>shoes</item><price>1.00</price><item>shoes</item>
</order>

Cuando se utilizan analizadores SAX, el valor de la segunda etiqueta <price> anula el valor de la primera etiqueta <price>. Esto permite que el atacante compre un par de zapatos de 100 $ a 1 $.