Los patrones de codificación deficientes pueden provocar grandes problemas de seguridad... entonces, ¿por qué los alentamos?

Una versión de este artículo apareció en Zona D. Se ha actualizado y distribuido aquí.

‍

Durante lo que parece una eternidad en este momento, hemos hablado de «cambiar a la izquierda» en el SDLC, teniendo en cuenta las mejores prácticas de seguridad desde el principio del desarrollo del software. DevSecOps supuso un gran paso adelante, en gran parte debido al énfasis que se hacía en la responsabilidad compartida en materia de seguridad y a la capacidad de un desarrollador preocupado por la seguridad para contrarrestar las vulnerabilidades más comunes mientras escribía código.

También sabemos, una vez más, desde hace eones, que el tipo de formación en código seguro elegido para atraer y mejorar las habilidades de los desarrolladores marca la diferencia. Las soluciones que requieren poco esfuerzo y motivadas únicamente por el cumplimiento de la normativa no ayudan a las mentes brillantes del futuro en materia de seguridad, y la mayoría de los profesionales que se preocupan por la seguridad lo han conseguido. Lo mejor es un aprendizaje dinámico y relevante desde el punto de vista del contexto, pero es fundamental que se comprendan los matices internos.

Si queremos tener una oportunidad de luchar contra los actores de amenazas, y ellos siempre tener una ventaja en una organización: los desarrolladores necesitan un entorno de formación holístico, con un aprendizaje por capas que desarrolle continuamente habilidades basadas en las mejores prácticas.

Las medidas de seguridad defensivas impulsadas por los desarrolladores no son una victoria automática.

Nuestro espíritu gira en torno a que el desarrollador sea fundamental para una estrategia de seguridad preventiva, desde el nivel del código hacia arriba. Eso es un hecho, y los desarrolladores expertos en seguridad son la forma más fácil de evitar los tipos de errores de seguridad más comunes que aparecen en los patrones de codificación deficientes (como Log4Shell, como un ejemplo reciente y devastador).

Sin embargo, las técnicas defensivas que podemos utilizar para mejorar las habilidades de los desarrolladores varían, incluso si pueden existir correctamente en el mismo grupo de entrenamiento.

Por ejemplo, imagina que te dicen cómo hornear un pastel, usando solo instrucciones basadas en lo que no debes hacer. «No lo hornee en exceso» y «no olvide los huevos» deja el tema abierto a la interpretación y existe un enorme potencial de errores que harán que el resultado final sea adecuado ¡Lo logré!. Lo mismo ocurre con la educación en seguridad defensiva; ¿qué? no hacer es una parte muy limitada de la conversación y no ofrece consejos prácticos para actuar realmente con una mentalidad defensiva. Puedes decirles a los desarrolladores que «no configuren mal esa API», pero si no entienden lo que constituye una configuración correcta y segura, hay mucho margen de error.

Los desarrolladores no tendrán un impacto positivo en la reducción de vulnerabilidades sin una comprensión básica de cómo funcionan las vulnerabilidades, por qué son peligrosas, qué patrones las causan y qué patrones de diseño o codificación las arreglan en un contexto que tenga sentido en su mundo. A enfoque andamiado permite que los niveles de conocimiento brinden una imagen completa de lo que significa programar de forma segura, defender una base de código y posicionarse como desarrollador consciente de la seguridad. Y sí, parte de ese aprendizaje escalonado debería dedicarse a la ofensiva y a comprender la mentalidad del atacante; esto es fundamental para perfeccionar las habilidades de pensamiento lateral, que son invaluables a la hora de modelar amenazas y de estrategia defensiva.

Reforzar los patrones de codificación deficientes es un escollo que no podemos ignorar.

Una desafortunada realidad con algunos métodos de aprendizaje para desarrolladores es que la parte «defensiva», incluso cuando el entrenamiento está estructurado con técnicas ofensivas, puede reforzar los malos hábitos, incluso si están validando técnicamente la seguridad del código.

La producción de código de alta calidad debería ser la base de todo desarrollo de software, pero la definición de «calidad» todavía parece estar en debate. La realidad es que el código inseguro no puede considerarse código de calidad, aunque por lo demás sea funcional y atractivo. El truco es que seguro el código no es intrínsecamente de alta calidad, ya sea. En otras palabras, los patrones de codificación deficientes pueden solucionar un problema de seguridad, pero al hacerlo, introducir otro o, potencialmente, dañar el software por completo.

Veamos un ejemplo de código de mala calidad en la forma de una solución para una autenticación fallida, así como la versión más segura para seguir las mejores prácticas:

‍

uso del sistema;

utilizando System.Collections.Generic;

