Enfoque de revisión de código estático

  

A) ¿Existe una ventaja / desventaja de realizar revisiones de   binarios sobre código fuente?

Los compiladores a menudo NO escriben código expresamente según lo previsto en la fuente. Por ejemplo, Return Oriented Programming explota el hecho de que los compiladores insertarán muchos más RET opcodes de los que el programador está consciente. Debido a la canalización y otros trucos de optimización, los compiladores esencialmente reescriben su código y posiblemente pueden agregar vulnerabilidades propias. ¡Esto significa que algunas construcciones en el código fuente pueden no expresarse en absoluto en el binario!

Esta es una clase de error que es esencialmente imposible para detectar mediante el análisis manual del código ... y sospecho que el riesgo todavía estaría allí para el código Java / C # JIT también, pero esto estar confuso de una herramienta de análisis estático.

El análisis manual del código fuente puede ayudar con el hecho de que la mayoría de las vulnerabilidades comunes pueden ser detectadas por inspección visual. Y tiene otros beneficios también, sobre todo en la reducción de la cantidad de bugs prod en general. (Y por lo tanto, el costo). Y también ayuda al aspecto social: las revisiones de fuentes alientan a las personas a escribir como si alguien más estuviera mirando. Una de las principales desventajas es que si está tratando con un lenguaje de tipo dinámico, como PERL, Groovy, LISP y sus derivados ... la mayoría de los datos no se verán hasta el tiempo de ejecución, lo que significa ninguno estático El análisis o el análisis del código fuente es suficiente.

Incluso puede engañar a las herramientas de análisis estático convirtiendo el código escrito de manera estática en instrucciones en tiempo de ejecución. ¿A Veracode no le gusta tu construcción Java? Vuelva a escribirlo con la reflexión, y el error Veracode desaparece y nadie es más sabio. Como experto en seguridad, también debe asumir que los programadores que trabajan en su propia empresa son una amenaza potencial.

En resumen, no hay forma de escapar del análisis del código fuente, el análisis estático y el análisis dinámico en una aplicación determinada si su esperanza es una base de código aceptablemente segura. *

  

B) Cuál proporciona más cobertura / vulnerabilidades.

El análisis del código fuente depende de que los revisores tengan excelentes habilidades de seguridad y, dado que son seres humanos, no se puede esperar razonablemente un rendimiento perfecto. Es por eso que las herramientas de análisis estático son útiles. Mi preferencia es ejecutar primero las herramientas de análisis estático y luego realizar las revisiones de código seguro después , se mitigan los descubrimientos. Prefiero usar STRIDE, pero hay otros marcos a considerar. Esto permite a los humanos concentrarse en los problemas de seguridad menos mundanos que están más relacionados con la lógica. Pero un ser humano inteligente vencerá a una herramienta de análisis estático tonto cualquier día de la semana.

El análisis de código fuente puede ayudarlo a encontrar dónde un programador dejó una puerta trasera ... las herramientas de análisis estático no están equipadas para manejar eso.

Entonces, la respuesta a esta pregunta es ... "depende". ¿Qué tipo de amenazas quieres dejar sin marcar?

* A menos que "aceptablemente seguro" se defina como dejar las ventanas abiertas y la puerta frontal desbloqueada.

Uno podría escribir libros sobre estas cosas y nunca estar satisfecho. Permítame intentar responder a esto en general, sin nombrar productos especiales.

Binary / Bytecode Analysis

Ventajas

• (en su mayoría) lenguaje de programación agnóstico
• Se puede ejecutar en binarios / bibliotecas de código cerrado que obtuviste de donde sea
• Puede encontrar fallas introducidas debido a errores del compilador (o comportamiento no definido del idioma de origen)

Desventajas

• a menudo es más difícil escribir / mantener debido a un hardware de rápida evolución (por ejemplo, es posible que aún no entienda Intel AVX)
• Limitado a ciertas arquitecturas (en la práctica, rara vez es un problema ya que la mayoría de las cosas se ejecutan en x86 / x86_64)
• Las construcciones de sincronización de subprocesos múltiples son difíciles de detectar, en todo caso.

Análisis de código fuente

Ventajas

