La API AccessibleObject permite que el programador eluda las comprobaciones de control de acceso proporcionadas por los especificadores de acceso de Java. En particular, permite que el programador permita que un objeto reflejado eluda los controles de acceso de Java y a cambio cambie el valor de los campos privados o invoque métodos privados, es decir, comportamientos que normalmente están prohibidos.

En una aplicación JSF normal, los valores se convierten y validan mediante convertidores y validadores especificados por los componentes de la interfaz de usuario. La conversión y validación en sí ocurre cuando se envía la página. Una vista que se puede marcar en una aplicación Fusion no causa el envío de páginas y, por lo tanto, no se realiza una conversión o validación similar de forma predeterminada.

Ejemplo 1: El siguiente fragmento de archivo de configuración muestra una vista de muestra, que se puede marcar como favorita, configurada para no realizar ninguna conversión o validación del parámetro de URL paramName.

...
    <bookmark>
        <method>#{paramHandler.handleParams}</method>
        <url-parameter>
            <name>paramName</name>
            <value>#{requestScope.paramName}</value>
        </url-parameter>
    </bookmark>
...

Las vulnerabilidades de secuestro al cargar clases de Android se presentan de dos formas:

- Un usuario malintencionado puede cambiar el nombre de los directorios que busca el programa para cargar clases, de modo que la ruta señale a un directorio que controla: este controla de forma explícita las rutas en las que se buscarán las clases.

- Un usuario malintencionado puede cambiar el entorno donde se carga la clase: este controla de forma implícita lo que significa el nombre de la ruta.

En este caso, nos preocupa principalmente el primer caso, la posibilidad de que un usuario malintencionado pueda controlar los directorios donde se buscan las clases para cargar. Las vulnerabilidades de secuestro al cargar clases de Android de este tipo tienen lugar cuando:

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



2. Los datos se utilizan como una cadena, o parte de ella, que representa un directorio de biblioteca donde buscar las clases para cargar.



3. Al ejecutar el código desde la ruta de la biblioteca, la aplicación concede al usuario malintencionado un privilegio o capacidad que, de lo contrario, no tendría.

Ejemplo 1: el siguiente código utiliza la userClassPath modificable por el usuario para determinar el directorio donde buscar las clases para cargar.

...
  productCategory = this.getIntent().getExtras().getString("userClassPath");
  DexClassLoader dexClassLoader = new DexClassLoader(productCategory, optimizedDexOutputPath.getAbsolutePath(), null, getClassLoader());
  ...

Este código permite a un usuario malintencionado cargar una biblioteca y posiblemente ejecutar código arbitrario con el privilegio elevado de la aplicación mediante la modificación de userClassPath para que señale a una ruta diferente que controla este. Como el programa no valida el valor leído del entorno, si un usuario malintencionado puede controlar el valor de userClassPath, podría engañar a la aplicación para que señalara un directorio controlado por él y, por lo tanto, cargar las clases que hubiera definido, utilizando los mismos privilegios que la aplicación original.

Ejemplo 2: el siguiente código utiliza la userOutput modificable por el usuario para determinar el directorio donde deberían escribirse los archivos DEX optimizados.

...
  productCategory = this.getIntent().getExtras().getString("userOutput");
  DexClassLoader dexClassLoader = new DexClassLoader(sanitizedPath, productCategory, null, getClassLoader());
...

Este código permite a un usuario malintencionado especificar el directorio de salida para los archivos DEX optimizados (ODEX). Esto permite a un usuario malintencionado cambiar el valor de userOutput por un directorio que controle, como por ejemplo almacenamiento externo. Una vez logrado esto, basta con reemplazar el archivo ODEX producido con un archivo ODEX malintencionado para ejecutar este con los mismos privilegios que la aplicación original.

Las entradas sin validar son una de las principales causas de vulnerabilidades en los servicios de API web ASP.NET. Las entradas no comprobadas pueden llevar a muchas vulnerabilidades, incluidas Cross-Site Scripting, Process Control, Access Control y SQL Injection, entre otras. Aunque los servicios de API web ASP.NET normalmente no son susceptibles de ataques de corrupción de memoria, si un servicio de API web ASP.NET llama en código nativo que no realiza comprobaciones de enlaces de matriz, un atacante puede utilizar una debilidad de validación de entrada del servicio de API web ASP.NET para iniciar un ataque de buffer overflow.

Para evitar ataques de este tipo:
1. Utilice atributos de validación para anotar comprobaciones de validación mediante programación en parámetros o miembros de parámetros de objeto de enlace de modelos para acciones del servicio de API web ASP.NET.
2. Utilice ModelState.IsValid para comprobar si la validación del modelo es correcta.

Los nombres y los valores de las propiedades bean tienen que validarse antes de rellenar cualquier bean. Las funciones de relleno bean permiten a los desarrolladores establecer una propiedad bean o una propiedad anidada. Un atacante puede aprovechar esta funcionalidad para acceder a propiedades bean especiales, como class.classLoader, que le permitirá sobrescribir propiedades del sistema y ejecutar potencialmente código arbitrario.

Ejemplo: el código siguiente establece una propiedad bean controlada por el usuario sin validación adecuada del nombre o valor de la propiedad:

String prop = request.getParameter('prop');
String value = request.getParameter('value');
HashMap properties = new HashMap();
properties.put(prop, value);
BeanUtils.populate(user, properties);

El buffer overflow es probablemente la forma más conocida de vulnerabilidad de seguridad de software. La mayoría de los desarrolladores de software saben lo que es una vulnerabilidad de buffer overflow, pero a menudo este tipo de ataques contra las aplicaciones existentes y desarrolladas recientemente son aún bastante habituales. Parte del problema se debe a la amplia variedad de formas en las que puede producirse un buffer overflow y otra parte se debe a las técnicas proclives a errores que a menudo se utilizan para evitarlas.

