Se producen errores de control de acceso de base de datos cuando:

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


2. Los datos se utilizan para especificar el valor de una clave principal en una consulta SQL.
Ejemplo 1: el código siguiente utiliza una instrucción que se basa en un número entero y, por tanto, no es vulnerable a las vulnerabilidades de SQL Injection, para crear y ejecutar una consulta SQL que busca una factura que coincida con el identificador especificado [1]. El identificador se selecciona de una lista de todas las facturas asociadas al usuario autenticado actual.

DATA: id TYPE i.
...
id = request->get_form_field( 'invoiceID' ).

CONCATENATE `INVOICEID = '` id `'` INTO cl_where.
SELECT *
    FROM invoices
    INTO CORRESPONDING FIELDS OF TABLE itab_invoices
    WHERE (cl_where).
ENDSELECT.
...

El problema es que el desarrollador no ha tenido en cuenta todos los valores posibles de ID. Aunque la interfaz genera una lista de identificadores de factura que pertenecen al usuario actual, un atacante puede eludir esta interfaz para solicitar cualquier factura que desee. Dado que el código de este ejemplo no comprueba si el usuario tiene permiso para acceder a la factura solicitada, se mostrará cualquier factura, incluso si no pertenece al usuario actual.

Se producen errores de control de acceso de base de datos cuando:

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


2. Los datos se utilizan para especificar el valor de una clave principal en una consulta SQL.
Ejemplo 1: el siguiente código utiliza una instrucción parametrizada, que aplica caracteres de escape a metacaracteres e impide la inclusión de vulnerabilidades de SQL Injection, para crear y ejecutar una consulta SQL que busca una factura que coincida con el identificador especificado [1]. El identificador se selecciona de una lista de todas las facturas asociadas al usuario autenticado actual.

        ...
        var params:Object = LoaderInfo(this.root.loaderInfo).parameters;
        var id:int = int(Number(params["invoiceID"]));
        var query:String = "SELECT * FROM invoices WHERE id = :id";

        stmt.sqlConnection = conn;
        stmt.text = query;
        stmt.parameters[":id"] = id;
        stmt.execute();
        ...

El problema es que el desarrollador no ha tenido en cuenta todos los valores posibles de id. Aunque la interfaz genera una lista de identificadores de factura que pertenecen al usuario actual, un atacante puede eludir esta interfaz para solicitar cualquier factura que desee. Dado que el código de este ejemplo no comprueba si el usuario tiene permiso para acceder a la factura solicitada, se mostrará cualquier factura, incluso si no pertenece al usuario actual.

Se producen errores de control de acceso de base de datos cuando:

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


2. Los datos se utilizan para especificar el valor de una clave principal en una consulta SOQL/SOSL.
Ejemplo 1: en el siguiente ejemplo de código, el valor inputID se origina a partir de una lista definida previamente, y una variable de enlace contribuye a evitar la inyección de SOQL/SOSL.

...
result = [SELECT Name, Phone FROM Contact WHERE (IsDeleted = false AND Id=:inputID)];
...

El problema con el ejemplo anterior es que el uso de una lista de identificadores definida previamente no es suficiente para evitar que el usuario modifique el valor de inputID. Si el atacante es capaz de evitar la interfaz y enviar una solicitud con un valor diferente, tendrá acceso a otra información de contacto. Dado que el código en este ejemplo no realiza una comprobación para asegurarse de que el usuario tiene permiso para acceder al contacto solicitado, se mostrará cualquier contacto, incluso si el usuario no tiene permiso para verlo.

Se producen errores de control de acceso de base de datos cuando:

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

2. Los datos se utilizan para especificar el valor de una clave principal en una consulta LINQ.
Ejemplo 1: el siguiente código ejecuta una consulta LINQ que busca una factura que coincide con el identificador especificado [1]. El identificador se selecciona de una lista de todas las facturas asociadas al usuario autenticado actual.

...

int16 id = System.Convert.ToInt16(invoiceID.Text);
var invoice = OrderSystem.getInvoices()
	.Where(new Invoice { invoiceID = id });
...

El problema es que el desarrollador no ha tenido en cuenta todos los valores posibles de id. Aunque la interfaz genera una lista de identificadores de factura que pertenecen al usuario actual, un atacante puede eludir esta interfaz para solicitar cualquier factura que desee. Dado que el código de este ejemplo no comprueba si el usuario tiene permiso para acceder a la factura solicitada, se mostrará cualquier factura, incluso si no pertenece al usuario actual.

Se producen errores de control de acceso de base de datos cuando:

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


2. Los datos se utilizan para especificar el valor de una clave principal en una consulta SQL.
Ejemplo 1: el siguiente código utiliza una instrucción parametrizada, que aplica caracteres de escape a metacaracteres e impide la inclusión de vulnerabilidades de SQL Injection, para crear y ejecutar una consulta SQL que busca una factura que coincida con el identificador especificado [1]. El identificador se selecciona de una lista de todas las facturas asociadas al usuario autenticado actual.

...
CMyRecordset rs(&dbms);
rs.PrepareSQL("SELECT * FROM invoices WHERE id = ?");
rs.SetParam_int(0,atoi(r.Lookup("invoiceID").c_str()));
rs.SafeExecuteSQL();
...

El problema es que el desarrollador no ha tenido en cuenta todos los valores posibles de id. Aunque la interfaz genera una lista de identificadores de factura que pertenecen al usuario actual, un atacante puede eludir esta interfaz para solicitar cualquier factura que desee. Dado que el código de este ejemplo no comprueba si el usuario tiene permiso para acceder a la factura solicitada, se mostrará cualquier factura, incluso si no pertenece al usuario actual.

Se producen errores de control de acceso de base de datos cuando:

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


2. Los datos se utilizan para especificar el valor de una clave principal en una consulta SQL.
Ejemplo 1: el siguiente código utiliza una instrucción parametrizada, que establece secuencias de escape metacaracteres e impide las vulnerabilidades de SQL Injection, para crear y ejecutar una consulta SQL que busca una factura que coincida con el identificador especificado [1]. El identificador se selecciona de una lista de todas las facturas asociadas al usuario autenticado actual.

...
ACCEPT ID.
EXEC SQL
    DECLARE C1 CURSOR FOR
    SELECT INVNO, INVDATE, INVTOTAL
    FROM INVOICES
    WHERE INVOICEID = :ID
END-EXEC.
...

El problema es que el desarrollador no ha tenido en cuenta todos los valores posibles de ID. Aunque la interfaz genera una lista de identificadores de factura que pertenecen al usuario actual, un atacante puede eludir esta interfaz para solicitar cualquier factura que desee. Dado que el código de este ejemplo no comprueba si el usuario tiene permiso para acceder a la factura solicitada, se mostrará cualquier factura, incluso si no pertenece al usuario actual.

Se producen errores de control de acceso de base de datos cuando:

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


2. Los datos se utilizan para especificar el valor del nombre de una base de datos.

Se producen errores de control de acceso de base de datos cuando:

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


2. Los datos se utilizan para especificar el valor de una clave principal en una consulta SQL.
Ejemplo 1: El siguiente código utiliza una instrucción parametrizada, la cual establece secuencias de escape para los metacaracteres e impide las vulnerabilidades SQL Injection, para crear y ejecutar una consulta SQL que busque una factura que coincida con el identificador especificado [1]. El identificador se selecciona de una lista de todas las facturas asociadas al usuario autenticado actual.

...
id := request.FormValue("invoiceID")
query := "SELECT * FROM invoices WHERE id = ?";
rows, err := db.Query(query, id)
...

El problema es que el desarrollador no ha tenido en cuenta todos los valores posibles de id. Aunque la interfaz genera una lista de identificadores de factura que pertenecen al usuario actual, un atacante puede eludir esta interfaz para solicitar cualquier factura que desee. Dado que el código de este ejemplo no comprueba si el usuario tiene permiso para acceder a la factura solicitada, se mostrará cualquier factura, incluso si no pertenece al usuario actual.

Se producen errores de control de acceso de base de datos cuando:

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


2. Los datos se utilizan para especificar el valor de una clave principal en una consulta SQL.
Example 1: The following code uses a parameterized statement, which escapes metacharacters and prevents SQL injection vulnerabilities, to construct and execute a SQL query that searches for an invoice matching the specified identifier [1]. El identificador se selecciona de una lista de todas las facturas asociadas al usuario autenticado actual.

...
id = Integer.decode(request.getParameter("invoiceID"));
String query = "SELECT * FROM invoices WHERE id = ?";
PreparedStatement stmt = conn.prepareStatement(query);
stmt.setInt(1, id);
ResultSet results = stmt.execute();
...

El problema es que el desarrollador no ha tenido en cuenta todos los valores posibles de id. Aunque la interfaz genera una lista de identificadores de factura que pertenecen al usuario actual, un atacante puede eludir esta interfaz para solicitar cualquier factura que desee. Dado que el código de este ejemplo no comprueba si el usuario tiene permiso para acceder a la factura solicitada, se mostrará cualquier factura, incluso si no pertenece al usuario actual.

Algunos piensan que en el mundo de las plataformas móviles, las vulnerabilidades de las aplicaciones web clásicas, como los errores de control de acceso a bases de datos, no tienen ningún sentido: ¿por qué se atacaría un usuario a sí mismo? Sin embargo, tenga en cuenta que la esencia de las plataformas móviles consiste en aplicaciones que se descargan desde varias fuentes y se ejecutan junto con otras en el mismo dispositivo. La probabilidad de ejecutar un malware junto a una aplicación de banca es bastante alta, de modo que se necesita expandir la superficie expuesta a ataques de las aplicaciones móviles para que incluyan las comunicaciones entre procesos.

Ejemplo 2: el siguiente código adapta el Example 1 a la plataforma Android.

...
        String id = this.getIntent().getExtras().getString("invoiceID");
        String query = "SELECT * FROM invoices WHERE id = ?";
        SQLiteDatabase db = this.openOrCreateDatabase("DB", MODE_PRIVATE, null);
        Cursor c = db.rawQuery(query, new Object[]{id});
...

Varios marcos web modernos proporcionan mecanismos para realizar la validación de la entrada del usuario (entre ellos, Struts y Struts 2). Para resaltar los orígenes no validados de entrada, los Paquetes de reglas de codificación segura de Fortify vuelven a priorizar dinámicamente los problemas notificados por Fortify Static Code Analyzer reduciendo la probabilidad de ataques y ofreciendo argumentos para los elementos probatorios cada vez que el mecanismo de validación de la estructura está en uso. Esta característica recibe el nombre de clasificación basada en contexto. A modo de ayuda extra para el usuario de Fortify con el proceso de auditoría, Fortify Software Security Research Group facilita la plantilla de proyecto de validación de datos que agrupa los problemas en carpetas en función del mecanismo de validación aplicado al origen de la entrada.

Se producen errores de control de acceso de base de datos cuando:

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


2. Los datos se utilizan para especificar el valor de una clave principal en una consulta SQL.
Ejemplo 1: el siguiente código utiliza una instrucción parametrizada, que aplica caracteres de escape a metacaracteres e impide la inclusión de vulnerabilidades de SQL Injection, para crear y ejecutar una consulta SQL que busca una factura que coincida con el identificador especificado [1]. El identificador se selecciona de una lista de todas las facturas asociadas al usuario autenticado actual.

	...
	var id = document.form.invoiceID.value;
	var query = "SELECT * FROM invoices WHERE id = ?";
	db.transaction(function (tx) {
		tx.executeSql(query,[id]);
		}
	)
	...

El problema es que el desarrollador no ha tenido en cuenta todos los valores posibles de id. Aunque la interfaz genera una lista de identificadores de factura que pertenecen al usuario actual, un atacante puede eludir esta interfaz para solicitar cualquier factura que desee. Dado que el código de este ejemplo no comprueba si el usuario tiene permiso para acceder a la factura solicitada, se mostrará cualquier factura, incluso si no pertenece al usuario actual.

Se producen errores de control de acceso de base de datos cuando:

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


2.Los datos se utilizan para especificar el valor de una clave principal en una consulta SQL.
Ejemplo 1: el siguiente código utiliza una instrucción parametrizada, que aplica caracteres de escape a metacaracteres e impide la inclusión de vulnerabilidades de SQL Injection para crear y ejecutar una consulta SQL que busca una factura que coincida con el identificador especificado. El identificador se selecciona de una lista de todas las facturas asociadas al usuario autenticado actual.

...

        NSManagedObjectContext *context = [appDelegate managedObjectContext];
        NSEntityDescription *entityDesc = [NSEntityDescription entityForName:@"Invoices" inManagedObjectContext:context];
        NSFetchRequest *request = [[NSFetchRequest alloc] init];
        [request setEntity:entityDesc];
        NSPredicate *pred = [NSPredicate predicateWithFormat:@"(id = %@)", invoiceId.text];
        [request setPredicate:pred];

        NSManagedObject *matches = nil;
        NSError *error;
        NSArray *objects = [context executeFetchRequest:request error:&error];

        if ([objects count] == 0) {
                 status.text = @"No records found.";
        } else {
                matches = [objects objectAtIndex:0];
                invoiceReferenceNumber.text = [matches valueForKey:@"invRefNum"];
                orderNumber.text = [matches valueForKey:@"orderNumber"];
                status.text = [NSString stringWithFormat:@"%d records found", [objects count]];
        }
        [request release];
