Según mi información, no existe una regla estricta y rápida para realizar una revisión del código de seguridad, pero todos desarrollamos nuestra propia estrategia para la misma. Me preguntaba si todos podemos compartir las diferentes estrategias involucradas o utilizadas en la revisión del código de seguridad.
Como mencionó @sonofaaa, en el libro "El arte de la evaluación de seguridad del software", los autores analizan las estrategias de auditoría de código en el Capítulo 4 (al final de la Parte I).
En particular, se discuten la sensibilidad del flujo externo (flujo de datos y flujo de control) y la dirección de rastreo (rebanado hacia adelante o hacia atrás) junto con muchos métodos neutros de revisión. Otros temas se discuten con gran detalle. Es el mejor material escrito sobre el tema de revisión de código seguro.
También debería mencionar "Programación segura con análisis estático", un libro de Brian Chess y Jacob West de Fortify Software. Cubren los elementos internos y el uso de herramientas de análisis estático centradas en la seguridad y las comparan con otras formas / herramientas en el mundo de la revisión segura de códigos.
Si desea revisar los analizadores estáticos modernos centrados en la seguridad, le sugiero que primero se involucre con algunas herramientas de código abierto o gratuitas, como CAT.NET para .NET (normalmente C #, VB.NET y / o ASP.NET), find-sec-bugs (o el antiguo LAPSE +) para Java Enterprise y JSP, y RIPS Scanner para PHP Normalmente no encontrará analizadores estáticos centrados en la seguridad que admitan lenguajes dinámicos, ya que no dependen de un sistema de tipo, pero me avisan si está interesado en la compatibilidad con Python, Ruby u otro lenguaje dinámico (o cualquier otro). idioma) y trataré de señalarte en la dirección correcta. Para empezar, prueba Bandit (proyecto OpenStack para código Python) y Brakeman Pro para Ruby.
Los analizadores estáticos centrados en la seguridad comercial están destinados a desarrolladores altamente capacitados y especializados orientados a la seguridad de aplicaciones. El costo de ellos supone que alguien ejecutará y analizará estas herramientas diariamente, como un trabajo de tiempo completo, durante todo el año. Si está interesado en ver resultados rápidos, consulte HPFOD - pero si está interesado en integrar estas herramientas a largo plazo, El portafolio de aplicaciones en riesgo para una instalación grande: visite Cigital ESP . También hay muchas boutiques de seguridad de aplicaciones y tiendas de consultoría que ejecutan y ajustan estas herramientas para sus clientes. Dependiendo de su ubicación y dirección estratégica, elegiría asociarme con uno, independientemente de cualquier otra cosa que mencione, ya que pueden ser invaluables para el éxito de un programa appsec. La búsqueda en LinkedIn de "consultoría de seguridad de aplicaciones" debería funcionar si no sabe dónde ir a continuación.
Generalmente comienzo con una lista de verificación. Diga el top 10 de OWASP o las pautas de codificación del CERT C (o la sección en mi propio libro). Solicito al equipo que evalúe el código en relación con la lista de verificación, y que también realice pruebas y revisiones no dirigidas. los problemas "populares" de la revisión abierta se agregan a la lista de verificación, reemplazando los problemas que estaban allí originalmente.
Además, las herramientas de análisis estático se utilizan cuando están disponibles.
El beneficio de este enfoque es también su mayor inconveniente. Los problemas de la lista de verificación se detectan fácilmente, pero a menudo son los únicos problemas encontrados, ya que la búsqueda creativa de errores no es fácil.
Contrariamente a su declaración, creo que la revisión del código (de seguridad) no debería ser una actividad principalmente ad-hoc. Existen algunas metodologías bastante sólidas para realizar una revisión de código eficiente . Para obtener los mejores resultados, esto debe hacerse de manera incremental e iterativa.
Aquí hay una muestra de un esquema de alto nivel de tal metodología, con algunos principios rectores:
La Parte I de TAOSSA cubre varios enfoques y escenarios híbridos, y Brandon Edwards hace un gran trabajo revisando las estrategias de revisión agnóstica de la tecnología y las trampas comunes de las grandes revisiones en los videos aquí (http://pentest.cryptocity.net/code- auditorias /)
Algunas metodologías pueden diferir ligeramente según lo que esté auditando: para aplicaciones web puede ser una, para aplicaciones C / C ++, otra. Además, depende de si el código fuente está disponible. Pero, en general, implica las siguientes etapas:
Durante este proceso se utilizan analizadores de códigos estáticos o dinámicos. Cuál de los dos depende de ti, los enlaces que te di podrían ayudarte.
Sin embargo, muy a menudo usted tiene que verificar el software que fue auditado previamente por usted, luego puede hacer su trabajo más fácil. Para el código fuente, puede usar WinMerge , que le permitiría encontrar diferencias entre la versión anterior y la nueva. Para binario puede usar Darungrim , BinDiff .
Los temas que podrían tener sentido leer sobre la pregunta actual se pueden encontrar aquí:
Lea otras preguntas en las etiquetas appsec code-review manual-review