En un ataque de buffer overflow clásico, el usuario malintencionado envía datos a un programa, que los almacena en un búfer de pila demasiado pequeño. El resultado es que se sobrescribe la información de la pila de llamadas, incluido el puntero de devolución de la función. Los datos establecen el valor del puntero de devolución para que, cuando se devuelva la función, esta transfiera el control al código malicioso incluido en los datos del usuario malintencionado.

Aunque este tipo de buffer overflow de pila aún es frecuente en algunas plataformas y comunidades de desarrolladores, existen diversos tipos adicionales de buffer overflow, incluidos los desbordamientos del búfer de montón y los errores por uno ("off-by-one"), entre otros. Hay una serie de libros excelentes que ofrecen información detallada sobre cómo funcionan los ataques de buffer overflow, incluidos "Bilding Secure Software" [1], "Writing Secure Code" [2] y "The Shellcoder's Handbook" [3].

En el nivel de código, las vulnerabilidades de buffer overflow normalmente conllevan la infracción de las presuposiciones de un programador. Muchas funciones de manipulación de memoria de C y C++ no realizan comprobaciones de límites y pueden sobrescribir fácilmente los límites asignados de los búferes en los que funcionan. Incluso las funciones limitadas como, por ejemplo, strncpy(), pueden provocar vulnerabilidades cuando se utilizan incorrectamente. La combinación de manipulación de memoria y presuposiciones erróneas acerca del tamaño y la formación de una unidad de datos es el motivo principal de la mayoría de desbordamientos del búfer.

Las vulnerabilidades de buffer overflow suelen producirse en código que:

- Utiliza datos externos para controlar su comportamiento.

- Depende de las propiedades de los datos que se aplican fuera del ámbito inmediato del código.

- Es tan complejo que un programador no puede predecir con precisión su comportamiento.



Los siguientes ejemplos muestran estos tres escenarios.

Ejemplo 1.a: el siguiente código de ejemplo muestra un buffer overflow sencillo que a menudo lo provoca el primer escenario en el que el código utiliza los datos externos para controlar su comportamiento. El código utiliza la función gets() para leer una cantidad arbitraria de datos en un búfer de pila. Como no hay forma de limitar la cantidad de datos leídos por esta función, la seguridad del código depende siempre de que el usuario introduzca un número de caracteres inferior a BUFSIZE.

	...
	char buf[BUFSIZE];
	gets(buf);
	...

Ejemplo 1.b: en este ejemplo se muestra lo fácil que es imitar el comportamiento poco seguro de la función gets() en C++ mediante el uso del operador >> para leer la entrada en una cadena char[].

	...
	char buf[BUFSIZE];
	cin >> (buf);
	...

Ejemplo 2: el código de este ejemplo utiliza también la entrada de usuario para controlar su comportamiento, pero añade un nivel de indirección con el uso de la función de copia de memoria limitada memcpy(). Esta función acepta un búfer de destino y uno de origen, y el número de bytes que se va a copiar. El búfer de entrada se llena con una llamada limitada a read(). Sin embargo, el usuario especifica el número de bytes que memcpy() copia.

	...
char buf[64], in[MAX_SIZE];
printf("Enter buffer contents:\n");
read(0, in, MAX_SIZE-1);
printf("Bytes to copy:\n");
scanf("%d", &bytes);
memcpy(buf, in, bytes);
	...

Nota: este tipo de vulnerabilidad de buffer overflow (en el que un programa lee datos y, a continuación, confía en un valor de los datos de las operaciones de memoria posteriores en los datos restantes) ha surgido con frecuencia en bibliotecas de imágenes, audio y otros archivos.

Ejemplo 3: este es un ejemplo del segundo escenario en el que el código depende de propiedades de los datos que no se han verificado localmente. En este ejemplo una función denominada lccopy() utiliza una cadena como argumento y devuelve la copia asignada por montón de la cadena con las letras en mayúsculas convertidas a minúsculas. La función no realiza ninguna comprobación de límites en esta entrada por esquema que str sea siempre menor que BUFSIZE. Si un usuario malintencionado omite las comprobaciones del código que llama a lccopy() o si un cambio realizado en ese código invalida la presuposición acerca del tamaño de str, lccopy() desbordará buf con la llamada a strcpy() no limitada.

char *lccopy(const char *str) {
	char buf[BUFSIZE];
	char *p;

	strcpy(buf, str);
	for (p = buf; *p; p++) {
		if (isupper(*p)) {
			*p = tolower(*p);
		}
	}
	return strdup(buf);
}

Ejemplo 4: El siguiente código demuestra el tercer escenario en el que el código es tan complejo que su comportamiento no se puede predecir fácilmente. Este código proviene del popular decodificador de imágenes libPNG, que es utilizado por una amplia gama de aplicaciones.

El código parece realizar con seguridad la comprobación de límites porque comprueba el tamaño de la longitud de variable, que se utiliza posteriormente para calcular la cantidad de datos copiados por png_crc_read(). Sin embargo, justo después de que se pruebe la longitud, el código realiza una comprobación en png_ptr->mode y, si esta presenta errores, se emite una advertencia y el proceso continúa. Como length se prueba en un bloque else if, length no se probará si la primera comprobación presenta errores y se utilizará ciegamente en la llamada a png_crc_read(), provocando un posible buffer overflow de pila.

Aunque el código de este ejemplo no es el más complejo que hayamos visto, muestra por qué debe reducirse al mínimo la complejidad en el código que realiza operaciones de memoria.

