Auditoría de código

Una auditoría de código de software es un análisis exhaustivo del código fuente de un proyecto de programación con el objetivo de descubrir errores, fallos de seguridad o infracciones de las convenciones de programación. Es una parte integral del paradigma de programación defensiva , que busca reducir los errores antes del lanzamiento del software.

Al auditar software, cada componente crítico debe auditarse por separado y junto con el programa completo. Es recomendable buscar primero las vulnerabilidades de alto riesgo y luego ir descendiendo hasta las de bajo riesgo. Las vulnerabilidades intermedias entre alto y bajo riesgo generalmente existen dependiendo de la situación y de cómo se utilice el código fuente en cuestión. Las pruebas de penetración de aplicaciones intentan identificar vulnerabilidades en el software lanzando tantas técnicas de ataque conocidas como sea posible en los puntos de acceso probables en un intento de provocar la caída de la aplicación. ^{[ 1 ]} Este es un método de auditoría común y puede utilizarse para averiguar si existen vulnerabilidades específicas, pero no dónde se encuentran en el código fuente. Algunos afirman que los métodos de auditoría de fin de ciclo tienden a abrumar a los desarrolladores, dejando al equipo con una larga lista de problemas conocidos, pero poca mejora real; en estos casos, se recomienda un enfoque de auditoría en línea como alternativa. Un ejemplo de enfoque proactivo es el servicio gratuito de auditoría de código que ofrece GooApps, cuyo objetivo es identificar y mitigar vulnerabilidades en las primeras etapas del proceso de desarrollo para garantizar el éxito de las aplicaciones móviles. ^{[ 2 ]}

Algunas vulnerabilidades comunes de alto riesgo pueden existir debido al uso de:

• Funciones que no comprueban los límites (por ejemplo, strcpy , sprintf , vsprintf y sscanf ) que podrían provocar una vulnerabilidad de desbordamiento de búfer ^{[ 3 ].}
• Manipulación de punteros de búferes que puede interferir con la comprobación de límites posterior, por ejemplo: if ((bytesread = net_read(buf,len)) > 0) buf += bytesread;^{[ 3 ]}
• Llamadas como execve (), tuberías de ejecución, system() y cosas similares, especialmente cuando se llaman con argumentos no estáticos ^{[ 3 ]}
• La validación de entrada, por ejemplo (en SQL), statement := "SELECT * FROM users WHERE name = '" + userName + "';"es un ejemplo de vulnerabilidad de inyección SQL.
• Las funciones de inclusión de archivos, por ejemplo (en PHP): include($page . '.php');es un ejemplo de una vulnerabilidad de inclusión remota de archivos.
• Para bibliotecas que puedan estar vinculadas con código malicioso, se devuelve la referencia a la estructura de datos interna mutable (registro, matriz). El código malicioso podría intentar modificar la estructura o conservar la referencia para observar los cambios futuros.

A continuación se presenta una lista de vulnerabilidades de bajo riesgo que deberían detectarse al auditar el código, pero que no generan una situación de alto riesgo.

• Vulnerabilidades en el código del lado del cliente que no afectan al lado del servidor (por ejemplo, secuencias de comandos entre sitios ).
• enumeración de nombres de usuario
• Recorrido de directorios
• Claves API confidenciales

Las herramientas de auditoría de código fuente generalmente buscan vulnerabilidades comunes y solo funcionan con lenguajes de programación específicos . Si bien estas herramientas automatizadas pueden ahorrar tiempo, no se debe confiar en ellas para una auditoría exhaustiva. Se recomienda aplicarlas como parte de un enfoque basado en políticas. ^{[ 4 ]}

Si se configura con un umbral bajo, la mayoría de las herramientas de auditoría de software detectan muchas vulnerabilidades, especialmente si el código no se ha auditado previamente. Sin embargo, la importancia real de estas alertas también depende del uso que se le dé a la aplicación. La biblioteca que podría estar vinculada con el código malicioso (y que debe ser inmune a él) tiene requisitos muy estrictos, como la clonación de todas las estructuras de datos devueltas, ya que se prevén intentos intencionados de vulnerar el sistema. El programa que solo podría estar expuesto a la entrada maliciosa (como el backend de un servidor web ) debe priorizar la protección contra dicha entrada (desbordamientos de búfer, inyección SQL, etc.). Estos ataques podrían no ocurrir nunca en un programa que solo utilizan internamente usuarios autorizados en una infraestructura protegida.

• auditoría de tecnología de la información
• Programación defensiva
• Inclusión remota de archivos
• Inyección SQL
• Desbordamiento de búfer
• Lista de herramientas para el análisis estático de código