Revisión de código seguro: Un enfoque práctico

Este artículo trata sobre diferentes técnicas de revisión de código y su aplicación en el mundo real

Lo que aprenderá:

Qué es la revisión de código seguro y cómo tratarlos en escenarios de la vida real

Lo que debe saber:

Conceptos básicos de seguridad

Revisión de código seguro:

La revisión de código seguro es un proceso que identifica la pieza de código insegura que puede causar una vulnerabilidad potencial en una etapa posterior del proceso de desarrollo de software, lo que en última instancia conduce a una aplicación insegura. Cuando se detecta una vulnerabilidad en etapas anteriores de SDLC, tiene menos impacto que las etapas posteriores de SDLC, cuando el código inseguro se mueve al entorno de producción. En el proceso SDLC (Ciclo de Vida de Desarrollo de Software), el proceso de revisión de código seguro entra en la Fase de desarrollo, lo que significa que cuando los desarrolladores están codificando la aplicación, pueden hacer una revisión de código propio o un analista de seguridad puede realizar la revisión de código, o ambas cosas. Los desarrolladores pueden utilizar herramientas automatizadas que se pueden integrar con su IDE (Eclipse, MS VS, etc.) y pueden hacer codificación y revisión de código simultáneamente. Después de eso, pueden tomar la ayuda de un experto en seguridad para identificar más fallas en el código, ya que los expertos en seguridad tienen una visión más intrínseca de los problemas de seguridad que los desarrolladores podrían pasar por alto.

Diferentes estudios y encuestas muestran que aproximadamente el 75% de los ataques ocurren debido a una aplicación insegura, dentro de la cual se incluye código inseguro. De esta manera, se convierte en una parte muy esencial del SDLC que debe realizarse rigurosamente. Los desarrolladores tienden principalmente a centrarse en la funcionalidad de la aplicación e ignorar el enfoque de codificación segura. Pero hoy en día se han vuelto más conscientes de la revisión de código debido al aumento de incidentes de piratería y ataques a servidores.

Gráfico– 1

Técnicas para asegurar la revisión del código:

En general, podemos dividir el proceso de revisión de código seguro en dos técnicas diferentes:

1. Basado en herramientas automatizadas / Caja negra: En este enfoque, la revisión de código seguro se realiza utilizando diferentes herramientas de código abierto / comerciales. La mayoría de los desarrolladores los usan mientras codifican, pero un analista de seguridad también puede tomar ayuda de ellos. Las herramientas son muy útiles al revisar el código cuando implementamos el proceso SDLC seguro en la organización y proporcionamos la herramienta a los propios desarrolladores para que realicen una revisión de “autocódigo” mientras codifican. Además, las herramientas son útiles para analizar bases de código grandes (millones de líneas). Pueden identificar rápidamente piezas de código potencialmente inseguras en la base de código, que pueden ser analizadas por el desarrollador o un analista de seguridad.
2. Manual / Caja Blanca: En esta técnica, se realiza una revisión exhaustiva del código sobre todo el código, lo que puede convertirse en un proceso muy tedioso y tedioso. Pero en este proceso, se pueden identificar fallas lógicas que pueden no ser posibles utilizando herramientas automatizadas, como los problemas de lógica de negocios. Las herramientas automatizadas son en su mayoría capaces de encontrar fallas técnicas, como ataques de inyección, pero pueden pasar por alto fallas como problemas de autorización. En este proceso, en lugar de ir línea por línea a través de toda la base de código, podemos concentrarnos en los problemas potenciales en el código. Esas vulnerabilidades potenciales pueden recibir una alta prioridad. Por ejemplo, en C / C++, si intentamos encontrar alguna función de copia en el código y comprobamos si está usando funciones como, strcpy() para realizar la función de copia. Como sabemos, se sabe que strcpy () es vulnerable a los ataques de desbordamiento de búfer. También es posible que queramos verificar si se está utilizando algún cifrado personalizado en la aplicación, qué herramientas automatizadas pueden fallar, ya que solo pueden identificar algoritmos estándar.

   Por lo tanto, el mejor enfoque será una mezcla de ambos, dependiendo del volumen y la criticidad de los datos. En el mundo actual, donde se desarrollan muchas aplicaciones complejas, no podemos ignorar ninguna de las técnicas mencionadas anteriormente.

Beneficios de la revisión segura de código:

Hay algunos factores que deben tenerse en cuenta al desarrollar un mecanismo robusto de control de acceso en la aplicación web:

1. Beneficio de esfuerzo: El esfuerzo para corregir las vulnerabilidades en la etapa anterior del proceso SDLC es mucho menor que en la etapa posterior del proceso. Una vez que el código está completo y el defecto no se identifica, es un proceso muy tedioso y lento encontrar problemas una vez que la aplicación está lista para entrar en producción. Además, la fijación de última hora puede afectar a toda la funcionalidad del programa y obstaculizar los plazos establecidos para el lanzamiento del producto. Quién sabe, puede crear otro defecto de seguridad, que puede ser fácilmente posible con un código grande y complejo.
2. Costo beneficio: El costo es directamente proporcional al esfuerzo requerido. No sólo el costo de desarrollo, sino también la vulnerabilidad detectada en el entorno de producción puede entrañar más costos. Una vez más, vale la pena, ya que los costos asociados con un ataque pueden ser mucho más elevados.
3. Cumplimiento: Algunos aspectos de cumplimiento, como PCI, hacen necesario realizar una revisión segura del código antes de lanzar el producto. Por lo tanto, una organización que sigue el SDLC completo tiene más posibilidades de obtener la certificación.
4. Reputación: La revisión de código seguro elimina la mayoría de los fallos de seguridad de la fase anterior, lo que lo hace más seguro que solo realizar evaluaciones de caja negra. Por lo tanto, hay menos posibilidades de que el producto se comprometa, por lo tanto, hay menos posibilidades de que se dañe la reputación.

Enfoque:

Estos se basan en una combinación de proceso estándar y mi propio enfoque. Puede variar de una persona a otra.

Proceso estándar :

Gráfico-2

Definir el alcance: En primer lugar, debe comprender y hacer una estimación aproximada del alcance de la revisión del código y los esfuerzos involucrados en ella. También se pueden definir restricciones presupuestarias. ¿Qué tipo de revisión de código se puede realizar? Black box o caja blanca? Tratar de entender la lógica de negocio de la aplicación. Recuerde qué vulnerabilidades necesita buscar, como OWASP Top 10, SANS, etc. Uno puede intentar revisarlas tanto como sea posible, si no todas. A continuación, puede deducir cuántos de ellos se pueden detectar utilizando herramientas y cuáles son los más adecuados para la revisión manual.

Categorice las vulnerabilidades: ¿Cuál es su prioridad, es decir, qué tipo de vulnerabilidades tomará como prioridad? Por ejemplo, en las aplicaciones de negocios, puede concentrarse principalmente en la lógica de negocios de la aplicación y profundizar en ella, ya que las herramientas detectan fácilmente las técnicas. Dar prioridad a ellos.

Las siguientes son algunas de las categorías que puede consultar:

• Autorización
• Autenticación
• Defectos de inyección
• Manejo incorrecto de errores/Defectos de excepción
• Cifrado (Criptografía)
• Auditoría y Registro
• Fallos relacionados con la sesión (Gestión de sesiones)
• Configuración insegura

Recomendación: Como analista de seguridad, es nuestro deber filtrar los falsos positivos generados por las herramientas y validarlos para confirmar que son defectos reales. Después de realizar una revisión de código adecuada, debe documentar las vulnerabilidades encontradas en un informe completo que cubra la categoría de la vulnerabilidad y su mitigación. Puede ir un paso adelante y sugerir un código seguro de muestra. Personalmente, también incluyo los fragmentos de código en el informe, preferiblemente en un archivo de Excel y luego los adjunto.

Así es como lo hago personalmente. Los puntos a continuación se basan en mi experiencia hasta la fecha en la revisión de código. Todavía tengo mucho que aprender y los puntos a continuación pueden o no ser válidos en todas las condiciones:

Realice siempre revisiones manuales: La revisión de código automatizada es un proceso en el que ejecuta las herramientas de escaneo como Rational, Ounce Labs y Parasoft En la base de código seguido de una auditoría manual de los resultados. El escáner marca todo el código con vulnerabilidades en función de su percepción. Ahora es el trabajo del auditor diferenciar entre problemas reales y falsos positivos. Aquí es donde comienza el verdadero dolor. No tienes dominio de todos y cada uno de los idiomas. Por lo tanto, se requiere la ayuda de recursos específicos del idioma. Ahora, me he familiarizado con casi todos los idiomas principales (.Vulnerabilidades específicas de NET, Java, PHP). Al hacer una evaluación de caja negra, nunca llegas a saber dónde está el verdadero problema.