...

El problema es que el desarrollador no ha tenido en cuenta todos los valores posibles de id. Aunque la interfaz genera una lista de identificadores de factura que pertenecen al usuario actual, un atacante puede eludir esta interfaz para solicitar cualquier factura que desee. Dado que el código de este ejemplo no comprueba si el usuario tiene permiso para acceder a la factura solicitada, se mostrará cualquier factura, incluso si no pertenece al usuario actual.

Se producen errores de control de acceso de base de datos cuando:

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


2. Los datos se utilizan para especificar el valor de una clave principal en una consulta SQL.
Example 1: The following code uses a parameterized statement, which escapes metacharacters and prevents SQL injection vulnerabilities, to construct and execute a SQL query that searches for an invoice matching the specified identifier [1]. El identificador se selecciona de una lista de todas las facturas asociadas al usuario autenticado actual.

        ...
	$id = $_POST['id'];
	$query = "SELECT * FROM invoices WHERE id = ?";
	$stmt = $mysqli->prepare($query);
	$stmt->bind_param('ss',$id);
	$stmt->execute();
        ...

El problema es que el desarrollador no ha tenido en cuenta todos los valores posibles de id. Aunque la interfaz genera una lista de identificadores de factura que pertenecen al usuario actual, un atacante puede eludir esta interfaz para solicitar cualquier factura que desee. Dado que el código de este ejemplo no comprueba si el usuario tiene permiso para acceder a la factura solicitada, se mostrará cualquier factura, incluso si no pertenece al usuario actual.

Varios marcos web modernos proporcionan mecanismos para realizar la validación de la entrada del usuario (entre ellos, Struts y Struts 2). Para resaltar los orígenes no validados de entrada, los Paquetes de reglas de codificación segura de Fortify vuelven a priorizar dinámicamente los problemas notificados por Fortify Static Code Analyzer reduciendo la probabilidad de ataques y ofreciendo argumentos para los elementos probatorios cada vez que el mecanismo de validación de la estructura está en uso. Esta característica recibe el nombre de clasificación basada en contexto. A modo de ayuda extra para el usuario de Fortify con el proceso de auditoría, Fortify Software Security Research Group facilita la plantilla de proyecto de validación de datos que agrupa los problemas en carpetas en función del mecanismo de validación aplicado al origen de la entrada.

Se producen errores de control de acceso de base de datos cuando:

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

2. Los datos se utilizan para especificar el valor de una clave principal en una consulta SQL.
Ejemplo 1: el siguiente código utiliza una instrucción parametrizada, que aplica caracteres de escape a metacaracteres e impide la inclusión de vulnerabilidades de SQL Injection, para crear y ejecutar una consulta SQL que busca una factura que coincida con el identificador especificado [1]. El identificador se selecciona de una lista de todas las facturas asociadas al usuario autenticado actual.

procedure get_item (
itm_cv IN OUT ItmCurTyp,
id in varchar2)
is
open itm_cv for ' SELECT * FROM items WHERE ' ||
'invoiceID = :invid' ||
     	using id;
end get_item;

El problema es que el desarrollador no ha tenido en cuenta todos los valores posibles de id. Aunque la interfaz genera una lista de identificadores de factura que pertenecen al usuario actual, un atacante puede eludir esta interfaz para solicitar cualquier factura que desee. Dado que el código de este ejemplo no comprueba si el usuario tiene permiso para acceder a la factura solicitada, se mostrará cualquier factura, incluso si no pertenece al usuario actual.

Se producen errores de control de acceso de base de datos cuando:

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


2. Los datos se utilizan para especificar el valor de una clave principal en una consulta SQL.
Ejemplo 1: el siguiente código utiliza una instrucción parametrizada, que aplica caracteres de escape a metacaracteres e impide la inclusión de vulnerabilidades de SQL Injection, para crear y ejecutar una consulta SQL que busca una factura que coincida con el identificador especificado [1]. El identificador se selecciona de una lista de todas las facturas asociadas al usuario autenticado actual.

...
id = request.POST['id']
c = db.cursor()
stmt = c.execute("SELECT * FROM invoices WHERE id = %s", (id,))
...

El problema es que el desarrollador no ha tenido en cuenta todos los valores posibles de id. Aunque la interfaz genera una lista de identificadores de factura que pertenecen al usuario actual, un atacante puede eludir esta interfaz para solicitar cualquier factura que desee. Dado que el código de este ejemplo no comprueba si el usuario tiene permiso para acceder a la factura solicitada, se mostrará cualquier factura, incluso si no pertenece al usuario actual.

Se producen errores de control de acceso de base de datos cuando:

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


2. Los datos se utilizan para especificar el valor de una clave principal en una consulta SQL.
Ejemplo 1: el siguiente código utiliza una instrucción parametrizada, que aplica caracteres de escape a metacaracteres e impide la inclusión de vulnerabilidades de SQL Injection, para crear y ejecutar una consulta SQL que busca una factura que coincida con el identificador especificado [1]. El identificador se selecciona de una lista de todas las facturas asociadas al usuario autenticado actual.

...
id = req['invoiceID'].respond_to(:to_int)
query = "SELECT * FROM invoices WHERE id=?"
stmt = conn.prepare(query)
stmt.execute(id)
...

El problema es que el desarrollador no ha tenido en cuenta todos los valores posibles de id. Aunque la interfaz genera una lista de identificadores de factura que pertenecen al usuario actual, un atacante puede eludir esta interfaz para solicitar cualquier factura que desee. Dado que el código de este ejemplo no comprueba si el usuario tiene permiso para acceder a la factura solicitada, se mostrará cualquier factura, incluso si no pertenece al usuario actual.

Se producen errores de control de acceso de base de datos cuando:

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


2.Los datos se utilizan para especificar el valor de una clave principal en una consulta SQL.
Ejemplo 1: el siguiente código utiliza una instrucción parametrizada, que aplica caracteres de escape a metacaracteres e impide la inclusión de vulnerabilidades de SQL Injection para crear y ejecutar una consulta SQL que busca una factura que coincida con el identificador especificado. El identificador se selecciona de una lista de todas las facturas asociadas al usuario autenticado actual.

...
let fetchRequest = NSFetchRequest()
let entity = NSEntityDescription.entityForName("Invoices", inManagedObjectContext: managedContext)
fetchRequest.entity = entity
let pred : NSPredicate = NSPredicate(format:"(id = %@)", invoiceId.text)
fetchRequest.setPredicate = pred
do {
    let results = try managedContext.executeFetchRequest(fetchRequest)
    let result : NSManagedObject = results.first!
    invoiceReferenceNumber.text = result.valueForKey("invRefNum")
    orderNumber.text = result.valueForKey("orderNumber")
    status.text = "\(results.count) records found"
} catch let error as NSError {
    print("Error \(error)")
}
...

El problema es que el desarrollador no ha tenido en cuenta todos los valores posibles de id. Aunque la interfaz genera una lista de identificadores de factura que pertenecen al usuario actual, un atacante puede eludir esta interfaz para solicitar cualquier factura que desee. Dado que el código de este ejemplo no comprueba si el usuario tiene permiso para acceder a la factura solicitada, se mostrará cualquier factura, incluso si no pertenece al usuario actual.

Se producen errores de control de acceso de base de datos cuando:

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


2. Los datos se utilizan para especificar el valor de una clave principal en una consulta SQL.
Ejemplo 1: el siguiente código utiliza una instrucción parametrizada, que aplica caracteres de escape a metacaracteres e impide la inclusión de vulnerabilidades de SQL Injection, para crear y ejecutar una consulta SQL que busca una factura que coincida con el identificador especificado [1]. El identificador se selecciona de una lista de todas las facturas asociadas al usuario autenticado actual.

	...
	id = Request.Form("invoiceID")
	strSQL = "SELECT * FROM invoices WHERE id = ?"
	objADOCommand.CommandText = strSQL
	objADOCommand.CommandType = adCmdText
	set objADOParameter = objADOCommand.CreateParameter("id" , adString, adParamInput, 0, 0)
	objADOCommand.Parameters("id") = id
	...

El problema es que el desarrollador no ha tenido en cuenta todos los valores posibles de id. Aunque la interfaz genera una lista de identificadores de factura que pertenecen al usuario actual, un atacante puede eludir esta interfaz para solicitar cualquier factura que desee. Dado que el código de este ejemplo no comprueba si el usuario tiene permiso para acceder a la factura solicitada, se mostrará cualquier factura, incluso si no pertenece al usuario actual.

Las vulnerabilidades de inyección de comandos se presentan de dos formas:

- Un usuario malintencionado puede cambiar el comando que el programa ejecuta: el usuario malintencionado controla explícitamente cuál es el comando.

- Un usuario malintencionado puede cambiar el entorno en el que se ejecuta el comando: implícitamente, el usuario malintencionado controla el significado del comando.

En este caso, nos preocupa principalmente el primer escenario, la posibilidad de que un usuario malintencionado pueda controlar el comando que se ejecuta. Las vulnerabilidades Command Injection de este tipo se producen cuando:

1. Los datos entran en la aplicación desde una fuente no confiable.

2. Los datos se utilizan como una cadena o como parte de esta representando un comando que la aplicación ejecuta.

3. Al ejecutar el comando, la aplicación proporciona al usuario malintencionado un privilegio o la capacidad que el usuario malintencionado no tendría de otro modo.

Ejemplo 1: El siguiente código de una utilidad del sistema utiliza la clave del registro APPHOME para determinar el directorio en el que está instalado y, a continuación, ejecuta una secuencia de comandos de inicialización basada en una ruta de acceso relativa desde el directorio especificado.

...
CALL FUNCTION 'REGISTRY_GET'
  EXPORTING
     KEY   = 'APPHOME'
  IMPORTING
     VALUE = home.

CONCATENATE home INITCMD INTO cmd.
CALL 'SYSTEM' ID 'COMMAND' FIELD cmd ID 'TAB' FIELD TABL[].
...

En el código del Example 1 se permite a un usuario malintencionado ejecutar comandos arbitrarios con el privilegio elevado de la aplicación mediante la modificación de la entrada del registro APPHOME para que apunte a otra ruta de acceso que contiene una versión malintencionada de INITCMD. Dado que el programa no valida el valor leído desde el registro, si un usuario malintencionado puede controlar el valor de la clave del registro APPHOME, podrá engañar a la aplicación para que ejecute código malintencionado y tome el control del sistema.

Ejemplo 2: El siguiente código proviene de una aplicación web administrativa diseñada para permitir a los usuarios iniciar una copia de seguridad de una base de datos de Oracle mediante un contenedor de archivos por lotes en torno a la utilidad rman y después ejecutar una secuencia de comandos cleanup.bat para eliminar algunos archivos temporales. La secuencia de comandos rmanDB.bat acepta un único parámetro de línea de comandos que especifica el tipo de copia de seguridad que realizar. Dado que se restringe el acceso a la base de datos, la aplicación ejecuta la copia de seguridad como un usuario con privilegios.

...
btype = request->get_form_field( 'backuptype' )
CONCATENATE `/K 'c:\\util\\rmanDB.bat ` btype `&&c:\\util\\cleanup.bat'` INTO cmd.

CALL FUNCTION 'SXPG_COMMAND_EXECUTE_LONG'
  EXPORTING
    commandname                   = cmd_exe
    long_params                   = cmd_string
  EXCEPTIONS
    no_permission                 = 1
    command_not_found             = 2
    parameters_too_long           = 3
    security_risk                 = 4
    OTHERS                        = 5.
...

El problema aquí es que el programa no realiza ninguna validación de la lectura del parámetro backuptype por parte del usuario. El módulo de función SXPG_COMMAND_EXECUTE_LONG no suele ejecutar varios comandos, pero en este caso el programa ejecuta primero el shell cmd.exe para ejecutar varios comandos con una única llamada a CALL 'SYSTEM'. Una vez que se invoca el comando de shell, permitirá que se ejecuten varios comandos separados por dos signos de Y comercial. Si un usuario malintencionado pasa una cadena del tipo "&& del c:\\dbms\\*.*", la aplicación ejecutará este comando junto con los demás comandos especificados por el programa. Debido a la naturaleza de la aplicación, se ejecuta con los privilegios necesarios para interactuar con la base de datos, lo que significa que cualquier comando que el usuario malintencionado inserte, se ejecutará también con estos privilegios.

Ejemplo 3: El siguiente código procede de una aplicación web que proporciona una interfaz a través de la cual los usuarios pueden actualizar su contraseña en el sistema. Parte del proceso de actualización de contraseñas en ciertos entornos de red consiste en ejecutar un comando make en el directorio /var/yp.

...
MOVE 'make' to cmd.
CALL 'SYSTEM' ID 'COMMAND' FIELD cmd ID 'TAB' FIELD TABL[].
...

