¿Es necesario ser un buen programador para realizar un análisis seguro del código fuente?

Depende de lo que se entiende por "análisis de código fuente seguro". Uno puede hacer cualquier cosa que uno quiera. El problema, supongo, es cuando alguien más ha pedido algo llamado "análisis seguro del código fuente", y uno se pregunta por qué uno no está calificado para ello.

En muchos casos, dicho análisis debe ser realizado por un Experto en la Materia (SME). En el producto final, una pyme entregará una declaración que básicamente dice "declaro que este código es seguro", con un entendimiento que es una declaración más profunda que "busqué un montón de patrones conocidos y no encontré problemas". / p>

Si estuviera interesado en la traducción auténtica de una filosofía china, ¿confiaría en una persona que sabía mucho de filosofía y tenía un montón de hojas de trucos para ayudar a descifrarla, pero en realidad no sabía chino?

Un gran ejemplo que viene a la mente es un error que afecta a un motor SQL. Perdóneme por no tener el nombre de qué motor, o qué versión para que pueda verificar, he tenido problemas para encontrarlo desde entonces. Sin embargo, el error fue conmovedor. El error estaba en el código que se veía así:

int storeDataInCircularBuffer(Buffer* dest, const char* src, size_t length)
{
    if (dest->putPtr + length < dest->putPtr)
        return ERROR; // prevent buffer overflow caused by overflow
    if (dest->putPtr + length > dest->endPtr) {
        ... // write the data in two parts
        return OK;
    } else {
        ... // write the data in one part
        return OK;
    }
}

Este código fue creado para formar parte de un búfer circular. En un búfer circular cuando llegas al final del búfer, te envuelves. A veces esto te obliga a dividir el mensaje entrante en dos partes, lo cual está bien. Sin embargo, en este programa SQL, estaban preocupados por el caso en el que length podría ser lo suficientemente grande como para provocar el desbordamiento de dest->putPtr + length , creando una oportunidad para un desbordamiento de búfer porque la siguiente verificación no funcionaría bien. Así que ponen en una prueba: if (dest->putPtr + length < dest->putPtr) . Su lógica era que la única forma en que esta afirmación podría ser cierta es si se produce un desbordamiento, por lo que detectamos el desbordamiento.

Esto creó un agujero de seguridad que realmente fue explotado, y tuvo que ser parchado. ¿Por qué? Bueno, sin que lo sepa el autor original, la especificación de C ++ declara que el desbordamiento de un puntero es un comportamiento indefinido, lo que significa que el compilador puede hacer lo que quiera. Como sucedió, cuando el autor original lo probó, gcc realmente emitió el código correcto. Sin embargo, unas pocas versiones más tarde, gcc tuvo optimizaciones para aprovechar esto. Vio que no había un comportamiento definido en el que esa declaración if pudiera pasar su prueba, y la optimizó!

Por lo tanto, para algunas versiones, las personas tenían servidores SQL que tenían un exploit, ¡aunque el código tenía controles explícitos para evitar dicho exploit!

Fundamentalmente, los lenguajes de programación son herramientas muy poderosas que pueden morder al desarrollador con facilidad. Analizar si esto ocurrirá requiere una base sólida en el idioma en cuestión.

