Las claves de cifrado mal administradas son la causa de distintos fallos de seguridad. Las organizaciones no deberían confiar en claves administradas por plataformas para recursos de datos críticos.

A menudo, no se tiene en cuenta que las copias de seguridad de datos son activos que requieren tanta protección como los datos originales.

Las copias de seguridad sin cifrar dejan los datos de la copia de seguridad accesibles ante posibles atacantes.

Por defecto, la configuración de copia de seguridad automatizada de máquinas virtuales de Azure SQL no aplica cifrado a las copias de seguridad de datos.

Ejemplo 1: El siguiente ejemplo muestra una configuración de Terraform que define una configuración de copia de seguridad automatizada de la máquina virtual de Azure SQL que no exige el cifrado de los datos de una copia de seguridad.

resource "azurerm_mssql_virtual_machine" "aztf009-tn-03" {
  virtual_machine_id               = data.azurerm_virtual_machine.example.id
  ...
  auto_backup {
    retention_period_in_days = 1
    storage_blob_endpoint = ""
    storage_account_access_key = azurerm_storage_account.example.primary_access_key
  }
}

Las claves de cifrado mal administradas son la causa de distintos fallos de seguridad. Las organizaciones no deberían confiar en claves administradas por plataformas para recursos de datos críticos.

Los errores de implementación, las configuraciones incorrectas y las claves comprometidas son algunos de los problemas que impiden que el cifrado de una sola capa proteja por completo los datos muy sensibles. Las organizaciones deben adoptar un enfoque de defensa en profundidad para proteger los datos muy sensibles y evitar tener un punto único de fallo en su diseño de seguridad.

Las claves de cifrado mal administradas son la causa de distintos fallos de seguridad. Las organizaciones no deberían confiar en claves administradas por plataformas para recursos de datos críticos.

Azure ofrece varias opciones de cifrado, cada una con ventajas y limitaciones concretas. Por ejemplo, el cifrado del lado del servidor (SSE) de Azure Storage realiza el cifrado por defecto sin utilizar recursos computacionales; sin embargo, no cifra el disco temporal ni las memorias caché. Tampoco protege los datos que fluyen desde una instancia informática al almacenamiento. Azure Disk Encryption (ADE) cifra tanto los discos temporales como las memorias cachés, así como los datos que fluyen hacia el almacenamiento, pero a expensas de los recursos computacionales.

Las claves de cifrado mal administradas son la causa de distintos fallos de seguridad. Las organizaciones no deberían confiar en claves administradas por plataformas para recursos de datos críticos.

Los mecanismos de autenticación débiles exponen a las organizaciones a accesos no autorizados.

Los mecanismos de autenticación pueden fallar por varias razones, tales como:
- Contraseñas débiles
- Validación incorrecta
- Gestión de credenciales débil

Los mecanismos de autenticación débiles exponen a las organizaciones a accesos no autorizados.

Los mecanismos de autenticación pueden fallar por varias razones, tales como:
- Contraseñas débiles
- Validación incorrecta
- Gestión de credenciales débil

Los mecanismos de autenticación débiles exponen a las organizaciones a accesos no autorizados.

Los mecanismos de autenticación pueden fallar por varias razones, tales como:
- Contraseñas débiles
- Validación incorrecta
- Gestión de credenciales débil

Los mecanismos de autenticación débiles exponen a las organizaciones a accesos no autorizados.

Los mecanismos de autenticación pueden fallar por varias razones, tales como:
- Contraseñas débiles
- Validación incorrecta
- Gestión de credenciales débil

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

La autenticación basada en Touch ID puede implementarse de dos formas diferentes: mediante el marco de trabajo LocalAuthentication o mediante el uso de controles de accesos basados en Touch ID en el servicio de llaves.

Si bien ambas deberían ser lo suficientemente seguras para la mayoría de las aplicaciones, el enfoque de LocalAuthentication tiene algunas características que lo hacen menos adecuado para las aplicaciones de mayor riesgo, como las de los sectores bancario, sanitario y asegurador:

- LocalAuthentication se define fuera de la zona segura del dispositivo, lo que implica que sus API pueden enlazarse y modificarse en dispositivos liberados.
- LocalAuthentication autentica al usuario mediante la evaluación de la directiva de contexto, que solo puede evaluar como true o false. Esta evaluación booleana implica que la aplicación no podrá saber a quién se está autenticando en realidad, solo si se usó, o no, la huella digital que está registrada en el dispositivo. Además, las huellas digitales que podrían registrarse en el futuro también se evaluarán correctamente como true.


Ejemplo 1: el siguiente código usa el marco de trabajo LocalAuthentication para realizar la autenticación del usuario:

    ...
    LAContext *context = [[LAContext alloc] init];  
    NSError *error = nil;  
    NSString *reason = @"Please authenticate using the Touch ID sensor.";
    
    if ([context canEvaluatePolicy:LAPolicyDeviceOwnerAuthenticationWithBiometrics error:&error]) {  
        [context evaluatePolicy:LAPolicyDeviceOwnerAuthenticationWithBiometrics
            localizedReason:reason
                reply:^(BOOL success, NSError *error) {
                    if (success) {
                        // Fingerprint was authenticated
                    } else {
                        // Fingerprint could not be authenticated
                    }
            }
        ];
    ...

La autenticación basada en Touch ID puede implementarse con los servicios de llaves mediante el almacenamiento de un elemento en las llaves y la configuración de un control de accesos que requiera que el usuario utilice su huella digital para recuperar el elemento más tarde. Las siguientes directivas pueden usarse para definir cómo se autenticará al usuario con su huella digital:

- kSecAccessControlUserPresence: restricción de acceso con Touch ID o un código de acceso. No es necesario que Touch ID esté disponible o registrado. Touch ID puede tener acceso al elemento aunque se agreguen o eliminen huellas digitales.
- kSecAccessControlTouchIDAny: restricción de acceso con Touch ID para las huellas digitales registradas. No se invalida el elemento si se agregan o eliminan huellas digitales.
- kSecAccessControlTouchIDCurrentSet: restricción de acceso con Touch ID para las huellas digitales registradas actualmente. Se invalida el elemento si se agregan o eliminan huellas digitales.

Cuando usa Touch ID, debe utilizar el atributo kSecAccessControlTouchIDCurrentSet para impedir que se agreguen o eliminen huellas digitales en el futuro.

Ejemplo 1: el siguiente código usa la restricción kSecAccessControlTouchIDAny que permite que el elemento de las llaves se desbloquee con cualquier huella digital que se registre en el futuro:

    ...
    SecAccessControlRef sacRef = SecAccessControlCreateWithFlags(kCFAllocatorDefault,
                 kSecAttrAccessibleWhenPasscodeSetThisDeviceOnly,
                 kSecAccessControlTouchIDCurrentSet, 
                 nil);
    NSMutableDictionary *dict = [NSMutableDictionary dictionary];
    [dict setObject:(__bridge id)kSecClassGenericPassword forKey:(__bridge id) kSecClass];
    [dict setObject:account forKey:(__bridge id)kSecAttrAccount];
    [dict setObject:service forKey:(__bridge id) kSecAttrService];
    [dict setObject:token forKey:(__bridge id)kSecValueData];
    ...
    [dict setObject:sacRef forKey:(__bridge id)kSecAttrAccessControl];
    [dict setObject:@"Please authenticate using the Touch ID sensor." forKey:(__bridge id)kSecUseOperationPrompt];

    dispatch_async(dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_DEFAULT, 0), ^{
        OSStatus status = SecItemAdd((__bridge CFDictionaryRef)dict, nil);
    });
    ...

De acuerdo con las directivas de Apple, la aplicación siempre debe explicar a los usuarios por qué se requieren sus huellas digitales. En caso contrario, puede confundirse al usuario o incluso hacer que la aplicación se rechace en AppStore.

Ejemplo 1: el siguiente código usa Touch ID para autenticar al usuario, pero no proporciona un motivo localizado que explique por qué se requiere la autenticación:

    [context evaluatePolicy:LAPolicyDeviceOwnerAuthenticationWithBiometrics localizedReason:nil
        reply:^(BOOL success, NSError *error) {
            if (success) {
                NSLog(@"Auth was OK");
            } 
    }];

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