El problema aquí es que el programa no especifica una ruta absoluta para la ejecución y no puede limpiar su entorno antes de ejecutar la llamada aCALL 'SYSTEM'. Si un usuario malintencionado puede modificar la variable $PATH para que señale a un binario malintencionado que se denomina make y hacer que el programa pueda ejecutarse en su entorno, entonces el archivo binario malintencionado se cargará en lugar del que se pretende. Debido a la naturaleza de la aplicación, se ejecuta con los privilegios necesarios para realizar las operaciones del sistema, lo que significa que el comando make del usuario malintencionado ahora se ejecutará con estos privilegios, posiblemente proporcionando al usuario malintencionado control total sobre el sistema.

Las vulnerabilidades de inyección de comandos se presentan de dos formas:

- Un usuario malintencionado puede cambiar el comando que el programa ejecuta: el usuario malintencionado controla explícitamente cuál es el comando.

- Un usuario malintencionado puede cambiar el entorno en el que se ejecuta el comando: implícitamente, el usuario malintencionado controla el significado del comando.

En este caso, nos preocupa principalmente el primer escenario, la posibilidad de que un usuario malintencionado pueda controlar el comando que se ejecuta. Las vulnerabilidades Command Injection de este tipo se producen cuando:

1. Los datos entran en la aplicación desde una fuente no confiable.

2. Los datos se utilizan como una cadena o como parte de esta representando un comando que la aplicación ejecuta.

3. Al ejecutar el comando, la aplicación proporciona al usuario malintencionado un privilegio o la capacidad que el usuario malintencionado no tendría de otro modo.

Ejemplo 1: el siguiente código utiliza la entrada del archivo de configuración para determinar el directorio en el que está instalado y, a continuación, ejecuta una secuencia de comandos de inicialización basada en una ruta de acceso relativa desde el directorio especificado.

        ...
        var fs:FileStream = new FileStream();
        fs.open(new File(String(configStream.readObject())+".txt"), FileMode.READ);
        home = String(fs.readObject(home));
        var cmd:String = home + INITCMD;
        fscommand("exec", cmd);
        ...

El código del Example 1 permite a un usuario malintencionado ejecutar comandos arbitrarios con el privilegio elevado de la aplicación mediante la modificación del contenido del archivo de configuración configStream para que apunte a otra ruta de acceso que contiene una versión malintencionada de INITCMD. Dado que el programa no valida el valor leído desde el archivo, si un usuario malintencionado puede controlar este valor, podrá engañar a la aplicación para que ejecute código malintencionado y tomar el control del sistema.

Ejemplo 2: el siguiente código proviene de una aplicación web administrativa diseñada para permitir a los usuarios iniciar una copia de seguridad de una base de datos de Oracle mediante un contenedor de archivos por lotes en torno a la utilidad rman y, a continuación, ejecutar un script cleanup.bat para eliminar algunos archivos temporales. La secuencia de comandos rmanDB.bat acepta un único parámetro de línea de comandos que especifica el tipo de copia de seguridad que realizar. Dado que se restringe el acceso a la base de datos, la aplicación ejecuta la copia de seguridad como un usuario con privilegios.

        ...
        var params:Object = LoaderInfo(this.root.loaderInfo).parameters;
        var btype:String = String(params["backuptype"]);
        var cmd:String = "cmd.exe /K \"c:\\util\\rmanDB.bat " + btype + "&&c:\\util\\cleanup.bat\"";
        fscommand("exec", cmd);
        ...

El problema aquí es que el programa no realiza ninguna validación de la lectura del parámetro backuptype por parte del usuario. La función fscommand() no suele ejecutar varios comandos, pero en este caso el programa ejecuta primero el shell cmd.exe para ejecutar varios comandos con una única llamada a fscommnd(). Una vez que se invoca el comando de shell, permitirá que se ejecuten varios comandos separados por dos signos de Y comercial. Si un usuario malintencionado pasa una cadena del tipo "&& del c:\\dbms\\*.*", la aplicación ejecutará este comando junto con los demás comandos especificados por el programa. Debido a la naturaleza de la aplicación, se ejecuta con los privilegios necesarios para interactuar con la base de datos, lo que significa que cualquier comando que el usuario malintencionado inserte, se ejecutará también con estos privilegios.

Ejemplo 3: El siguiente código procede de una aplicación web que proporciona una interfaz a través de la cual los usuarios pueden actualizar su contraseña en el sistema. Parte del proceso de actualización de contraseñas en ciertos entornos de red consiste en ejecutar un comando make en el directorio /var/yp.

        ...
        fscommand("exec", "make");
        ...

El problema aquí es que el programa no especifica una ruta absoluta para la ejecución y no puede limpiar su entorno antes de ejecutar la llamada afscommand(). Si un usuario malintencionado puede modificar la variable $PATH para que señale a un binario malintencionado que se denomina make y hacer que el programa pueda ejecutarse en su entorno, entonces el archivo binario malintencionado se cargará en lugar del que se pretende. Debido a la naturaleza de la aplicación, se ejecuta con los privilegios necesarios para realizar las operaciones del sistema, lo que significa que el comando make del usuario malintencionado ahora se ejecutará con estos privilegios, posiblemente proporcionando al usuario malintencionado control total sobre el sistema.

Las vulnerabilidades de inyección de comandos se presentan de dos formas:

- Un usuario malintencionado puede cambiar el comando que el programa ejecuta: el usuario malintencionado controla explícitamente cuál es el comando.

- Un usuario malintencionado puede cambiar el entorno en el que se ejecuta el comando: implícitamente, el usuario malintencionado controla el significado del comando.

En este caso, nos preocupa principalmente el primer escenario, la posibilidad de que un usuario malintencionado pueda controlar el comando que se ejecuta. Las vulnerabilidades Command Injection de este tipo se producen cuando:

1. Los datos entran en la aplicación desde una fuente no confiable.

2. Los datos se utilizan como una cadena o como parte de esta representando un comando que la aplicación ejecuta.

3. Al ejecutar el comando, la aplicación proporciona al usuario malintencionado un privilegio o la capacidad que el usuario malintencionado no tendría de otro modo.

Ejemplo 1: el siguiente código de una utilidad del sistema usa la propiedad del sistema APPHOME para determinar el directorio de instalación y, a continuación, ejecuta un script de inicialización en función de una ruta relativa desde el directorio especificado.

...
string val = Environment.GetEnvironmentVariable("APPHOME");
string cmd = val + INITCMD;
ProcessStartInfo startInfo = new ProcessStartInfo(cmd);
Process.Start(startInfo);
...

En el código del Example 1 se permite a un usuario malintencionado ejecutar comandos arbitrarios con el privilegio elevado de la aplicación mediante la modificación de la propiedad del sistema APPHOME para que apunte a otra ruta de acceso que contiene una versión malintencionada de INITCMD. Como el programa no valida el valor leído desde el entorno, si el usuario malintencionado puede controlar el valor de la propiedad del sistema APPHOME, puede engañar a la aplicación para que ejecute código malintencionado y asuma el control del sistema.

Ejemplo 2: el siguiente código proviene de una aplicación web administrativa diseñada para permitir a los usuarios iniciar una copia de seguridad de una base de datos de Oracle mediante un contenedor de archivos por lotes en torno a la utilidad rman y, a continuación, ejecutar un script cleanup.bat para eliminar algunos archivos temporales. La secuencia de comandos rmanDB.bat acepta un único parámetro de línea de comandos que especifica el tipo de copia de seguridad que realizar. Dado que se restringe el acceso a la base de datos, la aplicación ejecuta la copia de seguridad como un usuario con privilegios.

...
string btype = BackupTypeField.Text;
string cmd = "cmd.exe /K \"c:\\util\\rmanDB.bat"
              + btype + "&&c:\\util\\cleanup.bat\""));
Process.Start(cmd);
...

El problema aquí es que el programa no realiza ninguna validación en BackupTypeField. La función Process.Start() no suele ejecutar varios comandos, pero en este caso el programa ejecuta primero el shell cmd.exe para ejecutar varios comandos con una única llamada a Process.Start(). Una vez que se invoca el comando de shell, permitirá que se ejecuten varios comandos separados por dos signos de Y comercial. Si un usuario malintencionado pasa una cadena del tipo "&& del c:\\dbms\\*.*", la aplicación ejecutará este comando junto con los demás comandos especificados por el programa. Debido a la naturaleza de la aplicación, se ejecuta con los privilegios necesarios para interactuar con la base de datos, lo que significa que cualquier comando que el usuario malintencionado inserte, se ejecutará también con estos privilegios.

Ejemplo 3: el siguiente código es de una aplicación web que concede a los usuarios acceso a una interfaz a través de la cual se puede actualizar la contraseña en el sistema. Parte del proceso de actualización de contraseñas en este entorno de red consiste en ejecutar el comando update.exe de la siguiente forma:

...
Process.Start("update.exe");
...

El problema aquí es que el programa no especifica una ruta absoluta y no puede limpiar su entorno antes de ejecutar la llamada a Process.start(). Si un usuario malintencionado puede modificar la variable $PATH para que señale a un binario malintencionado que se denomina update.exe y hacer que el programa pueda ejecutarse en su entorno, entonces el archivo binario malintencionado se cargará en lugar del que se pretende. Debido a la naturaleza de la aplicación, se ejecuta con los privilegios necesarios para realizar las operaciones del sistema, lo que significa que el comando update.exe del usuario malintencionado ahora se ejecutará con estos privilegios, posiblemente proporcionando al usuario malintencionado control total sobre el sistema.

Las vulnerabilidades de inyección de comandos se presentan de dos formas:

- Un usuario malintencionado puede cambiar el comando que el programa ejecuta: el usuario malintencionado controla explícitamente cuál es el comando.

- Un usuario malintencionado puede cambiar el entorno en el que se ejecuta el comando: implícitamente, el usuario malintencionado controla el significado del comando.

En ese caso, nuestra principal inquietud es el primer escenario, en el que un usuario malintencionado controla de forma explícita el comando que se ejecuta. Las vulnerabilidades Command Injection de este tipo se producen cuando:

1. Los datos entran en la aplicación desde una fuente no confiable.


2. Los datos forman parte de una cadena que la aplicación ejecuta como comando.


3. Al ejecutar el comando, la aplicación proporciona al usuario malintencionado un privilegio o la capacidad que el usuario malintencionado no tendría de otro modo.

Ejemplo 1: en el siguiente programa de ejemplo se acepta un nombre de archivo como argumento de línea de comandos y se muestra el contenido del archivo al usuario. El programa se instala en setuid root porque está diseñado como herramienta de aprendizaje para permitir a los administradores del sistema en formación inspeccionar los archivos del sistema con privilegios sin concederles la capacidad de modificarlos o dañar el sistema.

int main(char* argc, char** argv) {
	char cmd[CMD_MAX] = "/usr/bin/cat ";
	strcat(cmd, argv[1]);
	system(cmd);
}

Como el programa se ejecuta con privilegios root, la llamada a system() también se ejecuta con privilegios root. Si un usuario especifica un nombre de archivo estándar, la llamada presenta el funcionamiento previsto. Sin embargo, si un atacante transfiere una cadena con el formato ";rm -rf /", la llamada a system() no se ejecuta cat debido a la falta de argumentos y, a continuación, pasa a eliminar de forma recursiva el contenido de la partición raíz.

Ejemplo 2: el siguiente código de un programa con privilegios utiliza la variable de entorno $APPHOME para determinar el directorio de instalación de la aplicación y, a continuación, ejecuta una secuencia de comandos de inicialización en ese directorio.

	...
	char* home=getenv("APPHOME");
	char* cmd=(char*)malloc(strlen(home)+strlen(INITCMD));
	if (cmd) {
		strcpy(cmd,home);
		strcat(cmd,INITCMD);
		execl(cmd, NULL);
	}
	...

Al igual que en el Example 1, el código de este ejemplo permite a un usuario malintencionado ejecutar comandos arbitrarios con el privilegio elevado de la aplicación. En este ejemplo, el atacante puede modificar la variable de entorno $APPHOME para especificar una ruta diferente que contenga una versión malintencionada de INITCMD. Como el programa no valida el valor leído del entorno, al controlar este, el atacante puede engañar a la aplicación para que ejecute código malicioso.

El usuario malintencionado utiliza la variable de entorno para controlar el comando al que llama el programa, por lo que el efecto del entorno es explícito en este ejemplo. Ahora nos centraremos en lo que puede ocurrir cuando el atacante puede cambiar la forma en que se interpreta el comando.

Ejemplo 3: El siguiente código procede de una utilidad CGI basada en la Web que permite a los usuarios cambiar sus contraseñas. El proceso de actualización de contraseñas bajo NIS conlleva la ejecución de make en el directorio /var/yp. Tenga en cuenta que, como el programa actualiza los registros de contraseñas, se ha instalado setuid root.

El programa llama a make de la siguiente forma:

system("cd /var/yp && make &> /dev/null");

