Tengo un código base que necesita una revisión de código para evaluarlo en las puertas traseras.
El código es demasiado grande para revisarlo todo, ¿cómo recomendaría abordar el problema?
Es una aplicación web java con una base de datos de Oracle, el código se personaliza desde un producto que es extremadamente grande.
Las personalizaciones cubren casi todo el código base, pero puedo identificar el código personalizado automáticamente.
Comenzaría con una descripción general estructural: desde una perspectiva de diseño, ¿están bien definidas las partes separadas del código? por ejemplo, ¿tiene un código de validación, funciones de entrada y salida, etc., que se utilizan para esos fines en todo el código base, o cada función es individual? ¿Tiene un código que sea funcionalmente seguro (a menudo ciertas construcciones de estilo no afectan la seguridad del flujo de datos)
Si tiene un envoltorio de seguridad que lleva a cabo la autenticación para cada función, es posible que pueda revisar estas funciones y simplemente verificar el uso de la función de envoltorio, por ejemplo.
Si es una base de código muy grande, entonces querrá ejecutar una herramienta como Fortify (u otras que @AviD podrá nombrar :-) para hacer una primera pasada al problema, pero todas las herramientas sufren una falta de inteligencia de contexto. Se identifican en base a firmas típicas, por lo que obtendrá falsos puntos positivos (y posiblemente falsos negativos, razón por la cual tener una buena descripción general puede ayudarlo a identificar los riesgos que una herramienta no detectará)
La idea es que la herramienta reduzca las posibles áreas de riesgo e identifique la gran mayoría de los problemas, ya que las herramientas son relativamente baratas, luego un ser humano valida y agrega a la salida de la herramienta, colocándola en el contexto del entorno de la aplicación.
A riesgo de parecer demasiado comercial, aconsejaría utilizar los servicios de un consultor de seguridad con experiencia que no solo conoce la herramienta de revisión de código y domina Java + Oracle, sino también alguien con experiencia en arquitectura empresarial basada en riesgos de seguridad.
La última línea: estás atornillado. Si le preocupa que uno de los desarrolladores haya ocultado deliberadamente una puerta trasera en esa base de código, no tiene una esperanza realista de saber si una puerta trasera está presente. La vida apesta.
Comentario: Algunas personas aquí están sugiriendo que puedes verificar si hay una puerta trasera revisando el código, usando herramientas de análisis estático, o algo así. No lo creas Se engañan a sí mismos si piensan que es probable que esto detecte una puerta trasera deliberadamente oculta. En mi opinión, esas respuestas son demasiado optimistas y es probable que le den una falsa sensación de seguridad. (Sé que me voy a volver impopular al decir esto y disuadir a otros comentaristas, pero me siento responsable de darte mi sincero y sincero consejo).
Consejos y mitigaciones: En cuanto a lo que debe hacer, creo que necesita contarnos más sobre la función de esa pieza de software, cómo se relaciona con su negocio y cuáles son las consecuencias. Si tiene una puerta trasera. Aquí hay algunas mitigaciones genéricas que podría considerar, que podrían o no ser relevantes para usted, dependiendo de las circunstancias:
Transferencia de riesgo. Requiera que el proveedor proporcione una garantía de que el código está libre de puertas traseras, con las principales cláusulas de penalización financiera si se encuentra alguna. (Tenga en cuenta que, si está presente una puerta trasera, es probable que las probabilidades sean bastante bajas, por lo que las penalizaciones, si se encuentran, se deben aumentar proporcionalmente a la inversa de la probabilidad de detectarla).
Aislamiento. Podría intentar aislar el efecto de una puerta trasera, de modo que solo pueda afectar el funcionamiento de esta pieza de software y tenga una oportunidad limitada de atacar otros sistemas suyos. Puede ejecutarlo en una máquina virtual, apagarlo desde sus redes, etc. Es posible que también lo pueda apagar desde la red, para que sea más difícil para un malo activar la puerta trasera.
Monitoreo. En algunos casos, puede ser posible realizar un monitoreo externo para detectar actividad ilícita. Por ejemplo, en una articulación de máquinas tragamonedas, puede controlar la cantidad de dinero que se recibe, la cantidad pagada y, estadísticamente, esos dos deben tener una relación sólida; Si ve pagos que exceden la cantidad esperada por más de cinco desviaciones estándar, esa podría ser una buena razón para preocuparse. Como otro ejemplo, en un banco, puede utilizar la contabilidad de doble entrada y realizar un seguimiento de algunas métricas agregadas, como la tasa de quejas de los consumidores y la frecuencia con la que los consumidores disputan los cargos. Este tipo de técnicas de monitoreo son altamente específicas para su negocio en particular, pero potencialmente pueden ser efectivas para detectar chanchullos.
Tenga en cuenta que es probable que ninguno de estos ofrezca una defensa realmente buena contra las puertas traseras deliberadas, y que pueden ser aplicables o no en cualquier situación particular, pero si tiene suerte, podrían ser mejores que nada.
@Rory cubrió bastante cómo hacer la revisión ...
Simplemente agregaré que debes saber lo que estás buscando, y no solo "puerta trasera" en general (similar a lo que @ VP01 dijo en su comentario en la parte superior).
Por ejemplo, estás buscando puertas traseras que hacen:
Si sabe qué tipos de puertas traseras está buscando, no tiene que concentrarse por igual en cada una de las millones de líneas de código, y puede establecer prioridades.
También agregaré que hay algunas herramientas automatizadas que se pueden escribir de manera muy rica, de modo que es compatible con la búsqueda de esos tipos específicos de las puertas traseras que defina, según la inteligencia y el contexto humanos. luego aplica eso a lo largo de los millones de LOC ...
P.S. Es posible que le interesen algunas de estas preguntas relacionadas:
Creo que la respuesta de Rory toca el núcleo, pero el momento es realmente importante aquí. Para hacer la revisión del código después de que el código ya sea enorme, mal documentado, mal probado, en producción (no sé si ese es el caso aquí) ya es casi "demasiado tarde" para hacerlo bien. Incluso con las mejores herramientas y los analistas externos de Java / Oracle será más difícil de entender las fallas de la lógica de negocios (intencionalmente plantadas allí). En mi opinión, el análisis del código desde el principio es el camino a seguir.
Hay algunos métodos que son comunes a cada revisión de aplicación, independientemente del idioma que se use. Aquí hay algunos consejos:
Lea otras preguntas en las etiquetas audit code-review