usando System.Linq;

utilizando System.Threading.Tasks;

utilizando Microsoft.AspNetCore.Authorization;

utilizando Microsoft.AspNetCore.HTTP;

utilizando Microsoft.AspNetCore.Mvc;

‍

El espacio de nombres corrige mal API.Controllers

{

[Ruta («api/ [controlador]»)]

[Controlador API]

clase pública AlertsController: ControllerBase

{

contexto privado de DatabaseContext = nuevo DatabaseContext ();

‍

[HttpGet (Nombre = «GetAlerts»)]

//No garantiza que el usuario esté autenticado

<Alert>público IEnumerable Get ()

{

devuelve Context.getAlerts ();

}

‍

[HttpGet (Nombre = «GetAlerts»)]

//Garantiza que el usuario esté autenticado, pero no comprueba ningún rol

[Autorizar ()]

<Alert>public IEnumerable getBadfix ()

{

devuelve Context.getAlerts ();

}

‍

[HttpGet (Nombre = «GetAlerts»)]

//Garantiza que el usuario esté autenticado y que tenga la función de «administrador»

[Autorizar (roles = «Administrador»)]

<Alert>public IEnumerable getGoodFix ()

{

devuelve Context.getAlerts ();

}

}

}

‍

En el primer fragmento, no hay ninguna comprobación para comprobar que el usuario está autenticado, lo que es lo más inseguro posible. El segundo, si bien es mejor en cuanto a realizar una comprobación de autenticación, no investiga las funciones asignadas ni si los permisos son lo suficientemente altos para la información solicitada. La tercera comprueba la autenticación de ambos usuarios y que se les asigna la función de «administrador». En una era en la que el control de acceso con privilegios mínimos debería ser la norma en la mayoría de los casos, es fundamental que las funciones se configuren y comprueben para garantizar que solo se pueda acceder a la información cuando sea necesario.

La máxima prioridad para los desarrolladores es crear funciones y, aunque la seguridad no pasa a un segundo plano intencionadamente, no tienen necesariamente las habilidades necesarias para evitar patrones de codificación deficientes que provocan errores de seguridad, y el punto de referencia de un buen ingeniero rara vez incluye la destreza en la codificación segura. Fomentamos indirectamente esos malos hábitos si las funciones son lo suficientemente buenas, y es esta mentalidad la que tiene que cambiar. El problema es que la forma en que algunas rutas de aprendizaje fomentan la corrección práctica del código también refuerza potencialmente el código que es seguro, pero de calidad inferior. Al aplicar una valoración binaria de tipo «sí, esto es seguro y no, esto no es seguro», en lugar de analizar más a fondo si realmente es el mejor enfoque para resolver el error y mantener la integridad del software, hay problemas en los detalles que pasan desapercibidos.

Sin llevar a los desarrolladores a lo largo de todo el proceso para obtener una visión completa de la codificación segura, este enfoque perpetúa los mismos problemas que intenta resolver. Imagínese si todos obtuviéramos nuestras licencias basándonos únicamente en nuestra capacidad para conducir un vehículo hasta un destino; una marca de paso aunque hayamos pasado un semáforo en rojo, hayamos atravesado un seto y hayamos perdido por poco a un peatón que cruzaba la calle para llegar allí. Cumplimos la meta, pero el viaje que hicimos para llegar allí es lo más importante.

Los desarrolladores deben poder preocuparse más por la creación de software seguro.

El desarrollador moderno tiene que seguir dando vueltas, y no es de extrañar que la formación en seguridad le resulte aburrida, especialmente cuando no se implementa teniendo en cuenta su jornada laboral y los aleja de sus plazos y prioridades. También es totalmente injusto cambiar sus indicadores clave de rendimiento para hacer hincapié en la codificación segura, cuando no tienen las habilidades adquiridas gracias a las oportunidades de aprendizaje habituales y adecuadas y a la utilización de herramientas complementarias. Sin embargo, no se puede exagerar la importancia de un desarrollo de software seguro, y conseguir que los desarrolladores estén de acuerdo con esto es crucial.

Como antiguo desarrollador, por lo general, quiero hacer un gran trabajo, y ser visto por encima de los demás en términos de producción de calidad es muy motivador. Incentivar a los desarrolladores para que se dediquen al desarrollo continuo de sus habilidades de seguridad es una obviedad, y se les debe recompensar por reconocer la importancia de la seguridad a nivel de código. Los programas de promoción de la seguridad, las recompensas por errores y los hackatones pueden ser excelentes oportunidades para crear una cultura de seguridad positiva, y quienes se pongan manos a la obra deberían llevarse el botín.