A diferencia de los ejemplos anteriores, el comando de este ejemplo está codificado, por lo que el usuario malintencionado no puede controlar el argumento transferido a system(). Sin embargo, como el programa no especifica una ruta absoluta para make ni limpia ninguna variable de entorno antes de llamar al comando, el atacante puede modificar la variable $PATH para que señale a un archivo binario malicioso denominado make y ejecutar la secuencia de comandos de CGI desde el indicador de shell. Y, como el programa ha instalado setuid root, la versión de make del usuario malintencionado se ejecuta ahora con privilegios root.

En Windows existen riesgos adicionales.

Ejemplo 4: al invocar CreateProcess() directamente o mediante una llamada a una de las funciones de la familia _spawn(), se debe tener cuidado en el caso de que haya un espacio en un ejecutable o en una ruta.

...
LPTSTR cmdLine = _tcsdup(TEXT("C:\\Program Files\\MyApplication -L -S"));
CreateProcess(NULL, cmdLine, ...);
...

Debido a la forma en que CreateProcess() analiza los espacios, el primer ejecutable que el sistema operativo intentará ejecutar es Program.exe y no MyApplication.exe. Por lo tanto, si un atacante es capaz de instalar una aplicación malintencionada llamada Program.exe en el sistema, cualquier programa que de manera incorrecta llame a CreateProcess() utilizando el directorio Program Files ejecutará esta aplicación en lugar de la que pretendía ejecutar.

El entorno desempeña un papel fundamental en la ejecución de los comandos del sistema en los programas. Las funciones como system(), exec() y CreateProcess() utilizan el entorno del programa que les llama, por lo que los atacantes disponen de una oportunidad potencial de influir en el comportamiento de dichas llamadas.

Las vulnerabilidades Command Injection se presentan de dos formas:

- Un atacante puede cambiar el comando que el programa ejecuta: el atacante controla explícitamente el comando.

- Un atacante puede controlar parámetros del programa.

- Un atacante puede cambiar el entorno en el que se ejecuta el comando: el atacante controla implícitamente el significado del comando.

En este caso, nos interesa principalmente el segundo escenario, en el que un usuario malintencionado puede cambiar el significado de un comando mediante la modificación de una variable de entorno o la inserción de un ejecutable malintencionado en la parte inicial de la ruta de búsqueda. Se producen vulnerabilidades Command Injection de este tipo cuando:

1. Un atacante modifica el entorno de una aplicación.

2. La aplicación ejecuta un comando sin especificar una ruta absoluta o verificar el binario que se está ejecutando.



3. Al ejecutar el comando, la aplicación proporciona al usuario malintencionado un privilegio o la capacidad que el usuario malintencionado no tendría de otro modo.

Ejemplo 1: Este ejemplo muestra lo que puede pasar si el atacante puede modificar la manera de interpretar un comando. El código procede de una utilidad CGI basada en la Web que permite a los usuarios cambiar sus contraseñas. El proceso de actualización de contraseñas bajo NIS conlleva la ejecución de make en el directorio /var/yp. Tenga en cuenta que, como el programa actualiza los registros de contraseñas, se ha instalado setuid root.

El programa invoca a make de la siguiente manera:

MOVE "cd /var/yp && make &> /dev/null" to command-line
CALL "CBL_EXEC_RUN_UNIT" USING command-line
                               length of command-line
                               run-unit-id
                               stack-size
                               flags

El comando en este ejemplo está codificado de forma rígida, por lo que un atacante no puede controlar el argumento transferido a CBL_EXEC_RUN_UNIT. Sin embargo, dado que el programa no especifica una ruta absoluta para make y no limpia sus variables de entorno antes de invocar el comando, el atacante puede modificar su variable de $PATH para que se dirija a un binario malintencionado denominado make y ejecutar el script CGI desde una indicación del comando de shell. Además, puesto que en el programa se ha instalado setuid root, la versión del atacante de make funciona con privilegios de root.

Ejemplo 2: El siguiente código usa una variable de entorno para determinar el directorio temporal que contiene el archivo que se va a imprimir con el comando pdfprint.

DISPLAY "TEMP" UPON ENVIRONMENT-NAME
ACCEPT ws-temp-dir FROM ENVIRONMENT-VARIABLE
STRING "pdfprint " DELIMITED SIZE
             ws-temp-dir DELIMITED SPACE
             "/" DELIMITED SIZE
             ws-pdf-filename DELIMITED SPACE
             x"00" DELIMITED SIZE
             INTO cmd-buffer
CALL "SYSTEM" USING cmd-buffer

Al igual que en el ejemplo anterior, el comando está codificado de forma rígida. Sin embargo, dado que el programa no especifica una ruta absoluta para pdfprint, el atacante puede modificar su variable de $PATH para que se dirija a un binario malintencionado. Además, aunque las frases DELIMITED SPACE evitan los espacios incrustados en ws-temp-dir y ws-pdf-filename, podrían existir metacaracteres del comando de shell (como &&) incrustados en cualquiera de ellos.

Las vulnerabilidades de inyección de comandos se presentan de dos formas:

- Un usuario malintencionado puede cambiar el comando que el programa ejecuta: el usuario malintencionado controla explícitamente cuál es el comando.

- Un usuario malintencionado puede cambiar el entorno en el que se ejecuta el comando: implícitamente, el usuario malintencionado controla el significado del comando.

En este caso, nos preocupa principalmente el primer escenario, la posibilidad de que un usuario malintencionado pueda controlar el comando que se ejecuta. Las vulnerabilidades Command Injection de este tipo se producen cuando:

1. Los datos entran en la aplicación desde una fuente no confiable.

2. Los datos se utilizan como una cadena o como parte de esta representando un comando que la aplicación ejecuta.

3. Al ejecutar el comando, la aplicación proporciona al usuario malintencionado un privilegio o la capacidad que el usuario malintencionado no tendría de otro modo.

Ejemplo 1: el siguiente código permite a un usuario malintencionado especificar comandos arbitrarios mediante el parámetro de solicitud cmd.

    ...
<cfset var="#url.cmd#">
<cfexecute name = "C:\windows\System32\cmd.exe"
    arguments = "/c #var#"
    timeout = "1"
    variable="mycmd">
</cfexecute>
    ...

Las vulnerabilidades Command Injection se presentan de dos formas:

- Un atacante puede cambiar el comando que el programa ejecuta: el atacante controla explícitamente qué comando es.

- Un atacante puede cambiar el entorno en el que se ejecuta el comando: el atacante controla implícitamente el significado del comando.

En este caso, nos preocupa principalmente el primer escenario, la posibilidad de que un atacante pueda controlar el comando que se ejecuta. Se producen vulnerabilidades Command Injection de este tipo cuando:

1. Los datos entran en la aplicación desde una fuente no confiable.

2. Los datos se utilizan como una cadena, o como parte de ella, que representa un comando que la aplicación ejecuta.

3. Al ejecutar el comando, la aplicación proporciona al usuario malintencionado un privilegio o la capacidad que el usuario malintencionado no tendría de otro modo.

Ejemplo 1: El siguiente código de una utilidad del sistema usa la propiedad del sistema APPHOME para determinar el directorio en el que está instalado y luego ejecuta un guion de inicialización basado en una ruta relativa del directorio especificado.

	...
	final cmd = String.fromEnvironment('APPHOME');
    await Process.run(cmd);
	...

En el código del Example 1 se permite a un usuario malintencionado ejecutar comandos arbitrarios con el privilegio elevado de la aplicación mediante la modificación de la propiedad del sistema APPHOME para que apunte a otra ruta de acceso que contiene una versión malintencionada de INITCMD. Como el programa no valida el valor leído desde el entorno, si el usuario malintencionado puede controlar el valor de la propiedad del sistema APPHOME, puede engañar a la aplicación para que ejecute código malintencionado y asuma el control del sistema.

Las vulnerabilidades Command Injection se presentan de dos formas:

- Un atacante puede cambiar el comando que el programa ejecuta: el atacante controla explícitamente el comando.

- Un atacante puede cambiar el entorno en el que se ejecuta el comando: el atacante controla implícitamente el significado del comando.

En este caso, nos preocupa principalmente el primer escenario, la posibilidad de que un atacante pueda controlar el comando que se ejecuta. Se producen vulnerabilidades Command Injection de este tipo cuando:

1. Los datos entran en la aplicación desde una fuente no confiable.


2. Los datos se utilizan como una cadena, o como parte de ella, que representa un comando que ejecuta la aplicación.

3. Al ejecutar el comando, la aplicación proporciona al usuario malintencionado un privilegio o la capacidad que el usuario malintencionado no tendría de otro modo.

Ejemplo: El siguiente código utiliza un comando controlado por el usuario.

  cmdName := request.FormValue("Command")
  c := exec.Command(cmdName)
  c.Run()

Las vulnerabilidades de inyección de comandos se presentan de dos formas:

- Un usuario malintencionado puede cambiar el comando que el programa ejecuta: el usuario malintencionado controla explícitamente cuál es el comando.

- Un usuario malintencionado puede cambiar el entorno en el que se ejecuta el comando: implícitamente, el usuario malintencionado controla el significado del comando.

En este caso, nos preocupa principalmente el primer escenario, la posibilidad de que un usuario malintencionado pueda controlar el comando que se ejecuta. Las vulnerabilidades Command Injection de este tipo se producen cuando:

1. Los datos entran en la aplicación desde una fuente no confiable.

2. Los datos se utilizan como una cadena o como parte de esta representando un comando que la aplicación ejecuta.

3. Al ejecutar el comando, la aplicación proporciona al usuario malintencionado un privilegio o la capacidad que el usuario malintencionado no tendría de otro modo.

Ejemplo 1: el siguiente código de una utilidad del sistema usa la propiedad del sistema APPHOME para determinar el directorio de instalación y, a continuación, ejecuta una secuencia de comandos de inicialización en función de una ruta relativa desde el directorio especificado.

	...
	String home = System.getProperty("APPHOME");
	String cmd = home + INITCMD;
	java.lang.Runtime.getRuntime().exec(cmd);
	...

En el código del Example 1 se permite a un usuario malintencionado ejecutar comandos arbitrarios con el privilegio elevado de la aplicación mediante la modificación de la propiedad del sistema APPHOME para que apunte a otra ruta de acceso que contiene una versión malintencionada de INITCMD. Como el programa no valida el valor leído desde el entorno, si el usuario malintencionado puede controlar el valor de la propiedad del sistema APPHOME, puede engañar a la aplicación para que ejecute código malintencionado y asuma el control del sistema.

Ejemplo 2: el siguiente código proviene de una aplicación web administrativa diseñada para permitir a los usuarios iniciar una copia de seguridad de una base de datos de Oracle mediante un contenedor de archivos por lotes en torno a la utilidad rman y, a continuación, ejecutar un script cleanup.bat para eliminar algunos archivos temporales. La secuencia de comandos rmanDB.bat acepta un único parámetro de línea de comandos que especifica el tipo de copia de seguridad que realizar. Dado que se restringe el acceso a la base de datos, la aplicación ejecuta la copia de seguridad como un usuario con privilegios.

...
String btype = request.getParameter("backuptype");
String cmd = new String("cmd.exe /K
\"c:\\util\\rmanDB.bat "+btype+"&&c:\\util\\cleanup.bat\"")
System.Runtime.getRuntime().exec(cmd);
...

El problema aquí es que el programa no realiza ninguna validación de la lectura del parámetro backuptype por parte del usuario. La función Runtime.exec() no suele ejecutar varios comandos, pero en este caso el programa ejecuta primero el shell cmd.exe para ejecutar varios comandos con una única llamada a Runtime.exec(). Una vez que se invoca el comando de shell, permitirá que se ejecuten varios comandos separados por dos signos de Y comercial. Si un usuario malintencionado pasa una cadena del tipo "&& del c:\\dbms\\*.*", la aplicación ejecutará este comando junto con los demás comandos especificados por el programa. Debido a la naturaleza de la aplicación, se ejecuta con los privilegios necesarios para interactuar con la base de datos, lo que significa que cualquier comando que el usuario malintencionado inserte, se ejecutará también con estos privilegios.

Ejemplo 3: El siguiente código procede de una aplicación web que proporciona una interfaz a través de la cual los usuarios pueden actualizar su contraseña en el sistema. Parte del proceso de actualización de contraseñas en ciertos entornos de red consiste en ejecutar un comando make en el directorio /var/yp.

...
System.Runtime.getRuntime().exec("make");
...

El problema aquí es que el programa no especifica una ruta absoluta para la ejecución y no puede limpiar su entorno antes de ejecutar la llamada aRuntime.exec(). Si un usuario malintencionado puede modificar la variable $PATH para que señale a un binario malintencionado que se denomina make y hacer que el programa pueda ejecutarse en su entorno, entonces el archivo binario malintencionado se cargará en lugar del que se pretende. Debido a la naturaleza de la aplicación, se ejecuta con los privilegios necesarios para realizar las operaciones del sistema, lo que significa que el comando make del usuario malintencionado ahora se ejecutará con estos privilegios, posiblemente proporcionando al usuario malintencionado control total sobre el sistema.