if (!(png_ptr->mode & PNG_HAVE_PLTE)) {
	/* Should be an error, but we can cope with it */
png_warning(png_ptr, "Missing PLTE before tRNS");
}
else if (length > (png_uint_32)png_ptr->num_palette) {
png_warning(png_ptr, "Incorrect tRNS chunk length");
png_crc_finish(png_ptr, length);
return;
}
...
png_crc_read(png_ptr, readbuf, (png_size_t)length);

Ejemplo 5: en este ejemplo también se muestra el tercer escenario en el que la complejidad del programa lo expone a desbordamientos del búfer. En ese caso, la exposición se debe a la interfaz ambigua de una de las funciones en lugar de a la estructura del código (como sí lo hacía en el ejemplo anterior).

La función getUserInfo() utiliza un nombre de usuario especificado por una cadena multibyte y un puntero a una estructura para la información de usuario, y rellena la estructura con información del usuario. Como la autenticación de Windows utiliza Unicode para los nombres de usuario, el argumento username se convierte primero de una cadena multibyte a una Unicode. A continuación, esta función transfiere de forma incorrecta el tamaño de unicodeUser en bytes en lugar de caracteres. Así pues, la llamada a MultiByteToWideChar() puede escribir hasta (UNLEN+1)*sizeof(WCHAR) caracteres anchos o
(UNLEN+1)*sizeof(WCHAR)*sizeof(WCHAR) bytes en la matriz unicodeUser, que solo tiene (UNLEN+1)*sizeof(WCHAR) bytes asignados. Si la cadena username contiene más de UNLEN caracteres, la llamada a MultiByteToWideChar() desbordará el búfer unicodeUser.

void getUserInfo(char *username, struct _USER_INFO_2 info){
WCHAR unicodeUser[UNLEN+1];
	MultiByteToWideChar(CP_ACP, 0, username, -1,
    	      			unicodeUser, sizeof(unicodeUser));
NetUserGetInfo(NULL, unicodeUser, 2, (LPBYTE *)&info);
}

El buffer overflow es probablemente la forma más conocida de vulnerabilidad de seguridad de software. La mayoría de los desarrolladores de software saben lo que es una vulnerabilidad de buffer overflow, pero a menudo este tipo de ataques contra las aplicaciones existentes y desarrolladas recientemente son aún bastante habituales. Parte del problema se debe a la amplia variedad de formas en las que puede producirse un buffer overflow y otra parte se debe a las técnicas proclives a errores que a menudo se utilizan para evitarlas.

En un ataque de buffer overflow clásico, el usuario malintencionado envía datos a un programa, que los almacena en un búfer de pila demasiado pequeño. El resultado es que se sobrescribe la información de la pila de llamadas, incluido el puntero de devolución de la función. Los datos establecen el valor del puntero de devolución para que, cuando se devuelva la función, esta transfiera el control al código malicioso incluido en los datos del usuario malintencionado.

Aunque este tipo de buffer overflow de pila aún es frecuente en algunas plataformas y comunidades de desarrolladores, existen diversos tipos adicionales de buffer overflow, incluidos los desbordamientos del búfer de montón y los errores por uno ("off-by-one"), entre otros. Hay una serie de libros excelentes que ofrecen información detallada sobre cómo funcionan los ataques de buffer overflow, incluidos "Bilding Secure Software" [1], "Writing Secure Code" [2] y "The Shellcoder's Handbook" [3].

En el nivel de código, las vulnerabilidades de buffer overflow normalmente conllevan la infracción de las presuposiciones de un programador. Muchas funciones de manipulación de la memoria de C y C++ no realizan la comprobación de límites y pueden traspasar fácilmente los límites asignados de los búferes en los que operan. Incluso las funciones limitadas como, por ejemplo, strncpy(), pueden provocar vulnerabilidades cuando se utilizan incorrectamente. La combinación de manipulación de memoria y presuposiciones erróneas acerca del tamaño y la formación de una unidad de datos es el motivo principal de la mayoría de desbordamientos del búfer.

En este caso, una cadena de formato construida incorrectamente provoca que el programa escriba más allá de los límites de la memoria asignada.

Ejemplo: el código siguiente desborda c porque el tipo double necesita más espacio que el asignado para c.

void formatString(double d) {
    char c;

    scanf("%d", &c)
}

El buffer overflow es probablemente la forma más conocida de vulnerabilidad de seguridad de software. La mayoría de los desarrolladores de software saben lo que es una vulnerabilidad de buffer overflow, pero a menudo este tipo de ataques contra las aplicaciones existentes y desarrolladas recientemente son aún bastante habituales. Parte del problema se debe a la amplia variedad de formas en las que puede producirse un buffer overflow y otra parte se debe a las técnicas proclives a errores que a menudo se utilizan para evitarlas.

En un ataque de buffer overflow clásico, el usuario malintencionado envía datos a un programa, que los almacena en un búfer de pila demasiado pequeño. El resultado es que se sobrescribe la información de la pila de llamadas, incluido el puntero de devolución de la función. Los datos establecen el valor del puntero de devolución para que, cuando se devuelva la función, esta transfiera el control al código malicioso incluido en los datos del usuario malintencionado.

Aunque este tipo de buffer overflow de pila aún es frecuente en algunas plataformas y comunidades de desarrolladores, existen diversos tipos adicionales de buffer overflow, incluidos los desbordamientos del búfer de montón y los errores por uno ("off-by-one"), entre otros. Hay una serie de libros excelentes que ofrecen información detallada sobre cómo funcionan los ataques de buffer overflow, incluidos "Bilding Secure Software" [1], "Writing Secure Code" [2] y "The Shellcoder's Handbook" [3].

