Auditoría de código de una aplicación
Enviado por Unirs • 30 de Abril de 2023 • Trabajo • 3.736 Palabras (15 Páginas) • 113 Visitas
Desarrollo Seguro de Software y Auditoría
Por:
Actividad I. Auditoría de código de una aplicación
[pic 1]
Bogotá D.C
02 FEBRERO 2023
1. INTRODUCCIÓN
Estamos en una época donde el ciclo de vida del software cada vez requiere menores tiempos de desarrollo , mayor calidad , más tiempo de vida en producción y una seguridad confiable , Es aquí donde el S-SDLC (Ciclo de Vida de Desarrollo de un Sistema- Seguro) (Owasp, 2023) nos brinda las herramientas y conceptos para cumplir con estas premisas , En el siguiente laboratorio vamos a realizar el análisis estático el cual nos permite escudriñar el código en fases tempranas de desarrollo sin necesidad de que este funcional o en producción lo cual si sería una condición para las pruebas dinámicas, Gracias al análisis estático podremos identificar alertas en el código. Alertas que se clasifican en verdaderos positivos, falsos positivos y falsos negativos los cuales permiten retroalimentar al desarrollador y llevarlo a revisar las alertas que podrían convertirse en vulnerabilidades de seguridad en el proyecto a futuro.
2. DESARROLLO
Para el siguiente laboratorio se utilizó el programa Fortify Audit Workbench (MicroFocus, 2023) en su versión 21.2.1.0004 distribuido por la empresa Micro Focus el cual nos permite analizar el código de forma estática e identificar y clasificar los diferentes tipos de alertas de manera automática (Ver imagen 1).
[pic 2]
Imagen 1.Análisis Dinámico Herramienta Fortify Audit Workbench.
Para esta práctica se analizó 15 diferentes tipos de alertas en la herramienta según los códigos CWE (MITRE, 2023) los cuales nos permiten enumerar posibles debilidades para clasificarlas en los siguientes cuadros de informe:
Alerta #1 | file_io_ansi.c:63 (Shared Sink) (Critical) |
Código CWE | CWE 22: Limitación incorrecta de un nombre de ruta a un directorio restringido ('Path Traversal') |
Tipo de alerta | Falso Positivo |
Código Fuente | *fd = fopen(pathname, mode);
|
Diagrama | [pic 3] |
Advertencia | Los atacantes pueden controlar el argumento de la ruta del sistema de archivos para fopen() en file_io_ansi.c línea 63, lo que les permite acceder o modificar archivos protegidos. |
Impacto | 3.0 |
Probabilidad | 3.2 |
Gravedad | 3.0 |
Confianza | 5.0 |
Recomendación | Se está realizando una validación de entrada adecuada, lo que genero el falso positivo, es decir, advertencias que no tienen consecuencias de seguridad ni requieren cambios en el código. if (*fd == NULL) return PJ_RETURN_OS_ERROR(errno); |
Alerta #2 | httpdemo.c:168 (Path Manipulation) (Critical) |
Código CWE | CWE 73: Control externo de nombre de archivo o ruta |
Tipo de alerta | Verdadero Positivo |
Código Fuente | f = fopen(argv[2], "wb"); |
Diagrama | [pic 4] |
Advertencia | Los atacantes pueden controlar el argumento de la ruta del sistema de archivos para fopen () en httpdemo.c línea 168, lo que les permite acceder o modificar archivos protegidos de otro modo. |
Impacto | 3.0 |
Probabilidad | 3.2 |
Gravedad | 3.0 |
Confianza | 5.0 |
Recomendación | La mejor manera de evitar la manipulación de rutas es con un nivel de direccionamiento indirecto: cree una lista de nombres de recursos legítimos que un usuario pueda especificar y solo permita que el usuario seleccione de la lista. Con este enfoque, la entrada proporcionada por el usuario nunca se usa directamente para especificar el nombre del recurso. |
Alerta #3 | file_io_ansi.c:103 (Buffer Overflow) (Critical) |
Código CWE | CWE-129: Validación incorrecta del índice de matriz |
Tipo de alerta | Verdadero Positivo |
Código Fuente | bytes = fread(data, 1, *size, (FILE*)fd); |
Diagrama | [pic 5] |
Advertencia | La función pj_file_read() en file_io_ansi.c podría escribir fuera de los límites de la memoria asignada en la línea 103, lo que podría corromper los datos, hacer que el programa se bloquee o provocar la ejecución de código malicioso. |
Impacto | 5.0 |
Probabilidad | 3.2 |
Gravedad | 4.0 |
Confianza | 5.0 |
Recomendación | Nunca use funciones intrínsecamente inseguras, como gets(), y evite el uso de funciones que son difíciles de usar de manera segura, como strcpy(). Reemplace las funciones ilimitadas como strcpy() con sus equivalentes limitados, como strncpy() o las funciones WinAPI definidas en strsafe.h Si bien el uso cuidadoso de las funciones limitadas puede reducir en gran medida el riesgo de desbordamiento de búfer, esta migración no se puede realizar a ciegas y no es suficiente por sí sola para garantizar la seguridad. |
...