Algunos piensan que en el mundo de las plataformas móviles, las vulnerabilidades clásicas como la inyección de comandos no tienen ningún sentido: ¿por qué se atacaría a sí mismo un usuario? Sin embargo, tenga en cuenta que la esencia de las plataformas móviles consiste en aplicaciones que se descargan desde varias fuentes y se ejecutan junto con otras en el mismo dispositivo. La probabilidad de ejecutar un malware junto a una aplicación de banca es bastante alta, de modo que se necesita expandir la superficie expuesta a ataques de las aplicaciones móviles para que incluyan las comunicaciones entre procesos.

Ejemplo 4: El siguiente código lee comandos que se van a ejecutar desde una finalidad de Android.

...
        String[] cmds = this.getIntent().getStringArrayExtra("commands");
	Process p = Runtime.getRuntime().exec("su");
        DataOutputStream os = new DataOutputStream(p.getOutputStream());
        for (String cmd : cmds) {
        	os.writeBytes(cmd+"\n");
        }
        os.writeBytes("exit\n");
        os.flush();
...

En un dispositivo con acceso Root, una aplicación malintencionada puede forzar a una aplicación víctima para que ejecute comandos arbitrarios con privilegios de superusuario.

Las vulnerabilidades de inyección de comandos se presentan de dos formas:

- Un usuario malintencionado puede cambiar el comando que el programa ejecuta: el usuario malintencionado controla explícitamente cuál es el comando.

- Un usuario malintencionado puede cambiar el entorno en el que se ejecuta el comando: implícitamente, el usuario malintencionado controla el significado del comando.

En este caso, nos preocupa principalmente el primer escenario, la posibilidad de que un usuario malintencionado pueda controlar el comando que se ejecuta. Las vulnerabilidades Command Injection de este tipo se producen cuando:

1. Los datos entran en la aplicación desde una fuente no confiable.


2. Los datos se utilizan como una cadena o como parte de esta representando un comando que la aplicación ejecuta.

3. Al ejecutar el comando, la aplicación proporciona al usuario malintencionado un privilegio o la capacidad que el usuario malintencionado no tendría de otro modo.

Ejemplo 1: el siguiente código de una utilidad del sistema usa la variable de entorno APPHOME para determinar el directorio de instalación y, a continuación, ejecuta un script de inicialización en función de una ruta relativa desde el directorio especificado.

var cp = require('child_process');
  ...
  var home = process.env('APPHOME');
  var cmd = home + INITCMD;
  child = cp.exec(cmd, function(error, stdout, stderr){
    ...
  });
  ...

En el código del Example 1 se permite a un usuario malintencionado ejecutar comandos arbitrarios con el privilegio elevado de la aplicación mediante la modificación de la propiedad del sistema APPHOME para que apunte a otra ruta de acceso que contiene una versión malintencionada de INITCMD. Como el programa no valida el valor leído desde el entorno, si el usuario malintencionado puede controlar el valor de la propiedad del sistema APPHOME, puede engañar a la aplicación para que ejecute código malintencionado y asuma el control del sistema.

Ejemplo 2: el siguiente código proviene de una aplicación web administrativa diseñada para permitir a los usuarios iniciar una copia de seguridad de una base de datos de Oracle mediante un contenedor de archivos por lotes en torno a la utilidad rman. La secuencia de comandos rmanDB.bat acepta un único parámetro de línea de comandos que especifica el tipo de copia de seguridad que realizar. Dado que se restringe el acceso a la base de datos, la aplicación ejecuta la copia de seguridad como un usuario con privilegios.

var cp = require('child_process');
var http = require('http');
var url = require('url');

function listener(request, response){
  var btype = url.parse(request.url, true)['query']['backuptype'];
  if (btype !== undefined){
    cmd = "c:\\util\\rmanDB.bat" + btype;
    cp.exec(cmd, function(error, stdout, stderr){
      ...
    });
  }
  ...
}
...
http.createServer(listener).listen(8080);

El problema de esto es que el programa no realiza ninguna validación de la lectura del parámetro backuptype por parte del usuario aparte de verificar su existencia. Una vez que se invoca el shell, puede permitir la ejecución de varios comandos y, debido a la naturaleza de la aplicación, se ejecutará con los privilegios necesarios para interactuar con la base de datos, lo que significa que cualquier comando que el atacante introduzca se ejecutará también con estos privilegios.

Ejemplo 3: El siguiente código procede de una aplicación web que proporciona una interfaz a través de la cual los usuarios pueden actualizar su contraseña en el sistema. Parte del proceso de actualización de contraseñas en ciertos entornos de red consiste en ejecutar un comando make en el directorio /var/yp.

...
require('child_process').exec("make", function(error, stdout, stderr){
  ...
});
...

El problema aquí es que el programa no especifica una ruta de acceso absoluta para make y no puede limpiar su entorno antes de ejecutar la llamada a child_process.exec(). Si un usuario malintencionado puede modificar la variable $PATH para que señale a un binario malintencionado que se denomina make y hacer que el programa pueda ejecutarse en su entorno, entonces el archivo binario malintencionado se cargará en lugar del que se pretende. Debido a la naturaleza de la aplicación, se ejecuta con los privilegios necesarios para realizar las operaciones del sistema, lo que significa que el comando make del usuario malintencionado ahora se ejecutará con estos privilegios, posiblemente proporcionando al usuario malintencionado control total sobre el sistema.

Las vulnerabilidades de inyección de comandos se presentan de dos formas:

- Un usuario malintencionado puede cambiar el comando que el programa ejecuta: el usuario malintencionado controla explícitamente cuál es el comando.

- Un usuario malintencionado puede cambiar el entorno en el que se ejecuta el comando: implícitamente, el usuario malintencionado controla el significado del comando.

En este caso, nos preocupa principalmente el primer escenario, la posibilidad de que un usuario malintencionado pueda controlar el comando que se ejecuta. Las vulnerabilidades Command Injection de este tipo se producen cuando:

1. Los datos entran en la aplicación desde una fuente no confiable.

2. Los datos se utilizan como una cadena o como parte de esta representando un comando que la aplicación ejecuta.

3. Al ejecutar el comando, la aplicación proporciona al usuario malintencionado un privilegio o la capacidad que el usuario malintencionado no tendría de otro modo.

Ejemplo 1: el siguiente código de una utilidad del sistema usa la propiedad del sistema APPHOME para determinar el directorio de instalación y, a continuación, ejecuta una secuencia de comandos de inicialización en función de una ruta relativa desde el directorio especificado.

	...
	$home = $_ENV['APPHOME'];
	$cmd = $home . $INITCMD;
	system(cmd);
	...

En el código del Example 1 se permite a un usuario malintencionado ejecutar comandos arbitrarios con el privilegio elevado de la aplicación mediante la modificación de la propiedad del sistema APPHOME para que apunte a otra ruta de acceso que contiene una versión malintencionada de INITCMD. Como el programa no valida el valor leído desde el entorno, si el usuario malintencionado puede controlar el valor de la propiedad del sistema APPHOME, puede engañar a la aplicación para que ejecute código malintencionado y asuma el control del sistema.

Ejemplo 2: el siguiente código proviene de una aplicación web administrativa diseñada para permitir a los usuarios iniciar una copia de seguridad de una base de datos de Oracle mediante un contenedor de archivos por lotes en torno a la utilidad rman y, a continuación, ejecutar un script cleanup.bat para eliminar algunos archivos temporales. La secuencia de comandos rmanDB.bat acepta un único parámetro de línea de comandos que especifica el tipo de copia de seguridad que realizar. Dado que se restringe el acceso a la base de datos, la aplicación ejecuta la copia de seguridad como un usuario con privilegios.

...
$btype = $_GET['backuptype'];
$cmd = "cmd.exe /K \"c:\\util\\rmanDB.bat " . $btype . "&&c:\\util\\cleanup.bat\"";
system(cmd);
...

El problema aquí es que el programa no realiza ninguna validación de la lectura del parámetro backuptype por parte del usuario. La función Runtime.exec() no suele ejecutar varios comandos, pero en este caso el programa ejecuta primero el shell cmd.exe para ejecutar varios comandos con una única llamada a Runtime.exec(). Una vez que se invoca el comando de shell, permitirá que se ejecuten varios comandos separados por dos signos de Y comercial. Si un usuario malintencionado pasa una cadena del tipo "&& del c:\\dbms\\*.*", la aplicación ejecutará este comando junto con los demás comandos especificados por el programa. Debido a la naturaleza de la aplicación, se ejecuta con los privilegios necesarios para interactuar con la base de datos, lo que significa que cualquier comando que el usuario malintencionado inserte, se ejecutará también con estos privilegios.

Ejemplo 3: El siguiente código procede de una aplicación web que proporciona una interfaz a través de la cual los usuarios pueden actualizar su contraseña en el sistema. Parte del proceso de actualización de contraseñas en ciertos entornos de red consiste en ejecutar un comando make en el directorio /var/yp.

...
$result = shell_exec("make");
...

El problema aquí es que el programa no especifica una ruta absoluta para la ejecución y no puede limpiar su entorno antes de ejecutar la llamada aRuntime.exec(). Si un usuario malintencionado puede modificar la variable $PATH para que señale a un binario malintencionado que se denomina make y hacer que el programa pueda ejecutarse en su entorno, entonces el archivo binario malintencionado se cargará en lugar del que se pretende. Debido a la naturaleza de la aplicación, se ejecuta con los privilegios necesarios para realizar las operaciones del sistema, lo que significa que el comando make del usuario malintencionado ahora se ejecutará con estos privilegios, posiblemente proporcionando al usuario malintencionado control total sobre el sistema.

Las vulnerabilidades de inyección de comandos se presentan de dos formas:

- Un usuario malintencionado puede cambiar el comando que el programa ejecuta: el usuario malintencionado controla explícitamente cuál es el comando.

- Un usuario malintencionado puede cambiar el entorno en el que se ejecuta el comando: implícitamente, el usuario malintencionado controla el significado del comando.

En este caso, nos preocupa principalmente el primer escenario, la posibilidad de que un usuario malintencionado pueda controlar el comando que se ejecuta. Las vulnerabilidades Command Injection de este tipo se producen cuando:

1. Los datos entran en la aplicación desde una fuente no confiable.

2. Los datos se utilizan como una cadena o como parte de esta representando un comando que la aplicación ejecuta.

3. Al ejecutar el comando, la aplicación proporciona al usuario malintencionado un privilegio o la capacidad que el usuario malintencionado no tendría de otro modo.

Ejemplo: el siguiente código define un procedimiento almacenado T-SQL que, cuando se llama con datos que no son de confianza, ejecutará un comando de sistema controlado por un atacante.

...
CREATE PROCEDURE dbo.listFiles (@path NVARCHAR(200))
AS

DECLARE @cmd NVARCHAR(500)
SET @cmd = 'dir ' + @path

exec xp_cmdshell @cmd

GO
...

Las vulnerabilidades de inyección de comandos se presentan de dos formas:

- Un usuario malintencionado puede cambiar el comando que el programa ejecuta: el usuario malintencionado controla explícitamente cuál es el comando.

- Un usuario malintencionado puede cambiar el entorno en el que se ejecuta el comando: implícitamente, el usuario malintencionado controla el significado del comando.

En este caso, nos preocupa principalmente el primer escenario, la posibilidad de que un usuario malintencionado pueda controlar el comando que se ejecuta. Las vulnerabilidades Command Injection de este tipo se producen cuando:

1. Los datos entran en la aplicación desde una fuente no confiable.

2. Los datos se utilizan como una cadena o como parte de esta representando un comando que la aplicación ejecuta.

3. Al ejecutar el comando, la aplicación proporciona al usuario malintencionado un privilegio o la capacidad que el usuario malintencionado no tendría de otro modo.

Ejemplo 1: el siguiente código de una utilidad del sistema usa la propiedad del sistema APPHOME para determinar el directorio de instalación y, a continuación, ejecuta una secuencia de comandos de inicialización en función de una ruta relativa desde el directorio especificado.

	...
	home = os.getenv('APPHOME')
	cmd = home.join(INITCMD)
	os.system(cmd);
	...

En el código del Example 1 se permite a un usuario malintencionado ejecutar comandos arbitrarios con el privilegio elevado de la aplicación mediante la modificación de la propiedad del sistema APPHOME para que apunte a otra ruta de acceso que contiene una versión malintencionada de INITCMD. Como el programa no valida el valor leído desde el entorno, si el usuario malintencionado puede controlar el valor de la propiedad del sistema APPHOME, puede engañar a la aplicación para que ejecute código malintencionado y asuma el control del sistema.

Ejemplo 2: el siguiente código proviene de una aplicación web administrativa diseñada para permitir a los usuarios iniciar una copia de seguridad de una base de datos de Oracle mediante un contenedor de archivos por lotes en torno a la utilidad rman y, a continuación, ejecutar un script cleanup.bat para eliminar algunos archivos temporales. La secuencia de comandos rmanDB.bat acepta un único parámetro de línea de comandos que especifica el tipo de copia de seguridad que realizar. Dado que se restringe el acceso a la base de datos, la aplicación ejecuta la copia de seguridad como un usuario con privilegios.