En el nivel de código, las vulnerabilidades de buffer overflow normalmente conllevan la infracción de las presuposiciones de un programador. Muchas funciones de manipulación de la memoria de C y C++ no realizan la comprobación de límites y pueden traspasar fácilmente los límites asignados de los búferes en los que operan. Incluso las funciones limitadas como, por ejemplo, strncpy(), pueden provocar vulnerabilidades cuando se utilizan incorrectamente. La combinación de manipulación de memoria y presuposiciones erróneas acerca del tamaño y la formación de una unidad de datos es el motivo principal de la mayoría de desbordamientos del búfer.

En este caso, una cadena de formato construida incorrectamente provoca que el programa escriba más allá de los límites de la memoria asignada.

Ejemplo: el código siguiente desborda buf porque, según el tamaño de f, el especificador de cadena de formato "%d %.1f ... " puede superar la cantidad de memoria asignada.

void formatString(int x, float f) {
   char buf[40];
   sprintf(buf, "%d %.1f ... ", x, f);
}

El buffer overflow es probablemente la forma más conocida de vulnerabilidad de seguridad de software. La mayoría de los desarrolladores de software saben lo que es una vulnerabilidad de buffer overflow, pero a menudo este tipo de ataques contra las aplicaciones existentes y desarrolladas recientemente son aún bastante habituales. Parte del problema se debe a la amplia variedad de formas en las que puede producirse un buffer overflow y otra parte se debe a las técnicas proclives a errores que a menudo se utilizan para evitarlas.

En un ataque de buffer overflow clásico, el usuario malintencionado envía datos a un programa, que los almacena en un búfer de pila demasiado pequeño. El resultado es que se sobrescribe la información de la pila de llamadas, incluido el puntero de devolución de la función. Los datos establecen el valor del puntero de devolución para que, cuando se devuelva la función, esta transfiera el control al código malicioso incluido en los datos del usuario malintencionado.

Aunque este tipo de error por uno ("off-by-one") sigue siendo normal en algunas plataformas y comunidades de desarrollo, hay más tipos de buffer overflow, entre los que se incluyen los desbordamientos de búfer de pila y de montón. Hay una serie de libros excelentes que ofrecen información detallada sobre cómo funcionan los ataques de buffer overflow, incluidos "Bilding Secure Software" [1], "Writing Secure Code" [2] y "The Shellcoder's Handbook" [3].

En el nivel de código, las vulnerabilidades de buffer overflow normalmente conllevan la infracción de las presuposiciones de un programador. Muchas funciones de manipulación de la memoria de C y C++ no realizan la comprobación de límites y pueden traspasar fácilmente los límites asignados de los búferes en los que operan. Incluso las funciones limitadas como, por ejemplo, strncpy(), pueden provocar vulnerabilidades cuando se utilizan incorrectamente. La combinación de manipulación de memoria y presuposiciones erróneas acerca del tamaño y la formación de una unidad de datos es el motivo principal de la mayoría de desbordamientos del búfer.

Ejemplo: El código siguiente contiene un desbordamiento del búfer por una unidad, que se produce cuando recv devuelve el máximo de bytes leídos: sizeof(buf). En este caso, la siguiente desreferencia de buf[nbytes] escribirá el byte null fuera de los límites de memoria asignada.

void receive(int socket) {
   char buf[MAX];
   int nbytes = recv(socket, buf, sizeof(buf), 0);
   buf[nbytes] = '\0';
   ...
}

El buffer overflow es probablemente la forma más conocida de vulnerabilidad de seguridad de software. La mayoría de los desarrolladores de software saben lo que es una vulnerabilidad de buffer overflow, pero a menudo este tipo de ataques contra las aplicaciones existentes y desarrolladas recientemente son aún bastante habituales. Parte del problema se debe a la amplia variedad de formas en las que puede producirse un buffer overflow y otra parte se debe a las técnicas proclives a errores que a menudo se utilizan para evitarlas.

En un ataque de buffer overflow clásico, el usuario malintencionado envía datos a un programa, que los almacena en un búfer de pila demasiado pequeño. El resultado es que se sobrescribe la información de la pila de llamadas, incluido el puntero de devolución de la función. Los datos establecen el valor del puntero de devolución para que, cuando se devuelva la función, esta transfiera el control al código malicioso incluido en los datos del usuario malintencionado.

Aunque este tipo de buffer overflow de pila aún es frecuente en algunas plataformas y comunidades de desarrolladores, existen diversos tipos adicionales de buffer overflow, incluidos los desbordamientos del búfer de montón y los errores por uno ("off-by-one"), entre otros. Hay una serie de libros excelentes que ofrecen información detallada sobre cómo funcionan los ataques de buffer overflow, incluidos "Bilding Secure Software" [1], "Writing Secure Code" [2] y "The Shellcoder's Handbook" [3].

En el nivel de código, las vulnerabilidades de buffer overflow normalmente conllevan la infracción de las presuposiciones de un programador. Muchas funciones de manipulación de la memoria de C y C++ no realizan la comprobación de límites y pueden traspasar fácilmente los límites asignados de los búferes en los que operan. Incluso las funciones limitadas como, por ejemplo, strncpy(), pueden provocar vulnerabilidades cuando se utilizan incorrectamente. La combinación de manipulación de memoria y presuposiciones erróneas acerca del tamaño y la formación de una unidad de datos es el motivo principal de la mayoría de desbordamientos del búfer.

Ejemplo: el código siguiente intenta evitar un buffer overflow por una unidad comprobando que el valor no confiable leído desde getInputLength() tiene un tamaño menor que el de la output del búfer de destino. Sin embargo, como la comparación entre len y MAX tiene signo, si len es negativo, se convertirá en un número positivo muy largo cuando se convierta a un argumento sin signo para memcpy().

void TypeConvert() {
   char input[MAX];
   char output[MAX];

   fillBuffer(input);
   int len = getInputLength();

   if (len <= MAX) {
      memcpy(output, input, len);
   }
   ...
}

