Auditoría de código - Code audit

Una auditoría de código de software es un análisis integral del código fuente en un proyecto de programación con la intención de descubrir errores, brechas de seguridad o violaciones de las convenciones de programación. Es una parte integral del paradigma de programación defensiva , que intenta reducir los errores antes de que se publique el software. El código fuente de C y C ++ es el código más común para ser auditado ya que muchos lenguajes de nivel superior, como Python, tienen menos funciones potencialmente vulnerables (por ejemplo, funciones que no verifican límites).

Pautas

Al auditar software, cada componente crítico debe auditarse por separado y junto con todo el programa. Es una buena idea buscar primero las vulnerabilidades de alto riesgo y trabajar hasta las de bajo riesgo. Las vulnerabilidades entre alto y bajo riesgo generalmente existen dependiendo de la situación y cómo se está utilizando el código fuente en cuestión. Las pruebas de penetración de aplicaciones intentan identificar vulnerabilidades en el software mediante el lanzamiento de tantas técnicas de ataque conocidas como sea posible en puntos de acceso probables en un intento de derribar la aplicación. Este es un método de auditoría común y se puede utilizar 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 pocas mejoras reales; en estos casos, se recomienda un enfoque de auditoría en línea como alternativa.

Vulnerabilidades de alto riesgo

Pueden existir algunas vulnerabilidades comunes de alto riesgo debido al uso de:

  • Funciones sin verificación de límites (p. Ej., Strcpy , sprintf , vsprintf y sscanf ) que podrían provocar una vulnerabilidad de desbordamiento del búfer
  • Manipulación de punteros de búferes que pueden interferir con la verificación de límites posterior, por ejemplo: if ((bytesread = net_read(buf,len)) > 0) buf += bytesread;
  • Llamadas como execve (), canalizaciones de ejecución, system () y cosas similares, especialmente cuando se llaman con argumentos no estáticos
  • Validación de entrada, por ejemplo (en SQL): statement := "SELECT * FROM users WHERE name = '" + userName + "';" es un ejemplo de una vulnerabilidad de inyección de SQL
  • 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 pueden estar vinculadas con código malicioso, devolver la referencia a la estructura interna de datos mutables (registro, matriz). El código malicioso puede intentar modificar la estructura o retener la referencia para observar los cambios futuros.

Vulnerabilidades de bajo riesgo

La siguiente es una lista de vulnerabilidades de bajo riesgo que se deben encontrar al auditar el código, pero que no producen una situación de alto riesgo.

  • Vulnerabilidades del código del lado del cliente que no afectan al lado del servidor (p. Ej., Secuencias de comandos entre sitios )
  • Enumeración de nombre de usuario
  • Cruce de directorio
  • Claves de API sensibles

Herramientas

Las herramientas de auditoría de código fuente generalmente buscan vulnerabilidades comunes y solo funcionan para lenguajes de programación específicos . Estas herramientas automatizadas podrían usarse para ahorrar tiempo, pero no se debe confiar en ellas para una auditoría en profundidad. Se recomienda aplicar estas herramientas como parte de un enfoque basado en políticas.

Dependencia de los requisitos

Si se establece en el umbral bajo, la mayoría de las herramientas de auditoría de software detectan muchas vulnerabilidades, especialmente si el código no ha sido auditado antes. Sin embargo, la importancia real de estas alertas también depende de cómo se utilice la aplicación. La biblioteca que puede estar vinculada con el código malicioso (y debe ser inmune a él) tiene requisitos muy estrictos como la clonación de todas las estructuras de datos devueltas, ya que se esperan intentos intencionales de romper el sistema. El programa que solo puede estar expuesto a la entrada maliciosa (como el backend del servidor web) primero debe preocuparse por esta entrada (saturación del búfer, inyección de SQL, etc.). Es posible que tales ataques nunca ocurran para el programa que solo es utilizado internamente por usuarios autorizados en una infraestructura protegida.

Ver también

Referencias