La programación defensiva es una forma de diseño defensivo destinada a desarrollar programas capaces de detectar posibles anomalías de seguridad y dar respuestas predeterminadas. [1] Garantiza el funcionamiento continuo de un software en circunstancias imprevistas. Las prácticas de programación defensiva se utilizan a menudo cuando se necesita alta disponibilidad , seguridad o protección .
La programación defensiva es un enfoque para mejorar el software y el código fuente , en términos de:
Sin embargo, una programación excesivamente defensiva puede proteger contra errores que nunca se producirán, lo que generará costos de tiempo de ejecución y mantenimiento.
La programación segura es el subconjunto de la programación defensiva que se ocupa de la seguridad informática . La seguridad es lo que interesa, no necesariamente la seguridad o la disponibilidad (se puede permitir que el software falle de determinadas maneras). Como ocurre con todos los tipos de programación defensiva, evitar los errores es un objetivo principal; sin embargo, la motivación no es tanto reducir la probabilidad de fallos en el funcionamiento normal (como si la seguridad fuera la preocupación), sino reducir la superficie de ataque: el programador debe asumir que el software podría utilizarse de forma indebida para revelar errores y que estos podrían explotarse de forma maliciosa.
int risky_programming ( char * entrada ) { char str [ 1000 ]; // ... strcpy ( str , entrada ); // Copiar entrada. // ... } La función tendrá un comportamiento indefinido cuando la entrada supere los 1000 caracteres. Es posible que algunos programadores no consideren que esto sea un problema, suponiendo que ningún usuario ingresará una entrada tan larga. Este error en particular demuestra una vulnerabilidad que permite explotar el desbordamiento del búfer . A continuación, se muestra una solución para este ejemplo:
int secure_programming ( char * input ) { char str [ 1000 + 1 ]; // Uno más para el carácter nulo. // ... // Copiar la entrada sin exceder la longitud del destino. strncpy ( str , input , sizeof ( str )); // Si strlen(input) >= sizeof(str) entonces strncpy no terminará en nulo. // Contrarrestamos esto estableciendo siempre el último carácter en el buffer en NUL, // recortando efectivamente la cadena a la longitud máxima que podemos manejar. // También se puede decidir abortar explícitamente el programa si strlen(input) es // demasiado largo. str [ sizeof ( str ) - 1 ] = '\0' ; // ... }La programación ofensiva es una categoría de programación defensiva, con el énfasis añadido de que ciertos errores no deben manejarse defensivamente . En esta práctica, solo se deben manejar los errores que están fuera del control del programa (como la entrada del usuario); en esta metodología , se debe confiar en el software en sí, así como en los datos dentro de la línea de defensa del programa .
const char * nombre_color_semáforo ( enum color_semáforo c ) { switch ( c ) { case SEMÁFORO_ROJO : return "rojo" ; case SEMÁFORO_AMARILLO : return "amarillo" ; case SEMÁFORO_VERDE : return "verde" ; } return "negro" ; // Se manejará como un semáforo muerto. // Advertencia: Esta última declaración 'return' será descartada por un compilador optimizador // si todos los valores posibles de 'color_semáforo' están listados en // la declaración 'switch' anterior... } const char * Trafficlight_colorname ( enum Trafficlight_color c ) { switch ( c ) { case TRAFFICLIGHT_RED : return "red" ; case TRAFFICLIGHT_YELLOW : return "yellow" ; case TRAFFICLIGHT_GREEN : return "green" ; } assert ( 0 ); // Afirma que esta sección es inalcanzable. // Advertencia: Esta llamada a la función 'assert' será descartada por un compilador optimizador // si todos los valores posibles de 'traffic_light_color' están listados en // la declaración 'switch' anterior... } if ( is_legacy_compatible ( user_config )) { // Estrategia: No confíe en que el nuevo código se comporte de la misma manera que old_code ( user_config ); } else { // Alternativa: No confíe en que el nuevo código maneje los mismos casos if ( new_code ( user_config ) != OK ) { old_code ( user_config ); } } // Espere que el nuevo código no tenga errores nuevos if ( new_code ( user_config ) != OK ) { // Informe en voz alta y finalice abruptamente el programa para obtener la atención adecuada report_error ( "Algo salió muy mal" ); exit ( -1 ); } A continuación se presentan algunas técnicas de programación defensiva:
Si se prueba el código existente y se sabe que funciona, reutilizarlo puede reducir la posibilidad de que se introduzcan errores.
Sin embargo, la reutilización de código no siempre es una buena práctica. La reutilización de código existente, especialmente cuando se distribuye ampliamente, puede permitir la creación de vulnerabilidades dirigidas a un público más amplio de lo que sería posible de otro modo y conlleva toda la seguridad y las vulnerabilidades del código reutilizado.
Al considerar el uso de código fuente existente, una revisión rápida de los módulos (subsecciones como clases o funciones) ayudará a eliminar o a que el desarrollador esté al tanto de cualquier vulnerabilidad potencial y garantizará que sea adecuado para su uso en el proyecto. [ cita requerida ]
Antes de reutilizar código fuente antiguo, bibliotecas, API, configuraciones, etc., se debe considerar si el trabajo antiguo es válido para su reutilización o si es probable que sea propenso a problemas heredados .
Los problemas heredados son problemas inherentes cuando se espera que los diseños antiguos funcionen con los requisitos actuales, especialmente cuando los diseños antiguos no se desarrollaron ni probaron con esos requisitos en mente.
Muchos productos de software han experimentado problemas con el código fuente heredado antiguo; por ejemplo:
Ejemplos notables del problema del legado:
Es probable que los usuarios malintencionados inventen nuevos tipos de representaciones de datos incorrectos. Por ejemplo, si un programa intenta rechazar el acceso al archivo "/etc/ passwd ", un pirata informático podría pasar otra variante de este nombre de archivo, como "/etc/./passwd". Se pueden emplear bibliotecas de canonización para evitar errores debido a entradas no canónicas .
Supongamos que las construcciones de código que parecen ser propensas a problemas (similares a vulnerabilidades conocidas, etc.) son errores y posibles fallas de seguridad. La regla básica es: "No estoy al tanto de todos los tipos de vulnerabilidades de seguridad . Debo protegerme contra aquellas que conozco y luego debo ser proactivo".
getsnunca se deben usar ya que el tamaño máximo del búfer de entrada no se pasa como argumento. Las funciones de la biblioteca de C como scanfse pueden usar de forma segura, pero requieren que el programador tenga cuidado con la selección de cadenas de formato seguro, depurándolas antes de usarlas.Estas tres reglas sobre seguridad de datos describen cómo manejar cualquier dato, de origen interno o externo:
Todos los datos son importantes hasta que se demuestre lo contrario , lo que significa que todos los datos deben verificarse como basura antes de ser destruidos.
Todos los datos están contaminados hasta que se demuestre lo contrario , lo que significa que todos los datos deben manejarse de una manera que no exponga el resto del entorno de ejecución sin verificar su integridad.
Todo código es inseguro hasta que se demuestre lo contrario . Si bien es un nombre ligeramente inapropiado, es un buen trabajo recordarnos que nunca debemos asumir que nuestro código es seguro, ya que los errores o el comportamiento indefinido pueden exponer el proyecto o sistema a ataques como los ataques de inyección SQL comunes .