• a menudo es más fácil rastrear las fallas encontradas en el código fuente real
• Por lo general, las herramientas permiten ver la "imagen más grande" de cómo funcionan mejor las cosas juntas (por ejemplo, las cosas asignadas aquí, desasignadas allí, la posibilidad de leer después de que sea gratis allí)
• Proporcionar análisis en un nivel semánticamente más alto (por ejemplo, un desbordamiento de enteros en algún cálculo que en el nivel de ensamblaje es un lío incomprensible de turnos y adiciones)
• La anotación del código fuente puede ayudar a la herramienta a comprender lo que está pasando (por ejemplo, "Confía en mí, esta es una primitiva de sincronización y, por lo tanto, lo siguiente es atómico, no hay que preocuparse por las condiciones de la raza")

Desventajas

• El código fuente debe estar disponible
• Es posible que no sea compatible con todo el lenguaje (por ejemplo, construcciones de metaprogramación de plantillas C ++)
• Es posible que no pueda simular con precisión las propiedades de la máquina y luego se ejecutarán (por ejemplo, el tamaño de los enteros, etc.)
• No desciende a las dependencias de la biblioteca, que pueden estar disponibles solo como binarios, o son diferentes en diferentes sistemas.

Nivel de cobertura

Esto es principalmente ortogonal a la forma en que opera la herramienta y es en gran medida una medida de la calidad de ese producto. Con el esfuerzo suficiente, todas las herramientas podrían implementar todas las comprobaciones para todo tipo de vulnerabilidades, pero nadie tiene suficiente mano de obra. Se harán cosas que son más fáciles de hacer; los que son difíciles de hacer nunca se pueden implementar.

Podría tener dos herramientas de análisis de código fuente que se centran en cosas totalmente diferentes (por ejemplo, una en condiciones de carrera y la otra en desbordamientos). Estoy seguro de que entre las herramientas siempre hay alguna superposición, pero no hay dos herramientas que encuentren exactamente el mismo tipo de fallas.

Si tiene la posibilidad, ejecute tantos como pueda, nunca sabrá si tiene un error en algún lugar que solo puede encontrar una de las herramientas que aún no ha ejecutado ...

La respuesta corta es usar ambos. Las pruebas de seguridad de aplicaciones híbridas o integradas (IAST) combinan las pruebas de seguridad de aplicaciones dinámicas (DAST) de binarios y códigos de bytes con las pruebas de seguridad de aplicaciones estáticas (SAST) para crear una vista unificada de las vulnerabilidades de una aplicación. El objetivo no es solo encontrar vulnerabilidades, sino también ayudar a los desarrolladores a identificar, interpretar y corregir rápidamente esos errores. Las herramientas híbridas van más allá del DAST y utilizan el análisis estático para señalar las líneas específicas del código fuente y extender la cobertura de la herramienta. Además, las herramientas IAST reducen los falsos positivos (la ruina de los desarrolladores de software) con pruebas en vivo de los resultados de SAST. IAST puede aprovechar las fortalezas de los métodos SAST y DAST y compensar las debilidades inherentes a cada una. Por ejemplo, las pruebas dinámicas de una inyección de SQL pueden confirmar que el ataque llegó a la base de datos. IAST acelera las pruebas al examinar el código para limitar la superficie de ataque; no hay necesidad de probar una página para la inyección de SQL si la página no hace ningún SQL. IAST puede emplear SAST para descubrir las superficies de ataque en un código que puede estar oculto a los métodos de prueba dinámicos.

Algunos ejemplos de herramientas IAST son Contraste de Aspect, Quotium Technologies ’, Appscan Enterprise de IBM, Acunetix Web Vulnerability Scanner y HP WebInspect Real-Time. Vea la publicación del blog de Jeff Williams en Por qué los escáneres de seguridad de aplicaciones estáticas solo no puedo cortarlo más Consulte la pregunta similar Eficacia de las pruebas de seguridad de aplicaciones interactivas

A) ¿Existe una ventaja / desventaja de realizar revisiones de binarios sobre el código fuente?

Normalmente "descompilo / desarmo" los binarios y los reviso en lugar del código fuente. A veces ni siquiera tengo acceso al código fuente. Podría haber diferentes "ramas" e incluso una fuente que nunca lo haga en el binario compilado (código muerto).

B) Cuál proporciona más cobertura / vulnerabilidades. El código fuente tiene sugerencias, como // TODO y comentarios que pueden ayudar si algo se necesita implementar / tiene puntos débiles. Los binarios no lo hacen. Ambos tienen méritos.