...
	btype = req.field('backuptype')
	cmd = "cmd.exe /K \"c:\\util\\rmanDB.bat " + btype + "&&c:\\util\\cleanup.bat\""
	os.system(cmd);
...

El problema aquí es que el programa no realiza ninguna validación de la lectura del parámetro backuptype por parte del usuario. La función Runtime.exec() no suele ejecutar varios comandos, pero en este caso el programa ejecuta primero el shell cmd.exe para ejecutar varios comandos con una única llamada a Runtime.exec(). Una vez que se invoca el comando de shell, permitirá que se ejecuten varios comandos separados por dos signos de Y comercial. Si un usuario malintencionado pasa una cadena del tipo "&& del c:\\dbms\\*.*", la aplicación ejecutará este comando junto con los demás comandos especificados por el programa. Debido a la naturaleza de la aplicación, se ejecuta con los privilegios necesarios para interactuar con la base de datos, lo que significa que cualquier comando que el usuario malintencionado inserte, se ejecutará también con estos privilegios.

Ejemplo 3: El siguiente código procede de una aplicación web que proporciona una interfaz a través de la cual los usuarios pueden actualizar su contraseña en el sistema. Parte del proceso de actualización de contraseñas en ciertos entornos de red consiste en ejecutar un comando make en el directorio /var/yp.

...
result = os.system("make");
...

El problema aquí es que el programa no especifica una ruta absoluta para la ejecución y no puede limpiar su entorno antes de ejecutar la llamada aos.system(). Si un usuario malintencionado puede modificar la variable $PATH para que señale a un binario malintencionado que se denomina make y hacer que el programa pueda ejecutarse en su entorno, entonces el archivo binario malintencionado se cargará en lugar del que se pretende. Debido a la naturaleza de la aplicación, se ejecuta con los privilegios necesarios para realizar las operaciones del sistema, lo que significa que el comando make del usuario malintencionado ahora se ejecutará con estos privilegios, posiblemente proporcionando al usuario malintencionado control total sobre el sistema.

Las vulnerabilidades de inyección de comandos se presentan de dos formas:

- Un usuario malintencionado puede cambiar el comando que el programa ejecuta: el usuario malintencionado controla explícitamente cuál es el comando.

- Un usuario malintencionado puede cambiar el entorno en el que se ejecuta el comando: implícitamente, el usuario malintencionado controla el significado del comando.

En este caso, nos preocupa principalmente el primer escenario, la posibilidad de que un usuario malintencionado pueda controlar el comando que se ejecuta. Las vulnerabilidades Command Injection de este tipo se producen cuando:

1. Los datos entran en la aplicación desde una fuente no confiable.


2. Los datos se utilizan como una cadena o como parte de esta representando un comando que la aplicación ejecuta.

3. Al ejecutar el comando, la aplicación proporciona al usuario malintencionado un privilegio o la capacidad que el usuario malintencionado no tendría de otro modo.

Ejemplo 1: el siguiente código de una utilidad del sistema usa la propiedad del sistema APPHOME para determinar el directorio de instalación y, a continuación, ejecuta una secuencia de comandos de inicialización en función de una ruta relativa desde el directorio especificado.

...
home = ENV['APPHOME']
cmd = home + INITCMD
Process.spawn(cmd)
...

En el código del Example 1 se permite a un usuario malintencionado ejecutar comandos arbitrarios con el privilegio elevado de la aplicación mediante la modificación de la propiedad del sistema APPHOME para que apunte a otra ruta de acceso que contiene una versión malintencionada de INITCMD. Como el programa no valida el valor leído desde el entorno, si el usuario malintencionado puede controlar el valor de la propiedad del sistema APPHOME, puede engañar a la aplicación para que ejecute código malintencionado y asuma el control del sistema.

Ejemplo 2: El siguiente código proviene de una aplicación web administrativa diseñada para permitir a los usuarios iniciar una copia de seguridad de una base de datos de Oracle mediante un contenedor de archivos por lotes en torno a la utilidad rman y después ejecutar una secuencia de comandos cleanup.bat para eliminar algunos archivos temporales. La secuencia de comandos rmanDB.bat acepta un único parámetro de línea de comandos que especifica el tipo de copia de seguridad que realizar. Dado que se restringe el acceso a la base de datos, la aplicación ejecuta la copia de seguridad como un usuario con privilegios.

...
btype = req['backuptype']
cmd = "C:\\util\\rmanDB.bat #{btype} &&C:\\util\\cleanup.bat"
spawn(cmd)
...

El problema aquí es que el programa no realiza ninguna validación de la lectura del parámetro backuptype por parte del usuario. Una vez que se invoca el comando de shell mediante Kernel.spawn, permitirá que se ejecuten varios comandos separados por dos signos de Y comercial. Si un usuario malintencionado pasa una cadena del tipo "&& del c:\\dbms\\*.*", la aplicación ejecutará este comando junto con los demás comandos especificados por el programa. Debido a la naturaleza de la aplicación, se ejecuta con los privilegios necesarios para interactuar con la base de datos, lo que significa que cualquier comando que el usuario malintencionado inserte, se ejecutará también con estos privilegios.

Ejemplo 3: El siguiente código procede de una aplicación web que proporciona una interfaz a través de la cual los usuarios pueden actualizar su contraseña en el sistema. Parte del proceso de actualización de contraseñas en ciertos entornos de red consiste en ejecutar un comando make en el directorio /var/yp.

...
system("make")
...

El problema aquí es que el programa no especifica una ruta absoluta para la ejecución y no puede limpiar su entorno antes de ejecutar la llamada aKernel.system(). Si un usuario malintencionado puede modificar la variable $PATH para que señale a un binario malintencionado que se denomina make y hacer que el programa pueda ejecutarse en su entorno, entonces el archivo binario malintencionado se cargará en lugar del que se pretende. Debido a la naturaleza de la aplicación, se ejecuta con los privilegios necesarios para realizar las operaciones del sistema, lo que significa que el comando make del usuario malintencionado ahora se ejecutará con estos privilegios, posiblemente proporcionando al usuario malintencionado control total sobre el sistema.

Las vulnerabilidades de inyección de comandos se presentan de dos formas:

- Un usuario malintencionado puede cambiar el comando que el programa ejecuta: el usuario malintencionado controla explícitamente cuál es el comando.

- Un usuario malintencionado puede cambiar el entorno en el que se ejecuta el comando: implícitamente, el usuario malintencionado controla el significado del comando.

En este caso, nos preocupa principalmente el primer escenario, la posibilidad de que un usuario malintencionado pueda controlar el comando que se ejecuta. Las vulnerabilidades Command Injection de este tipo se producen cuando:

1. Los datos entran en la aplicación desde una fuente no confiable.

2. Los datos se utilizan como una cadena o como parte de esta representando un comando que la aplicación ejecuta.

3. Al ejecutar el comando, la aplicación proporciona al usuario malintencionado un privilegio o la capacidad que el usuario malintencionado no tendría de otro modo.

Ejemplo 1: el siguiente código de una utilidad del sistema usa la propiedad del sistema APPHOME para determinar el directorio de instalación y, a continuación, ejecuta un script de inicialización en función de una ruta relativa desde el directorio especificado.

	...
	Dim cmd
	Dim home

	home = Environ$("AppHome")
	cmd = home & initCmd
	Shell cmd, vbNormalFocus
	...

En el código del Example 1 se permite a un usuario malintencionado ejecutar comandos arbitrarios con el privilegio elevado de la aplicación mediante la modificación de la propiedad del sistema APPHOME para que apunte a otra ruta de acceso que contiene una versión malintencionada de INITCMD. Como el programa no valida el valor leído desde el entorno, si el usuario malintencionado puede controlar el valor de la propiedad del sistema APPHOME, puede engañar a la aplicación para que ejecute código malintencionado y asuma el control del sistema.

Ejemplo 2: el siguiente código proviene de una aplicación web administrativa diseñada para permitir a los usuarios iniciar una copia de seguridad de una base de datos de Oracle mediante un contenedor de archivos por lotes en torno a la utilidad rman y, a continuación, ejecutar un script cleanup.bat para eliminar algunos archivos temporales. La secuencia de comandos rmanDB.bat acepta un único parámetro de línea de comandos que especifica el tipo de copia de seguridad que realizar. Dado que se restringe el acceso a la base de datos, la aplicación ejecuta la copia de seguridad como un usuario con privilegios.

...
btype = Request.Form("backuptype")
cmd = "cmd.exe /K " & Chr(34) & "c:\util\rmanDB.bat " & btype & "&&c:\util\cleanup.bat" & Chr(34) & ";
Shell cmd, vbNormalFocus
...

El problema aquí es que el programa no realiza ninguna validación de la lectura del parámetro backuptype por parte del usuario. Una vez que se invoca el comando de shell, permitirá que se ejecuten varios comandos separados por dos signos de Y comercial. Si un usuario malintencionado pasa una cadena del tipo "&& del c:\\dbms\\*.*", la aplicación ejecutará este comando junto con los demás comandos especificados por el programa. Debido a la naturaleza de la aplicación, se ejecuta con los privilegios necesarios para interactuar con la base de datos, lo que significa que cualquier comando que el usuario malintencionado inserte, se ejecutará también con estos privilegios.

Ejemplo 3: El siguiente código procede de una aplicación web que proporciona una interfaz a través de la cual los usuarios pueden actualizar su contraseña en el sistema. Parte del proceso de actualización de contraseñas en ciertos entornos de red consiste en ejecutar un comando make en el directorio /var/yp.

...
$result = shell_exec("make");
...

El problema aquí es que el programa no especifica una ruta absoluta para la ejecución y no puede limpiar su entorno antes de ejecutar la llamada aRuntime.exec(). Si un usuario malintencionado puede modificar la variable $PATH para que señale a un binario malintencionado que se denomina make y hacer que el programa pueda ejecutarse en su entorno, entonces el archivo binario malintencionado se cargará en lugar del que se pretende. Debido a la naturaleza de la aplicación, se ejecuta con los privilegios necesarios para realizar las operaciones del sistema, lo que significa que el comando make del usuario malintencionado ahora se ejecutará con estos privilegios, posiblemente proporcionando al usuario malintencionado control total sobre el sistema.

Los exploradores web modernos admiten una marca Secure para cada cookie. Si se define una marca, el explorador solo puede enviar la cookie a través de HTTPS. Enviar cookies a través de un canal no cifrado puede exponerlas a ataques de espionaje de red. Las marcas seguras ayudan a mantener la confidencialidad del valor de una cookie. Esto es especialmente importante cuando la cookie contiene datos privados o porta un identificador de sesión.

Ejemplo 1: En el ejemplo siguiente, se ha creado una cookie sin configurar el parámetro isSecure como true.

...
Cookie cookie = new Cookie('emailCookie', emailCookie, path, maxAge, false, 'Strict');
...

Si su aplicación utiliza tanto HTTPS como HTTP, pero no define el parámetro isSecure, las cookies enviadas durante una solicitud HTTPS también se envían en las solicitudes HTTP subsiguientes. El espionaje del tráfico de red a través de conexiones inalámbricas no cifradas es una tarea fácil para los atacantes. Enviar cookies (sobre todo las que incluyen ID de sesión) a través de HTTP puede poner en peligro la aplicación.

Los exploradores web modernos admiten una marca Secure en cada cookie. Si se incluye una marca, el explorador solo puede enviar la cookie a través de HTTPS. Enviar cookies a través de un canal no cifrado puede exponerlas a ataques de reconocimiento de red, por lo que las marcas seguras ayudan a mantener la confidencialidad del valor de una cookie. Esto es especialmente importante cuando la cookie contiene datos privados o porta un identificador de sesión.

Ejemplo: en el ejemplo siguiente, se ha añadido una cookie a la respuesta sin configurar la propiedad Secure.

...
 HttpCookie cookie = new HttpCookie("emailCookie", email);
    Response.AppendCookie(cookie);
...

Si su aplicación utiliza tanto HTTPS como HTTP pero no define la marca Secure, las cookies enviadas durante una solicitud HTTPS también se enviarán en subsiguientes solicitudes HTTP. Espiar tráfico de red a través de conexiones inalámbricas no cifradas es una tarea fácil para los atacantes, por lo que enviar cookies (sobre todo con ID de sesión) a través de HTTP puede poner en peligro la aplicación.

Los exploradores web modernos admiten una marca Secure para cada cookie. Si se define una marca, el explorador solo puede enviar la cookie a través de HTTPS. Enviar cookies a través de un canal no cifrado puede exponerlas a ataques de espionaje de red, por lo que las marcas seguras ayudan a mantener la confidencialidad del valor de una cookie. Esto es especialmente importante cuando la cookie contiene datos privados o identificadores de sesión, o cuando porta un token de CSRF.
Ejemplo 1: En código siguiente agrega una cookie a la respuesta sin establecer la marca Secure.

cookie := http.Cookie{
  Name:     "emailCookie",
  Value:    email,
}
http.SetCookie(response, &cookie)
...