Hable primero con los desarrolladores: Cuanto más involucre a los desarrolladores en el proceso de revisión de código, más efectivo será el análisis. Usted obtiene la confianza de que lo que está haciendo se basa en la comprensión correcta del código. Por otro lado, los desarrolladores también se alegran de que los esté tomando en confianza en lugar de declarar algo vulnerable de inmediato.

Tenga a mano un cuaderno y un bolígrafo para comprender el flujo del programa. Comprender el origen de la mancha y dónde se refleja en el código es necesario para detectar las vulnerabilidades reales. El solo hecho de ver que la mancha está entrando en el programa y reflejándose en alguna otra parte del programa no siempre significa que sea vulnerable a la creación de Scripts entre sitios, por ejemplo. De nuevo aquí, hablar con los desarrolladores ayuda, ya que podrían estar implementando algún mecanismo centralizado de filtrado/validación de entradas. Así que no saques conclusiones precipitadas.

Use un editor de texto avanzado: El editor de texto debe ser capaz de buscar un término en toda la base de código. Uno de estos editores de texto es Notepad++. Busca el término y lo resalta para que pueda ver dónde se usa el término en particular en todos los lugares. Te ayuda a unir las piezas y ver la imagen completa.

Tenga tiempo suficiente para revisar el código, ya que necesita aplicar sus pensamientos más de una vez para detectar vulnerabilidades reales. Por lo tanto, siempre pida a sus clientes el tiempo suficiente para completar el proyecto por completo.

Estar conectado a Internet siempre ayuda en el momento de revisar el código. Ciertos términos, funciones o métodos siempre te molestan, ya que es posible que no los hayas visto antes. Google ayuda mucho a entenderlos.

Buscar vulnerabilidades en el contexto de la aplicación: No solo debe detectar vulnerabilidades reales y aplicables en el contexto de la aplicación, ya que disminuye el número de problemas, sino que también debe proponer las contramedidas en el informe. Eso hace que los desarrolladores estén felices y confiados. El escáner puede marcar cualquier problema como Alto, Medio o Bajo. Es su responsabilidad darles una clasificación adecuada basada en el contexto de las aplicaciones.

Todo el mundo ama su propio programa: Los programas son como un bebé de desarrolladores. No siempre identifique las debilidades del programa, también las aprecie si encuentra algún mecanismo robusto utilizado en el programa. De esa manera, puede hacerlos amigables y siempre se usarán para revisar su código. Así que ambos son felices.

Entrenarlos: Por último, pero no menos importante, capacite a los desarrolladores sobre las vulnerabilidades en el mundo real. Dales formación, involúcralos y anímalos a revisar sus códigos antes de la producción. Dígales cómo ahorra esfuerzo y dinero. Si tiene una herramienta de escaneo que admite complementos para IDE, instálela en sus máquinas para que puedan realizar un desarrollo adecuado y una revisión manual.

Una Ilustración de Muestra:

Considere este ejemplo (Proyecto WebGoat de Owasp):

String username = “”;

Contraseña de cadena= “”;

username = s. getParser().getRawParameter (NOMBRE DE USUARIO);

password = s. getParser ().getRawParameter(CONTRASEÑA);

……………..

………..……

String query = ” SELECCIONE * DE LOS datos del sistema de usuario DONDE nombre_de_usuario = ‘”

+ nombre de usuario + “‘y contraseña = ‘” + contraseña + “‘”;

ec.addElement (nuevo StringElement (consulta));

Las entradas del usuario se solicitan a través de getRawParameter, y se asignan a las variables’ nombre de usuario ‘y’ contraseña’. Una vez más, se utilizan directamente en la consulta SQL sin ninguna validación de entrada y también se incrustan en la consulta dinámica. Cualquier usuario malicioso puede manipular esta consulta para ejecutar sus propios códigos SQL arbitrarios. Por lo tanto, si tratamos de encontrar todos los puntos de entrada en la base de código (getRawParameter en este caso), podemos detectar fallas de inyección. Incluso si buscamos consultas SQL que se están utilizando en el código, si encontramos que se están utilizando como consultas dinámicas, puede ser un caso de una posible inyección SQL.

En la Red: https://www.owasp.org/index.php/Category:OWASP_Code_Review_Project

https://www.owasp.org/images/2/2e/OWASP_Code_Review_Guide-V1_1.pdf