Los motores de plantillas se usan para procesar contenido mediante datos dinámicos. El usuario suele controlar estos datos de contexto, a los que se les da formato mediante una plantilla para generar páginas web, correos electrónicos, etc. Los motores de plantillas permiten usar potentes expresiones de lenguaje en plantillas para procesar contenido dinámico; para ello, los datos de contexto se procesan con construcciones de codificación, como condicionales, bucles, etc. Si un atacante controla la plantilla que se desea procesar, puede inyectar expresiones que expongan los datos de contexto y ejecuten comandos arbitrarios en el explorador.

Ejemplo 1: en el ejemplo siguiente se muestra cómo recuperar una plantilla de una dirección URL y cómo se representa la información con AngularJS.

function MyController(function($stateParams, $interpolate){
    var ctx = { foo : 'bar' };
    var interpolated = $interpolate($stateParams.expression);
    this.rendered = interpolated(ctx);
    ...
}

En este caso, $stateParams.expression tomará datos potencialmente controlados por el usuario y los evaluará como una plantilla para utilizarlos con un contexto especificado. Esto, a su vez, puede permitir a un usuario malintencionado ejecutar cualquier código que desee en el explorador, recuperando información sobre el contexto en el que se ejecute, buscando información adicional sobre cómo se crea la aplicación o convirtiéndolo en un auténtico ataque XSS.

Las vulnerabilidades de inclusión no autorizadas se producen cuando:

1. Los datos tienen acceso a una aplicación web a través de una fuente que no es de confianza; la mayoría de las veces mediante una solicitud web.

2. Los datos forman parte de la cadena que especifica el atributo template de una etiqueta <cfinclude>.
Ejemplo: el siguiente código utiliza la entrada de un formulario web para crear la ruta de acceso a un archivo especial que se utiliza para dar formato a la página de inicio del usuario. El programador no ha considerado la posibilidad de que un usuario malintencionado pueda proporcionar un nombre de archivo malintencionado, como "../../users/wileyh/malicious", que provocará que la aplicación incluya y ejecute el contenido de un archivo en el directorio de inicio del usuario malintencionado.

<cfinclude template =  
              "C:\\custom\\templates\\#Form.username#.cfm">

Si un atacante puede especificar el archivo incluido por la etiqueta <cfinclude>, puede provocar que la aplicación incluya el contenido de casi cada archivo en el sistema de archivos del servidor de la página actual. Esta capacidad se puede aprovechar como mínimo de dos maneras significativas. Si un atacante puede escribir en una ubicación del sistema de archivos del servidor, como el directorio de inicio del usuario o un directorio común de carga, podrá provocar que la aplicación incluya un archivo con contenido perjudicial en la página, que ejecutará el servidor. Incluso sin acceso de escritura al sistema de archivos del servidor, un atacante podría a menudo acceder a información confidencial o privada mediante la especificación de la ruta de acceso de un archivo del servidor.

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 referencias directas a las expresiones de GitHub Actions en un script de ejecución se generan de forma dinámica. Esto permite que cualquiera que tenga el control de la entrada pueda comprometer el sistema mediante la inyección de comandos.

Ejemplo 1: El siguiente código de una GitHub Action hace referencia directa a una expresión en un script de ejecución que deja el sistema abierto para la inyección de comandos.

    ...
    steps:
      - run: echo "${{  github.event.pull_request.title  }}"
    ...
    

Cuando se ejecuta la acción, el script de shell se ejecuta de forma dinámica, incluido cualquier código que represente el valor github.event.pull_request.title. Si github.event.pull_request.title contiene código ejecutable malintencionado, la acción ejecuta el código malintencionado, lo que resulta en la inyección de comandos.

Los ataques de contaminación de parámetros de la cadena de conexión (CSPP) consisten en inyectar parámetros de la cadena de conexión en otros parámetros existentes. Esta vulnerabilidad es similar a otras vulnerabilidades, y quizás la más conocida, que se producen en entornos HTTP donde también se puede registrar contaminación de parámetros. Sin embargo, también se puede aplicar en otros lugares, como cadenas de conexión a base de datos. Si una aplicación no corrige adecuadamente la entrada del usuario, un usuario malintencionado puede poner en peligro la lógica de la aplicación para llevar a cabo ataques de robo de credenciales para recuperar la base de datos completa. Mediante el envío de parámetros adicionales a una aplicación y si estos parámetros tienen el mismo nombre que un parámetro existente, la conexión a la base de datos puede reaccionar de una de las siguientes maneras:

Solo puede obtener los datos del primer parámetro
Puede obtener los datos del último parámetro
Puede obtener los datos de todos los parámetros y concatenarlos juntos

Esto puede depender de la unidad utilizada, el tipo de base de datos o incluso cómo se utilizan las API.

Ejemplo 1: el código siguiente utilizan la entrada de una solicitud HTTP para conectarse a una base de datos:

      ...
      string password = Request.Form["db_pass"]; //gets POST parameter 'db_pass'
      SqlConnection DBconn = new SqlConnection("Data Source = myDataSource; Initial Catalog = db; User ID = myUsername; Password = " + password + ";");
      ...
    

En este ejemplo, el programador no ha considerado que un usuario malintencionado podría proporcionar un parámetro db_pass como:
"xxx; Integrated Security = true" la cadena de conexión se vuelve:

"Data Source = myDataSource; Initial Catalog = db; User ID = myUsername; Password = xxx; Integrated Security = true; "

Esto hará que la aplicación se conecte a la base de datos mediante la cuenta del sistema operativo bajo la cual se está ejecutando la aplicación para eludir la autenticación normal. Esto significaría que el usuario malintencionado podría conectarse a la base de datos sin una contraseña válida y realizar consultas a la base de datos directamente.

Las vulnerabilidades de inyección de cadenas de consulta se producen cuando:

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



2. Los datos se utilizan para crear de forma dinámica un URI de consulta de proveedor de contenidos.



Los proveedores de contenido para Android permiten a los desarrolladores escribir consultas sin SQL, simplemente generando URI de proveedor de contenido. Los URI de consultas de proveedor de contenido son vulnerables a los ataques de inyección, por lo que los desarrolladores deberían evitar el uso de cadenas concatenadas con entradas de datos contaminados para generar el URI si no se han asegurado antes de que los metacaracteres se han validado o codificado correctamente.

Ejemplo 1: en una aplicación que expone varios proveedores de contenido en URI:

content://my.authority/messagescontent://my.authority/messages/123content://my.authority/messages/deleted

Si los desarrolladores generan cadenas concatenadas de URI de consulta, los usuarios malintencionados podrán incluir en la ruta barras diagonales u otros metacaracteres de URI que cambiarán el significado de la consulta. En el siguiente fragmento de código, un atacante puede invocar a content://my.authority/messages/deleted proporcionando un código msgId con el valor deleted:

// "msgId" is submitted by users
Uri dataUri = Uri.parse(WeatherContentProvider.CONTENT_URI + "/" + msgId);
Cursor wCursor1 = getContentResolver().query(dataUri, null, null, null, null);

Las interfaces de programación de aplicaciones (API, Application Program Interface) de Flash ofrecen una interfaz para cargar archivos SWF remotos en el entorno de ejecución existente. A pesar de que la directiva entre dominios solo permite cargar archivos SWF desde una lista de dominios de confianza, es frecuente que la directiva entre dominios sea demasiado permisiva. Si se permite que la entrada del usuario, que no es de confianza defina qué archivos SWF de carga pueden causar que se haga referencia al contenido arbitrario y que posiblemente lo ejecute la aplicación de destino, teniendo como resultado un ataque flash de sitios.

Las vulnerabilidades flash de sitios se producen cuando:

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

2. Los datos se utilizan para cargar un archivo SWF remoto.
Ejemplo: El siguiente código utiliza el valor de uno de los parámetros para el archivo SWF cargado como la dirección URL desde donde cargar un archivo SWF remoto.

   ...
   var params:Object = LoaderInfo(this.root.loaderInfo).parameters;
   var url:String = String(params["url"]);
   var ldr:Loader = new Loader();
   var urlReq:URLRequest = new URLRequest(url);
   ldr.load(urlReq);
   ...

Las vulnerabilidades de Cross-Site Scripting (XSS) se producen cuando:

1. Los datos entran en una aplicación web a través de un origen no confiable. En el caso de XSS reflejado, el origen no confiable suele ser una solicitud web, mientras que en el caso de XSS persistente (también conocido como almacenado) suele ser una base de datos u otro almacén de datos back-end.


2. Los datos se incluyen en el contenido dinámico que se envía a un usuario web sin validación.

El contenido malintencionado que se envía al explorador web a menudo adopta la forma de un segmento de código JavaScript, pero también se puede presentar como HTML, Flash o cualquier otro tipo de código que el explorador ejecute. La variedad de los ataques basados en XSS es casi ilimitada, pero suelen incluir la transmisión al atacante de datos privados, como cookies u otra información de sesión, el redireccionamiento de la víctima a contenido web que el atacante controla u otras operaciones malintencionadas en el equipo del usuario bajo el disfraz de un sitio vulnerable.

Ejemplo 1: el siguiente segmento de código JSP lee un identificador de empleado, eid, a partir de una solicitud HTTP y lo muestra al usuario.

<% String eid = request.getParameter("eid"); %>
...
Employee ID: <%= eid %>

El código de este ejemplo funciona correctamente si eid contiene solo texto alfanumérico estándar. Si eid tiene un valor que incluye metacaracteres o código fuente, el explorador web ejecuta el código al tiempo que muestra la respuesta HTTP.

Esto podría no parecer inicialmente una vulnerabilidad. Después de todo, ¿por qué alguien escribiría una dirección URL que hiciese que el código malintencionado se ejecutase en su propio equipo? El peligro real es que un atacante creará la dirección URL malintencionada y, después, utilizará trucos de correo electrónico o de ingeniería social con el fin de atraer a las víctimas para que visiten un vínculo a la dirección URL. Cuando las víctimas hagan clic en el vínculo, sin darse cuenta reflejarán el contenido malintencionado a través de la aplicación web vulnerable en sus propios equipos. Este mecanismo de ataque a las aplicaciones web vulnerables se conoce como Reflected XSS.

Ejemplo 2: el siguiente segmento de código JSP consulta una base de datos en busca de un empleado con un identificador dado e imprime el nombre del empleado correspondiente.

<%...
Statement stmt = conn.createStatement();
ResultSet rs = stmt.executeQuery("select * from emp where id="+eid);
if (rs != null) {
   rs.next();
   String name = rs.getString("name");
}
%>

Employee Name: <%= name %>

Al igual que en el Example 1, este código funciona correctamente cuando los valores de name presentan un comportamiento correcto, pero no funciona para evitar ataques si no lo presentan. De nuevo, este código puede parecer menos peligroso, ya que el valor de name se lee de una base de datos con contenido aparentemente administrado por la aplicación. Sin embargo, si el valor de name se origina desde los datos que administró el usuario, la base de datos puede ser conductora de contenido malintencionado. Sin la validación de entrada adecuada en todos los datos almacenados en la base de datos, un atacante puede ejecutar comandos malintencionados en el explorador web del usuario. Este tipo de ataque, conocido como XSS persistente (o almacenado) es especialmente insidioso porque el direccionamiento indirecto causado por el almacén de datos hace que resulte más difícil identificar la amenaza y aumenta la posibilidad de que el ataque afecte a varios usuarios. XSS tiene su inicio en este formulario con los sitios web que ofrecen un "libro de visitas" a los visitantes. Los usuarios malintencionados incluyen JavaScript en las entradas del libro de visitas y todos los visitantes posteriores a la página del libro de visitas ejecutarían el código malintencionado.

Algunos piensan que en los entornos móviles las vulnerabilidades de las aplicaciones web clásicas como los scripts de sitios 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.

Example 3: The following code enables JavaScript in Android's WebView (by default, JavaScript is disabled) and loads a page based on the value received from an Android intent.

...
	WebView webview = (WebView) findViewById(R.id.webview);
  	webview.getSettings().setJavaScriptEnabled(true);
        String url = this.getIntent().getExtras().getString("url");
        webview.loadUrl(url);
...

Si el valor de url comienza por javascript:, el código JavaScript que sigue se ejecuta en el contexto de la página web dentro de WebView.

Como se muestra en los ejemplos, las vulnerabilidades XSS son causadas por código que incluye datos sin validar en la respuesta HTTP. Hay tres vectores, por los cuales un ataque XSS puede llegar a una víctima:

- Al igual que en el Example 1, los datos se leen directamente de la solicitud HTTP y se reflejan en la respuesta HTTP. Los ataques XSS reflejados se producen cuando un usuario malintencionado hace que un usuario proporcione contenido peligroso a una aplicación web vulnerable, lo que se reflejará en el usuario y que el explorador web ejecutará. El mecanismo más común para la entrega de contenido malintencionado es incluirlo como un parámetro en una dirección URL que se registra públicamente o se envía por correo electrónico directamente a las víctimas. Las direcciones URL creadas de esta manera constituyen el núcleo de muchas tramas de suplantación de identidad, mediante las cuales un usuario malintencionado convence a las víctimas para que visiten una dirección URL que hace referencia a un sitio vulnerable. Después de que el sitio refleja el contenido del atacante al usuario, se ejecuta el contenido y se continúa con la transferencia de información privada, como las cookies que pueden incluir información de la sesión, desde el equipo del usuario hacia el atacante, o se ejecutan otras actividades malintencionadas.

- Al igual que en el Example 2, la aplicación almacena datos peligrosos en una base de datos o en otro almacén de datos de confianza. Los datos peligrosos posteriormente se vuelven a leer en la aplicación y se incluyen en contenido dinámico. Los ataques XSS persistentes se producen cuando un usuario malintencionado inserta contenido peligroso en un almacén de datos que se lee posteriormente y se incluye en el contenido dinámico. Desde la perspectiva de un usuario malintencionado, el lugar óptimo para insertar contenido malintencionado es un área que se muestra a muchos usuarios o a usuarios particularmente interesantes. Los usuarios interesantes normalmente disponen de privilegios elevados en la aplicación o interactúan con información confidencial y valiosa para el usuario malintencionado. Si uno de estos usuarios ejecuta contenido malintencionado, el usuario malintencionado puede realizar operaciones con privilegios en nombre del usuario o tener acceso a datos confidenciales de este.

- Al igual que en el Example 3, una fuente externa a la aplicación almacena datos peligrosos en una base de datos u otro almacén de datos y, posteriormente, la aplicación lee los datos peligrosos como datos de confianza y los incluye en el contenido dinámico.

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.

Las vulnerabilidades Cross-Site Scripting (XSS) se producen cuando:

1. Los datos entran en una aplicación web a través de un origen no confiable. En el caso de Reflected XSS, el origen no confiable suele ser una solicitud web, mientras que en el caso de Persisted XSS (también conocido como Stored XSS) suele ser una base de datos u otro almacén de datos back-end.


2. Los datos se incluyen en el contenido dinámico que se envía a un usuario web sin validación.

El contenido malintencionado que se envía al explorador web a menudo adopta la forma de un segmento de código JavaScript, pero también se puede presentar como HTML, Flash o cualquier otro tipo de código que el explorador ejecute. La variedad de los ataques basados en XSS es casi ilimitada, pero suelen incluir la transmisión al atacante de datos privados, como cookies u otra información de sesión, el redireccionamiento de la víctima a contenido web que el atacante controla u otras operaciones malintencionadas en el equipo del usuario bajo el disfraz de un sitio vulnerable.

Para que el explorador represente la respuesta como HTML u otro documento que pueda ejecutar scripts, debe especificar un tipo de MIME text/html. Por lo tanto, un ataque XSS solo es posible si la respuesta usa este tipo de MIME o cualquier otro que también fuerce al explorador a representar la respuesta como HTML u otro documento que pueda ejecutar scripts, como imágenes SVG (image/svg+xml), documentos XML (application/xml), etc.

La mayoría de los exploradores modernos no representan el HTML ni ejecutan scripts cuando se proporcione una respuesta con tipos de MIME como application/octet-stream. Sin embargo, algunos exploradores como Internet Explorer realizan lo que se conoce como Content Sniffing. Content Sniffing consiste en ignorar el tipo de MIME proporcionado e intentar deducir el tipo de MIME correcto a partir del contenido de la respuesta.
Cabe destacar que un tipo de MIME de text/html es solo uno de los tipos de MIME que pueden generar vulnerabilidades a ataques XSS. Otros documentos que pueden ejecutar scripts, como las imágenes SVG (image/svg+xml) y los documentos XML (application/xml) entre otros, pueden provocar vulnerabilidades a ataques XSS con independencia de si el explorador realiza Content Sniffing.

Por lo tanto, una respuesta como <html><body><script>alert(1)</script></body></html> podría representarse como HTML aunque su encabezado content-type esté definido en application/octet-stream, multipart-mixed, etc.

Ejemplo 1: El siguiente método JAX-RS refleja los datos de usuario en una respuesta application/octet-stream.

@RestController
public class SomeResource {
    @RequestMapping(value = "/test", produces = {MediaType.APPLICATION_OCTET_STREAM_VALUE})
    public String response5(@RequestParam(value="name") String name){
        return name;
	}
}

Si un usuario malintencionado envía una solicitud con el parámetro name definido en <html><body><script>alert(1)</script></body></html>, el servidor produce la siguiente respuesta:

HTTP/1.1 200 OK
Content-Length: 51
Content-Type: application/octet-stream
Connection: Closed

<html><body><script>alert(1)</script></body></html>

Aunque la respuesta establece claramente que se debe tratar como un documento JSON, un explorador antiguo todavía podría intentar representarlo como documento HTML, por lo que sería vulnerable a un ataque Cross-Site Scripting.

Las vulnerabilidades de Cross-Site Scripting (XSS) se producen cuando:

1. Los datos entran en una aplicación web a través de un origen no confiable. En el caso de XSS basado en DOM, los datos se leen desde un parámetro de URL u otro valor dentro del explorador, y se escriben en la página con código del cliente. En el caso de XSS reflejado, el origen no confiable suele ser una solicitud web, mientras que en el caso de XSS persistente (también conocido como almacenado) suele ser una base de datos u otro almacén de datos back-end.


2. Los datos se incluyen en el contenido dinámico que se envía a un usuario web sin validación. En el caso de XSS basado en DOM, el contenido malintencionado se ejecuta como parte de la creación de DOM (Modelo de objetos de documento), siempre que el explorador de la víctima analice la página HTML.

El contenido malintencionado que se envía al explorador web a menudo adopta la forma de un segmento de código JavaScript, pero también se puede presentar como HTML, Flash o cualquier otro tipo de código que el explorador ejecute. La variedad de los ataques basados en XSS es casi ilimitada, pero suelen incluir la transmisión al atacante de datos privados, como cookies u otra información de sesión, el redireccionamiento de la víctima a contenido web que el atacante controla u otras operaciones malintencionadas en el equipo del usuario bajo el disfraz de un sitio vulnerable.

Ejemplo: El siguiente segmento de código JavaScript lee un ID de empleado, eid, a partir de una solicitud HTTP y se lo muestra en pantalla al usuario.

String queryString = Window.Location.getQueryString();
int pos = queryString.indexOf("eid=")+4;
HTML output = new HTML();
output.setHTML(queryString.substring(pos, queryString.length()));

El código de este ejemplo funciona correctamente si eid contiene solo texto alfanumérico estándar. Si eid tiene un valor que incluye metacaracteres o código fuente, el explorador web ejecuta el código al tiempo que muestra la respuesta HTTP.

Esto podría no parecer inicialmente una vulnerabilidad. Después de todo, ¿por qué alguien escribiría una dirección URL que hiciese que el código malintencionado se ejecutase en su propio equipo? El peligro real es que un atacante creará la dirección URL malintencionada y, después, utilizará trucos de correo electrónico o de ingeniería social con el fin de atraer a las víctimas para que visiten un vínculo a la dirección URL. Cuando las víctimas hagan clic en el vínculo, sin darse cuenta reflejarán el contenido malintencionado a través de la aplicación web vulnerable en sus propios equipos. Este mecanismo de ataque a las aplicaciones web vulnerables se conoce como Reflected XSS.


Como se muestra en el ejemplo, las vulnerabilidades XSS son causadas por código que incluye datos sin validar en la respuesta HTTP. Hay tres vectores, por los cuales un ataque XSS puede llegar a una víctima:

- Los datos se leen directamente de la solicitud HTTP y se reflejan en la respuesta HTTP. Los ataques XSS reflejados se producen cuando un usuario malintencionado hace que un usuario proporcione contenido peligroso a una aplicación web vulnerable, lo que se reflejará en el usuario y que el explorador web ejecutará. El mecanismo más común para la entrega de contenido malintencionado es incluirlo como un parámetro en una dirección URL que se registra públicamente o se envía por correo electrónico directamente a las víctimas. Las direcciones URL creadas de esta manera constituyen el núcleo de muchas tramas de suplantación de identidad, mediante las cuales un usuario malintencionado convence a las víctimas para que visiten una dirección URL que hace referencia a un sitio vulnerable. Después de que el sitio refleja el contenido del atacante al usuario, se ejecuta el contenido y se continúa con la transferencia de información privada, como las cookies que pueden incluir información de la sesión, desde el equipo del usuario hacia el atacante, o se ejecutan otras actividades malintencionadas.

- La aplicación almacena datos peligrosos en una base de datos o en otro almacén de datos de confianza. Los datos peligrosos posteriormente se vuelven a leer en la aplicación y se incluyen en contenido dinámico. Los ataques XSS persistentes se producen cuando un usuario malintencionado inserta contenido peligroso en un almacén de datos que se lee posteriormente y se incluye en el contenido dinámico. Desde la perspectiva de un usuario malintencionado, el lugar óptimo para insertar contenido malintencionado es un área que se muestra a muchos usuarios o a usuarios particularmente interesantes. Los usuarios interesantes normalmente disponen de privilegios elevados en la aplicación o interactúan con información confidencial y valiosa para el usuario malintencionado. Si uno de estos usuarios ejecuta contenido malintencionado, el usuario malintencionado puede realizar operaciones con privilegios en nombre del usuario o tener acceso a datos confidenciales de este.

- Una fuente externa a la aplicación almacena datos peligrosos en una base de datos u otro almacén de datos y posteriormente la aplicación lee los datos peligrosos como datos de confianza y los incluye en el contenido dinámico.