Si una aplicación utiliza tanto HTTPS como HTTP, pero no define la marca Secure, las cookies enviadas durante una solicitud HTTPS también se enviarán en las subsiguientes solicitudes HTTP. Los atacantes pueden secuestrar el tráfico de red no cifrado y poner en peligro la cookie, lo cual es especialmente fácil en el caso de las redes inalámbricas.

Los exploradores web modernos admiten una marca Secure para cada cookie. Si se define una marca, el explorador solo puede enviar la cookie a través de HTTPS. Enviar cookies a través de un canal no cifrado puede exponerlas a ataques de espionaje de red, por lo que las marcas seguras ayudan a mantener la confidencialidad del valor de una cookie. Esto es especialmente importante cuando la cookie contiene datos privados o porta un identificador de sesión.

Ejemplo 1: En el siguiente ejemplo, el atributo use-secure-cookie permite el envío de la cookie remember-me a través de un transporte sin cifrar.

	<http auto-config="true">
        ...
        <remember-me use-secure-cookie="false"/>
	</http>

Si su aplicación utiliza tanto HTTPS como HTTP, pero no define la marca Secure, las cookies enviadas durante una solicitud HTTPS también se enviarán en las solicitudes HTTP subsiguientes. El espionaje del tráfico de red a través de conexiones inalámbricas no cifradas es una tarea fácil para los atacantes, por lo que enviar cookies (sobre todo las que incluyen ID de sesión) a través de HTTP puede poner en peligro la aplicación.

Los exploradores web modernos admiten una marca Secure en cada cookie. Si se incluye una marca, el explorador solo puede enviar la cookie a través de HTTPS. Enviar cookies a través de un canal no cifrado puede exponerlas a ataques de reconocimiento de red, por lo que las marcas seguras ayudan a mantener la confidencialidad del valor de una cookie. Esto es especialmente importante cuando la cookie contiene datos privados o porta un identificador de sesión.
Ejemplo 1: en el ejemplo siguiente, se ha añadido una cookie a la respuesta sin configurar la propiedad Secure como true.

  res.cookie('important_cookie', info, {domain: 'secure.example.com', path: '/admin', httpOnly: true, secure: false});

Si su aplicación utiliza tanto HTTPS como HTTP pero no define la marca Secure, las cookies enviadas durante una solicitud HTTPS también se enviarán en subsiguientes solicitudes HTTP. Espiar tráfico de red a través de conexiones inalámbricas no cifradas es una tarea fácil para los atacantes, por lo que enviar cookies (sobre todo con ID de sesión) a través de HTTP puede poner en peligro la aplicación.

Los exploradores web modernos admiten una marca Secure en cada cookie. Si se incluye una marca, el explorador solo puede enviar la cookie a través de HTTPS. Enviar cookies a través de un canal no cifrado puede exponerlas a ataques de reconocimiento de red, por lo que las marcas seguras ayudan a mantener la confidencialidad del valor de una cookie. Esto es especialmente importante cuando la cookie contiene datos privados o porta un identificador de sesión.
Ejemplo 1: En el ejemplo siguiente, se ha agregado una cookie a la respuesta sin establecer la marca Secure.

  ...
  NSDictionary *cookieProperties = [NSDictionary dictionary];
  ...
  NSHTTPCookie *cookie = [NSHTTPCookie cookieWithProperties:cookieProperties];
  ...

Si su aplicación utiliza tanto HTTPS como HTTP pero no define la marca Secure, las cookies enviadas durante una solicitud HTTPS también se enviarán en subsiguientes solicitudes HTTP. Espiar tráfico de red a través de conexiones inalámbricas no cifradas es una tarea fácil para los atacantes, por lo que enviar cookies (sobre todo con ID de sesión) a través de HTTP puede poner en peligro la aplicación.

Los exploradores web modernos admiten una marca Secure en cada cookie. Si se incluye una marca, el explorador solo puede enviar la cookie a través de HTTPS. Enviar cookies a través de un canal no cifrado puede exponerlas a ataques de reconocimiento de red, por lo que las marcas seguras ayudan a mantener la confidencialidad del valor de una cookie. Esto es especialmente importante cuando la cookie contiene datos privados o porta un identificador de sesión.
Ejemplo 1: En código siguiente agrega una cookie a la respuesta sin establecer la marca Secure.

...
setcookie("emailCookie", $email, 0, "/", "www.example.com");
...

Si una aplicación utiliza tanto HTTPS como HTTP pero no define la marca Secure, las cookies enviadas durante una solicitud HTTPS también se enviarán en subsiguientes solicitudes HTTP. Los atacantes pueden poner en peligro la cookie secuestrando el tráfico de red no cifrado, lo cual es especialmente fácil en el caso de las redes inalámbricas.

Los exploradores web modernos admiten una marca Secure en cada cookie. Si se incluye una marca, el explorador solo puede enviar la cookie a través de HTTPS. Enviar cookies a través de un canal no cifrado puede exponerlas a ataques de reconocimiento de red, por lo que las marcas seguras ayudan a mantener la confidencialidad del valor de una cookie. Esto es especialmente importante cuando la cookie contiene datos privados o identificadores de sesión, o cuando porta un token de CSRF.
Ejemplo 1: En código siguiente agrega una cookie a la respuesta sin establecer la marca Secure.

from django.http.response import HttpResponse
...
def view_method(request):
  res = HttpResponse()
  res.set_cookie("emailCookie", email)
  return res
...

Si una aplicación utiliza tanto HTTPS como HTTP pero no define la marca Secure, las cookies enviadas durante una solicitud HTTPS también se enviarán en subsiguientes solicitudes HTTP. Los atacantes pueden poner en peligro la cookie secuestrando el tráfico de red no cifrado, lo cual es especialmente fácil en el caso de las redes inalámbricas.

Los exploradores web modernos admiten una marca Secure para cada cookie. Si se define una marca, el explorador solo puede enviar la cookie a través de HTTPS. Enviar cookies a través de un canal no cifrado puede exponerlas a ataques de espionaje de red, por lo que las marcas seguras ayudan a mantener la confidencialidad del valor de una cookie. Esto es especialmente importante cuando la cookie contiene datos privados o porta un identificador de sesión.
Ejemplo 1: En el ejemplo siguiente, se ha agregado una cookie a la respuesta sin establecer la marca Secure.

...
let properties = [
    NSHTTPCookieDomain: "www.example.com",
    NSHTTPCookiePath: "/service",
    NSHTTPCookieName: "foo",
    NSHTTPCookieValue: "bar"
]
let cookie : NSHTTPCookie? = NSHTTPCookie(properties:properties)
...

Si su aplicación utiliza tanto HTTPS como HTTP, pero no define la marca Secure, las cookies enviadas durante una solicitud HTTPS también se enviarán en las solicitudes HTTP subsiguientes. El espionaje del tráfico de red a través de conexiones inalámbricas no cifradas es una tarea fácil para los atacantes, por lo que enviar cookies (sobre todo las que incluyen ID de sesión) a través de HTTP puede poner en peligro la aplicación.

Todos los exploradores más comunes admiten la propiedad de cookie HttpOnly que evita que scripts del lado del cliente puedan acceder a la cookie. Los ataques de Cross-Site Scripting suelen acceder a las cookies con el fin de robar los identificadores de sesión o los tokens de autenticación. Cuando HttpOnly no está habilitado, los atacantes pueden acceder más fácilmente a las cookies del usuario.
Ejemplo 1: el siguiente código crea una cookie sin configurar la propiedad HttpOnly.

    HttpCookie cookie = new HttpCookie("emailCookie", email);
    Response.AppendCookie(cookie);

Los exploradores admiten la propiedad de cookie HttpOnly que evita que los scripts del lado del cliente accedan a la cookie. Los ataques Cross-Site Scripting suelen acceder a las cookies con el fin de robar los identificadores de sesión o los tokens de autenticación. Cuando HttpOnly no está habilitado, los usuarios malintencionados pueden acceder más fácilmente a las cookies del usuario.
Ejemplo 1: el siguiente código crea una cookie sin configurar la propiedad HttpOnly.

cookie := http.Cookie{
  Name:     "emailCookie",
  Value:    email,
}
...

Todos los exploradores más comunes admiten la propiedad de cookie HttpOnly que evita que scripts del lado del cliente puedan acceder a la cookie. Los ataques de Cross-Site Scripting suelen acceder a las cookies con el fin de robar los identificadores de sesión o los tokens de autenticación. Cuando HttpOnly no está habilitado, los atacantes pueden acceder más fácilmente a las cookies del usuario.
Ejemplo 1: el siguiente código crea una cookie sin configurar la propiedad HttpOnly.

javax.servlet.http.Cookie cookie = new javax.servlet.http.Cookie("emailCookie", email);
// Missing a call to: cookie.setHttpOnly(true);

Todos los exploradores más comunes admiten la propiedad de cookie HttpOnly que evita que scripts del lado del cliente puedan acceder a la cookie. Los ataques de Cross-Site Scripting suelen acceder a las cookies con el fin de robar los identificadores de sesión o los tokens de autenticación. Cuando HttpOnly no está habilitado, los atacantes pueden acceder más fácilmente a las cookies del usuario.
Ejemplo 1: el siguiente código crea una cookie sin configurar la propiedad httpOnly.

  res.cookie('important_cookie', info, {domain: 'secure.example.com', path: '/admin'});

Todos los exploradores más comunes admiten la propiedad de cookie HttpOnly que evita que scripts del lado del cliente puedan acceder a la cookie. Los ataques de Cross-Site Scripting suelen acceder a las cookies con el fin de robar los identificadores de sesión o los tokens de autenticación. Cuando HttpOnly no está habilitado, los atacantes pueden acceder más fácilmente a las cookies del usuario.
Ejemplo 1: el siguiente código crea una cookie sin configurar la propiedad HttpOnly.

setcookie("emailCookie", $email, 0, "/", "www.example.com", TRUE);  //Missing 7th parameter to set HttpOnly

Los exploradores admiten la propiedad de cookie HttpOnly que evita que scripts del lado del cliente puedan acceder a la cookie. Los ataques de Cross-Site Scripting suelen acceder a las cookies con el fin de robar los identificadores de sesión o los tokens de autenticación. Cuando HttpOnly no está habilitado, los atacantes pueden acceder más fácilmente a las cookies del usuario.
Ejemplo 1: el siguiente código crea una cookie sin configurar la propiedad HttpOnly.

from django.http.response import HttpResponse
...
def view_method(request):
  res = HttpResponse()
  res.set_cookie("emailCookie", email)
  return res
...

A menudo, los desarrolladores configuran las cookies para que se activen en un dominio básico como ".example.com". Esto expone la cookie a todas las aplicaciones web del dominio básico y los subdominios. Puesto que es frecuente que las cookies porten información confidencial como identificadores de sesión, compartir las cookies entre aplicaciones puede provocar que una vulnerabilidad de una aplicación comprometa a otra.

Ejemplo:
Imagine que tiene una aplicación segura implementada en http://secure.example.com/ y que la aplicación define una cookie de ID de sesión con un dominio ".example.com" cuando un usuario inicia sesión.

Por ejemplo:

  HttpCookie cookie = new HttpCookie("sessionID", sessionID);
  cookie.Domain = ".example.com";

Supongamos que tiene otra aplicación menos segura en http://insecure.example.com/ que contiene una vulnerabilidad Cross-Site Scripting. Cualquier usuario autenticado en http://secure.example.com que acceda a http://insecure.example.com corre el riesgo de exponer su cookie de sesión de http://secure.example.com.

Además de leer una cookie, los atacantes podrían realizar un ataque de Cookie Poisoning utilizando insecure.example.com para crear su propia cookie demasiado grande que sustituya a la cookie de secure.example.com.

A menudo, los desarrolladores configuran las cookies para que se activen en un dominio básico como ".example.com". Esto expone la cookie a todas las aplicaciones web del dominio básico y los subdominios. Puesto que es frecuente que las cookies porten información confidencial como identificadores de sesión, compartir las cookies entre aplicaciones puede provocar que una vulnerabilidad de una aplicación comprometa a otra.

Ejemplo 1: Imagine que tiene una aplicación segura implementada en http://secure.example.com/ y que la aplicación define una cookie de ID de sesión con un dominio ".example.com" cuando los usuarios inician sesión.

Por ejemplo:

cookie := http.Cookie{
  Name:       "sessionID",
  Value:      getSessionID(),
  Domain:     ".example.com",
}
...

Supongamos que tiene otra aplicación menos segura en http://insecure.example.com/ que contiene una vulnerabilidad Cross-Site Scripting. Cualquier usuario autenticado en http://secure.example.com que acceda a http://insecure.example.com corre el riesgo de exponer su cookie de sesión de http://secure.example.com.

Además de leer una cookie, los atacantes pueden realizar un "ataque de envenenamiento de cookies" mediante el uso de insecure.example.com para crear su propia cookie demasiado grande que sustituya a la cookie de Secure.example.com.