(Edición: Greg Bacon fue lo suficientemente bueno como para desenterrar una advertencia del CERT sobre esto: Nota de vulnerabilidad VU # 162289 C los compiladores pueden descartar silenciosamente algunas comprobaciones envolventes. , y también esto relacionado. Gracias Greg!)

Creo que necesitas ser un buen programador para tener éxito, así que recomiendo que te conviertas en uno. Puede haber muchas cosas que su kit de herramientas / escáner no detecte. Honestamente, no recomiendo confiar completamente en las herramientas de escaneo de su código, ya que las vulnerabilidades cambian constantemente, y es posible que alguien haya codificado de manera que el escáner no pueda detectar las vulnerabilidades.

La capacidad de recorrer el código y ver cómo funciona, y cómo no debería funcionar, es fundamental para asegurar el desarrollo de software. Tener a un desarrollador al tanto de los problemas de seguridad es exactamente lo que quiere cuando se trata de producir un producto sólido, y exactamente lo que necesita durante una revisión del código.

Si bien, puede apuntar y hacer clic y verificar vulnerabilidades con sus escáneres y herramientas, no va a ser muy efectivo en el gran esquema de las cosas. ¿Sabe cuánto más efectivo sería si pudiera ver el código usted mismo y determinar si es bueno o malo? Waaaay mejor

No intentes pasar una revisión de código seguro si no sabes lo que estás haciendo, pero no abandones la idea si sientes que no estás en un punto en el que puedes hacer una Buena reseña. Recomiendo tratar de aprender creando sus propias revisiones de códigos de maquetas seguras, y repasarlo unas cuantas veces para asegurarse de que todo esté bien.

Pero aún así, definitivamente debes aprender no solo a codificar, sino también a codificar bien.

Es dudoso que un experto en seguridad sea eficaz para realizar el análisis del código fuente sin ser también un programador experto. Muchas vulnerabilidades son el resultado de prácticas de codificación técnica o sintáctica que son mal utilizadas de alguna manera menor. Un punto y coma faltante, un signo igual en lugar de un doble igual, un límite de matriz que se define doblemente en el primer día, pero una versión se modifica en la versión posterior, faltan corchetes, fallas de memoria, todo esto ha generado vulnerabilidades. Un desarrollador experimentado puede ver esto, pero un principiante probablemente no lo haría.

Lo que su experto en seguridad debería estar haciendo es alentar a los ingenieros a utilizar herramientas de escaneo automatizadas, como analizadores de código estático, comprobadores de fuzz y verificadores dinámicos de aplicaciones. Ayude a los equipos de ingeniería a comprender la validación de entradas, los ataques de inyección, los límites de confianza. Concienciarse de que los defectos de seguridad deben priorizarse adecuadamente y abordarse rápidamente. Programar y realizar pruebas de pluma. Y, lo que es más importante, haga que los ingenieros realicen revisiones de código del trabajo de cada uno.

Sí, el experto en seguridad debería poder leer el código, pero eso no significa que esté calificado para ser el árbitro de la seguridad del código.

Depende de tus expectativas. Las vulnerabilidades de seguridad causadas por problemas de diseño (es decir, falta la protección CSRF, solo la implementación rudimentaria de un protocolo, etc.) probablemente se pueden encontrar si el evaluador tiene un conocimiento profundo de los conceptos de seguridad, incluso si solo puede seguir el flujo de código sin tener un conocimiento más profundo del lenguaje de programación específico.

Pero los problemas de seguridad específicos del idioma, como los desbordamientos de búfer, los errores off-by-one, el manejo de Unicode o %code% , los problemas causados por el tamaño de los tipos de datos y los datos firmados o no firmados, etc. no se encontrarán si el comprobador tiene no hay un conocimiento más profundo del lenguaje, de las malas prácticas y de los patrones típicos de inseguridad específicos del lenguaje. Tome la historia de las vulnerabilidades de Java como ejemplo, donde ni los desarrolladores expertos de Java notaron los agujeros que perforaron en la caja de arena del lenguaje agregando reflexión al lenguaje y solo expertos externos con un profundo conocimiento de los idiomas internos detectó las fallas.

  

¿Es necesario ser un buen programador para realizar un análisis seguro del código fuente?

No.

  

¿Podrá realizar una revisión segura del código sin conocimiento de múltiples lenguajes de programación y dominio sobre ellos?

No.

En la programación hay más que experiencia en los detalles de cómo funcionan los distintos idiomas. Es una de las cosas que necesita para ser un buen programador, y también es una de las cosas que necesita para poder analizar el código fuente desde una perspectiva de seguridad (o cualquier otra calidad).

Entonces, si bien no necesita ser un buen programador, sí necesita dominar los idiomas involucrados.

La revisión segura del código no solo requiere el conocimiento del lenguaje de alto nivel, sino también las opciones del compilador y ¡CÓMO FUNCIONARÁ EL CÓDIGO EN LA CPU! Los lenguajes de alto nivel son eficientes para escribir código porque ocultan gran parte de la complejidad. Pero muchos errores y errores se esconden dentro de la complejidad. Como se señaló en otra respuesta, los compiladores intentan hacer lo correcto, pero realmente necesitas entender lo que está sucediendo al desensamblar el código y desarrollar una comprensión profunda de cómo funciona.

Este entendimiento también es necesario con lenguajes de script como JavaScript que interpretan el código de alto nivel a las instrucciones de la CPU y la asignación de memoria. Desafortunadamente, esta revisión dependería de la plataforma. Consulte, por ejemplo, en enlace .

Para resolver correctamente el peligro de los ataques de canal lateral, debe conocer el hardware. Hay ataques de canal lateral realmente feos, como ejecutar un proceso sin privilegios en una configuración de varias CPU en paralelo con uno privilegiado que realiza alguna tarea de cifrado / descifrado y el sondeo de qué líneas de caché compartidas se ensucian en qué tipo de patrón temporal o por cronometrando la entrega respectiva de secuencias de patrones específicos que se cifran.

Dado que los algoritmos de cifrado se encuentran bajo un intenso escrutinio de los matemáticos y otros teóricos, los ataques de canal lateral son formas cada vez más importantes de abrir el juego nuevamente. La desventaja es que deben diseñarse para una implementación, código y hardware en particular.