En .NET, puede utilizar la clase BinaryFormatter para convertir un objeto en una secuencia binaria que contiene tanto el objeto en sí como los metadatos necesarios para reconstruirlo durante la deserialización.

El uso de la clase BinaryFormatter puede generar escenarios de deserialización inseguros donde los atacantes pueden ejecutar código arbitrario, abusar de la lógica de la aplicación o desencadenar una condición de denegación de servicio.

El uso del tipo BinaryFormatter es peligroso y no se recomienda para el procesamiento de datos, ya que no se puede proteger.

Ejemplo 1: La aplicación permite el uso de la clase BinaryFormatter no segura estableciendo la propiedad de configuración EnableUnsafeBinaryFormatterSerialization a true en el archivo runtimeConfig.json.

...
AppContext.SetSwitch("System.Runtime.Serialization.EnableUnsafeBinaryFormatterSerialization", true);
...

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

No se recomienda a los desarrolladores crear las aplicaciones con API no documentadas u ocultas. No hay garantía de que Google no quite o cambie dichas API en el futuro y, por lo tanto, estas se deben evitar. También se debe evitar el uso de estos métodos o campos porque constituyen un riesgo y podrían dañar la aplicación.

El código intenta usar el objeto Camera una vez que se ha liberado. Todas las referencias adicionales al objeto Camera sin que se vuelva a adquirir el recurso generarán una excepción y pueden provocar que se bloquee la aplicación si no se detecta la excepción.

Ejemplo 1: El siguiente código utiliza un botón de conmutación para activar o desactivar la vista previa de la cámara. Después de que el usuario pulse el botón una vez, la vista previa de la cámara se detiene y el recurso de cámara se libera. Sin embargo, si este pulsa de nuevo el botón, se llamará a startPreview() en el objeto Camera liberado anteriormente.

public class ReuseCameraActivity extends Activity {
  private Camera cam;

  ...
  private class CameraButtonListener implements OnClickListener {
      public void onClick(View v) {
          if (toggle) {
              cam.stopPreview();
              cam.release();
          }
          else {
              cam.startPreview();
          }
          toggle = !toggle;
      }
  }
  ...
}

El código intenta usar el objeto multimedia una vez que se ha liberado. Todas las referencias adicionales al objeto multimedia sin que se vuelva a adquirir el recurso generarán una excepción y pueden provocar que se bloquee la aplicación si no se detecta la excepción.

Ejemplo 1: El siguiente código usa un botón de pausa para activar o desactivar la reproducción multimedia. Después de que el usuario pulse el botón una vez, la canción o el vídeo actuales se detendrán temporalmente y se liberará el recurso de cámara. Sin embargo, si este pulsa de nuevo el botón, se llamará a start() en el recurso multimedia liberado anteriormente.

public class ReuseMediaPlayerActivity extends Activity {
  private MediaPlayer mp;

  ...
  private class PauseButtonListener implements OnClickListener {
      public void onClick(View v) {
          if (paused) {
              mp.pause();
              mp.release();
          }
          else {
              mp.start();
          }
          paused = !paused;
      }
  }
  ...
}

El código intenta usar el controlador de base de datos SQLite de Android una vez que se ha cerrado. Todas las referencias adicionales al controlador sin que se restablezca la conexión a la base de datos generarán una excepción y pueden provocar que se bloquee la aplicación si no se detecta la excepción.

Ejemplo 1: El siguiente código puede proceder de un programa que almacena temporalmente valores de usuario en la memoria caché, pero puede llamar a flushUpdates() para confirmar los cambios en el disco. El método cierra correctamente el controlador de base de datos tras escribir las actualizaciones en la base de datos. Sin embargo, cuando se llama de nuevo a flushUpdates(), se hace referencia de nuevo al objeto de base de datos sin reinicializarlo.

public class ReuseDBActivity extends Activity {
  private myDBHelper dbHelper;
  private SQLiteDatabase db;

  @Override
  public void onCreate(Bundle state) {
      ...
      db = dbHelper.getWritableDatabase();
      ...
  }
  ...

  private void flushUpdates() {
      db.insert(cached_data);     // flush cached data
      dbHelper.close();
  }
  ...
}

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 vulnerabilidades de recorrido de ruta zip ocurren cuando un actor malintencionado puede especificar nombres de entradas de archivos zip en un archivo zip determinado. Cuando se especifica un nombre de entrada de archivo zip de forma maliciosa, un atacante puede sobrescribir el contenido de los archivos clave del sistema cuando se expande el archivo zip correspondiente. Los atacantes pueden usar expresiones de recorrido de ruta como ../ y / para acceder a archivos del sistema que de otro modo estarían fuera del alcance del programa. Las aplicaciones de Android que apuntan a Android 14 y versiones posteriores pueden, de forma predeterminada, generar una excepción cuando se detectan expresiones como ../ y / durante la extracción del archivo zip. Esta función de seguridad se puede anular o desactivar por completo.

Ejemplo 1: El siguiente código deshabilita la protección Zip Entry Overwrite.

...
dalvik.system.ZipPathValidator.clearCallback();
...

La minimización mejora los tiempos de carga de páginas para las aplicaciones que incluyen archivos JavaScript al reducir su tamaño. La minimización hace referencia al proceso de eliminación de espacios en blanco, comentarios, signos de punto y coma, y llaves acortando el nombre de las variables locales y eliminando código inaccesible.

Ejemplo 1: en el siguiente código ASPX se incluye la versión no minimizada de la biblioteca jQuery de Microsoft:

...
<script src="http://applicationserver.application.com/lib/jquery/jquery-1.4.2.js" type="text/javascript"></script>
...

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 1: 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 1: 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 1: 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 1: 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 1: 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 operaciones aritméticas no actúan del mismo modo en valores booleanos a como lo harían en valores integrales, lo que podría ocasionar un comportamiento inesperado.

Cuando los datos de una matriz de bytes se convierten en String, no se especifica lo que ocurrirá con los datos que quedan fuera del conjunto de caracteres correspondiente. Esto puede suponer una pérdida de datos o una disminución en el nivel de seguridad cuando se necesitan datos binarios para garantizar que se cumplen las medidas de seguridad apropiadas.

Ejemplo 1: el siguiente código convierte los datos en una cadena para crear un hash.

  ...
  FileInputStream fis = new FileInputStream(myFile);
  byte[] byteArr = byte[BUFSIZE];
  ...
  int count = fis.read(byteArr);
  ...
  String fileString = new String(byteArr);
  String fileSHA256Hex = DigestUtils.sha256Hex(fileString);
  // use fileSHA256Hex to validate file
  ...

Si el tamaño del archivo es menor que BUFSIZE, funcionará siempre y cuando la información de myFile se encuentre codificada igual que el conjunto de caracteres predeterminado. Sin embargo, si utiliza una codificación diferente o es un archivo binario, se perderá información. A su vez, esto provocará que el hash de SHA resultante no sea de confianza y que sea más fácil causar conflictos, especialmente si hay algún dato fuera del conjunto de caracteres predeterminado que se represente con el mismo valor, como un signo de interrogación.