A menudo, los desarrolladores configuran las cookies para que se activen en un dominio básico como ".example.com". Esto expone la cookie a todas las aplicaciones web del dominio básico y los subdominios. Puesto que es frecuente que las cookies porten información confidencial como identificadores de sesión, compartir las cookies entre aplicaciones puede provocar que una vulnerabilidad de una aplicación comprometa a otra.

Ejemplo 1:
Imagine que tiene una aplicación segura implementada en http://secure.example.com/ y que la aplicación define una cookie de ID de sesión con un dominio ".example.com" cuando los usuarios inician sesión.

Por ejemplo:

  Cookie cookie = new Cookie("sessionID", sessionID);
  cookie.setDomain(".example.com");

Supongamos que tiene otra aplicación menos segura en http://insecure.example.com/ y que contiene una vulnerabilidad de Cross-Site Scripting. Cualquier usuario autenticado en http://secure.example.com que acceda a http://insecure.example.com crea un riesgo al exponer su cookie de sesión de http://secure.example.com.

Además de leer una cookie, los atacantes podrían realizar un ataque de envenenamiento de cookies utilizando insecure.example.com para crear su propia cookie demasiado grande que sustituya a la cookie de secure.example.com.

A menudo, los desarrolladores configuran las cookies para que se activen en un dominio básico como ".example.com". Esto expone la cookie a todas las aplicaciones web del dominio básico y los subdominios. Puesto que es frecuente que las cookies porten información confidencial como identificadores de sesión, compartir las cookies entre aplicaciones puede provocar que una vulnerabilidad de una aplicación comprometa a otra.

Ejemplo 1:
Imagine que tiene una aplicación segura implementada en http://secure.example.com/ y que la aplicación define una cookie de ID de sesión con un dominio ".example.com" cuando los usuarios inician sesión.

Por ejemplo:

  cookie_options = {};
  cookie_options.domain = '.example.com';
  ...
  res.cookie('important_cookie', info, cookie_options);

Supongamos que tiene otra aplicación menos segura en http://insecure.example.com/ y que contiene una vulnerabilidad de Cross-Site Scripting. Cualquier usuario autenticado en http://secure.example.com que acceda a http://insecure.example.com crea un riesgo al exponer su cookie de sesión de http://secure.example.com.

Además de leer una cookie, los atacantes podrían realizar un ataque de envenenamiento de cookies utilizando insecure.example.com para crear su propia cookie demasiado grande que sustituya a la cookie de secure.example.com.

A menudo, los desarrolladores configuran las cookies para que se activen en un dominio básico como ".example.com". Esto expone la cookie a todas las aplicaciones web del dominio básico y los subdominios. Puesto que es frecuente que las cookies porten información confidencial como identificadores de sesión, compartir las cookies entre aplicaciones puede provocar que una vulnerabilidad de una aplicación comprometa a otra.

Ejemplo 1:
Imagine que tiene una aplicación segura implementada en http://secure.example.com/ y que la aplicación define una cookie de ID de sesión con un dominio ".example.com" cuando los usuarios inician sesión.

Por ejemplo:

  ...
  NSDictionary *cookieProperties = [NSDictionary dictionary];
  ...
  [cookieProperties setValue:@".example.com" forKey:NSHTTPCookieDomain];
  ...
  NSHTTPCookie *cookie = [NSHTTPCookie cookieWithProperties:cookieProperties];
  ...

Supongamos que tiene otra aplicación menos segura en http://insecure.example.com/ y que contiene una vulnerabilidad de Cross-Site Scripting. Cualquier usuario autenticado en http://secure.example.com que acceda a http://insecure.example.com crea un riesgo al exponer su cookie de sesión de http://secure.example.com.

Además de leer una cookie, los atacantes podrían realizar un ataque de envenenamiento de cookies utilizando insecure.example.com para crear su propia cookie demasiado grande que sustituya a la cookie de secure.example.com.

A menudo, los desarrolladores configuran las cookies para que se activen en un dominio básico como ".example.com". Esto expone la cookie a todas las aplicaciones web del dominio básico y los subdominios. Puesto que es frecuente que las cookies porten información confidencial como identificadores de sesión, compartir las cookies entre aplicaciones puede provocar que una vulnerabilidad de una aplicación comprometa a otra.

Ejemplo 1:
Imagine que tiene una aplicación segura implementada en http://secure.example.com/ y que la aplicación define una cookie de ID de sesión con un dominio ".example.com" cuando los usuarios inician sesión.

Por ejemplo:

setcookie("mySessionId", getSessionID(), 0, "/", ".example.com", true, true);

Supongamos que tiene otra aplicación menos segura en http://insecure.example.com/ y que contiene una vulnerabilidad de Cross-Site Scripting. Cualquier usuario autenticado en http://secure.example.com que acceda a http://insecure.example.com crea un riesgo al exponer su cookie de sesión de http://secure.example.com.

Además de leer una cookie, los atacantes podrían realizar un ataque de envenenamiento de cookies utilizando insecure.example.com para crear su propia cookie demasiado grande que sustituya a la cookie de secure.example.com.

A menudo, los desarrolladores configuran las cookies para que se activen en un dominio básico como ".example.com". Esto expone la cookie a todas las aplicaciones web del dominio básico y los subdominios. Puesto que es frecuente que las cookies porten información confidencial como identificadores de sesión, compartir las cookies entre aplicaciones puede provocar que una vulnerabilidad de una aplicación comprometa a otra.

Ejemplo 1: Imagine que tiene una aplicación segura implementada en http://secure.example.com/ y que la aplicación define una cookie de ID de sesión con un dominio ".example.com" cuando los usuarios inician sesión.

Por ejemplo:

from django.http.response import HttpResponse
...
def view_method(request):
  res = HttpResponse()
  res.set_cookie("mySessionId", getSessionID(), domain=".example.com")
  return res
...

Supongamos que tiene otra aplicación menos segura en http://insecure.example.com/ y que contiene una vulnerabilidad de Cross-Site Scripting. Cualquier usuario autenticado en http://secure.example.com que acceda a http://insecure.example.com crea un riesgo al exponer su cookie de sesión de http://secure.example.com.

Además de leer una cookie, los usuarios malintencionados podrían realizar un "ataque de envenenamiento de cookies" utilizando insecure.example.com para crear su propia cookie demasiado grande que sustituya a la cookie de secure.example.com.

A menudo, los desarrolladores configuran las cookies para que se activen en un dominio básico como ".example.com". Esto expone la cookie a todas las aplicaciones web del dominio básico y los subdominios. Puesto que es frecuente que las cookies porten información confidencial como identificadores de sesión, compartir las cookies entre aplicaciones puede provocar que una vulnerabilidad de una aplicación comprometa a otra.

Ejemplo 1:
Imagine que tiene una aplicación segura implementada en http://secure.example.com/ y que la aplicación define una cookie de ID de sesión con un dominio ".example.com" cuando los usuarios inician sesión.

Por ejemplo:

...
let properties = [
    NSHTTPCookieDomain: ".example.com",
    NSHTTPCookiePath: "/service",
    NSHTTPCookieName: "foo",
    NSHTTPCookieValue: "bar",
    NSHTTPCookieSecure: true
]
let cookie : NSHTTPCookie? = NSHTTPCookie(properties:properties)
...

Supongamos que tiene otra aplicación menos segura en http://insecure.example.com/ y que contiene una vulnerabilidad de Cross-Site Scripting. Cualquier usuario autenticado en http://secure.example.com que acceda a http://insecure.example.com crea un riesgo al exponer su cookie de sesión de http://secure.example.com.

Además de leer una cookie, los atacantes podrían realizar un ataque de envenenamiento de cookies utilizando insecure.example.com para crear su propia cookie demasiado grande que sustituya a la cookie de secure.example.com.

A menudo, los desarrolladores configuran las cookies para que sean accesibles desde la ruta de acceso al contexto raíz ("/"). Al hacerlo, se expone la cookie a todas las aplicaciones web del dominio. Puesto que es frecuente que las cookies porten información confidencial como identificadores de sesión, compartir las cookies entre aplicaciones puede provocar que una vulnerabilidad de una aplicación comprometa a otra.

Ejemplo 1:
Imagine que tiene una aplicación de foros implementada en http://communitypages.example.com/MyForum y que la aplicación define una cookie de ID de sesión con una ruta "/" cuando los usuarios inician sesión en un foro. Por ejemplo:

...
String path = '/';
Cookie cookie = new Cookie('sessionID', sessionID, path, maxAge, true, 'Strict');
...

Imagine que un atacante crea otra aplicación en http://communitypages.example.com/EvilSite y publica un vínculo a este sitio en el foro. Cuando un usuario del foro hace clic en este vínculo, el explorador envía la cookie configurada mediante /MyForum a la aplicación que se ejecuta en /EvilSite. Al robar el identificador de sesión, el atacante puede comprometer la cuenta de cualquier usuario del foro que haya navegado a /EvilSite.

Además de leer una cookie, los usuarios malintencionados podrían realizar un ataque de Cookie Poisoning utilizando /EvilSite para crear su propia cookie demasiado grande que sustituya a la cookie de /MyForum.

A menudo, los desarrolladores configuran las cookies para que sean accesibles desde la ruta de acceso al contexto raíz "/"; no obstante, de esta forma se expone la cookie a todas las aplicaciones web del mismo nombre de dominio. Puesto que es frecuente que las cookies porten información confidencial como identificadores de sesión, compartir las cookies entre aplicaciones puede provocar que una vulnerabilidad de una aplicación comprometa a otra.

Ejemplo:
Imagine que tiene una aplicación de foros implementada en http://communitypages.example.com/MyForum y que la aplicación define una cookie de ID de sesión con una ruta "/" cuando los usuarios inician sesión.

Por ejemplo:

  HttpCookie cookie = new HttpCookie("sessionID", sessionID);
  cookie.Path = "/";

Imagine que un atacante crea otra aplicación en http://communitypages.example.com/EvilSite y publica un vínculo a este sitio en el foro. Cuando un usuario del foro hace clic en este vínculo, el explorador envía la cookie configurada mediante /MyForum a la aplicación que se ejecuta en /EvilSite. Si se apodera del ID de sesión, el usuario malintencionado puede comprometer la cuenta de cualquier usuario del foro que haya navegado a /EvilSite.

Además de leer una cookie, los atacantes podrían realizar un ataque de envenenamiento de cookies utilizando /EvilSite para crear su propia cookie demasiado grande que sustituya a la cookie de /MyForum.

A menudo, los desarrolladores configuran las cookies para que sean accesibles desde la ruta de acceso al contexto raíz ("/"). Al hacerlo, se expone la cookie a todas las aplicaciones web del dominio. Puesto que es frecuente que las cookies porten información confidencial como identificadores de sesión, compartir las cookies entre aplicaciones puede provocar que una vulnerabilidad de una aplicación comprometa a otra.

Ejemplo 1:
Supongamos que tiene una aplicación de foros implementada en http://communitypages.example.com/MyForum y que la aplicación define una cookie de ID de sesión con una ruta "/" cuando los usuarios inician sesión.

Por ejemplo:

cookie := http.Cookie{
  Name:    "sessionID",
  Value:   sID,
  Expires: time.Now().AddDate(0, 0, 1),
  Path:    "/",
}
...

Imagine que un atacante crea otra aplicación en http://communitypages.example.com/EvilSite y publica un vínculo a este sitio en el foro. Cuando un usuario del foro hace clic en este vínculo, el explorador envía la cookie configurada mediante /MyForum a la aplicación que se ejecuta en /EvilSite. Al robar el identificador de sesión, el atacante puede comprometer la cuenta de cualquier usuario del foro que haya navegado a /EvilSite.

Además de leer una cookie, los atacantes pueden realizar un "ataque de envenenamiento de cookies" mediante el uso de /EvilSite para crear su propia cookie demasiado grande que sustituya a la cookie de /MyForum.

A menudo, los desarrolladores configuran las cookies para que sean accesibles desde la ruta de acceso al contexto raíz ("/"). Al hacerlo, se expone la cookie a todas las aplicaciones web del dominio. Puesto que es frecuente que las cookies porten información confidencial como identificadores de sesión, compartir las cookies entre aplicaciones puede provocar que una vulnerabilidad de una aplicación comprometa a otra.

Ejemplo 1:
Imagine que tiene una aplicación de foros implementada en http://communitypages.example.com/MyForum y que la aplicación define una cookie de ID de sesión con una ruta "/" cuando los usuarios inician sesión.

Por ejemplo:

  Cookie cookie = new Cookie("sessionID", sessionID);
  cookie.setPath("/");

Imagine que un atacante crea otra aplicación en http://communitypages.example.com/EvilSite y publica un vínculo a este sitio en el foro. Cuando un usuario del foro hace clic en este vínculo, el explorador envía la cookie configurada mediante /MyForum a la aplicación que se ejecuta en /EvilSite. Si se apodera del ID de sesión, el usuario malintencionado puede comprometer la cuenta de cualquier usuario del foro que haya navegado a /EvilSite.

Además de leer una cookie, los atacantes podrían realizar un ataque de envenenamiento de cookies utilizando /EvilSite para crear su propia cookie demasiado grande que sustituya a la cookie de /MyForum.