Los patrones de codificación deficientes pueden causar graves problemas de seguridad... entonces, ¿por qué los fomentamos?

Una versión de este artículo apareció en DZone. Ha sido actualizado y distribuido aquí.

‍

Durante lo que parece una eternidad a estas alturas, hemos hablado de "desplazarse a la izquierda" (shifting left) en el ciclo de vida de desarrollo de software (SDLC), teniendo en cuenta las mejores prácticas de seguridad desde el inicio del desarrollo. DevSecOps supuso un gran salto adelante, en gran parte debido al énfasis en la responsabilidad compartida de la seguridad y al poder de un desarrollador consciente de la seguridad para frustrar vulnerabilidades comunes mientras escribe código.

También sabemos, de nuevo desde hace eones, que el tipo de formación en código seguro que se elija para involucrar y capacitar a los desarrolladores marca la diferencia. Las soluciones de bajo esfuerzo motivadas únicamente por el cumplimiento normativo no fomentan las mentes brillantes de la seguridad del futuro, y la mayoría de los profesionales de concienciación sobre seguridad ya se han dado cuenta de ello. El aprendizaje dinámico y contextualmente relevante es lo mejor, pero es fundamental comprender los matices que conlleva.

Si queremos tener alguna posibilidad contra los actores de amenazas (quienes siempre llevan ventaja sobre una organización), los desarrolladores necesitan un entorno de formación integral, con un aprendizaje por capas que desarrolle continuamente habilidades basadas en las mejores prácticas.

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

Nuestro espíritu gira en torno a que el desarrollador sea fundamental en una estrategia de seguridad preventiva, desde el nivel del código hacia arriba. Eso es un hecho, y los desarrolladores con conocimientos de seguridad ofrecen el camino más sencillo para frustrar los tipos de errores de seguridad comunes que se manifiestan en patrones de codificación deficientes (como Log4Shell, por citar un ejemplo reciente y devastador).

Sin embargo, las técnicas defensivas que podemos emplear para capacitar a los desarrolladores varían, incluso si pueden coexistir en el mismo ámbito de formación.

Por ejemplo, imagine que le enseñaran a hornear un pastel usando solo instrucciones basadas en lo que no debe hacer. "No lo hornees demasiado" y "no olvides los huevos" deja mucho margen a la interpretación y una enorme posibilidad de cometer errores que darían un resultado digno de Nailed It!. Lo mismo ocurre con la educación en seguridad defensiva; lo que no se debe hacer es una parte muy limitada de la conversación y no ofrece consejos prácticos para actuar realmente con una mentalidad defensiva. Puede decirle a los desarrolladores: "no configures mal esa API", pero sin entender qué constituye una configuración correcta y segura, hay mucho margen para el error.

Los desarrolladores no tendrán un impacto positivo en la reducción de vulnerabilidades sin una comprensión fundamental de cómo funcionan estas, por qué son peligrosas, qué patrones las provocan y qué diseños o patrones de codificación las solucionan en un contexto que tenga sentido en su mundo. Un enfoque estructurado permite que las capas de conocimiento ofrezcan una visión completa de lo que significa programar de forma segura, defender una base de código y destacar como un desarrollador consciente de la seguridad. Y sí, parte de ese aprendizaje por capas debe dedicarse a la ofensiva y a comprender la mentalidad de un atacante; esto es fundamental para perfeccionar las habilidades de pensamiento lateral, que son invaluables en el modelado de amenazas y la estrategia defensiva.

Reforzar patrones de codificación deficientes es una trampa que no podemos ignorar.

Una realidad desafortunada de algunos métodos de aprendizaje para desarrolladores es que la parte "defensiva" (incluso cuando la formación está estructurada con técnicas ofensivas) puede reforzar malos hábitos, aunque técnicamente validen 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" sigue pareciendo estar sujeta a debate. La realidad es que el código inseguro no puede considerarse código de calidad, aunque sea funcional y estético. El problema es que el código seguro tampoco es intrínsecamente de alta calidad. En otras palabras, los patrones de codificación deficientes pueden solucionar un problema de seguridad, pero al hacerlo, introducir otro o, potencialmente, romper el software por completo.

Echemos un vistazo a un ejemplo de código de mala calidad en forma de una solución para una autenticación rota, así como la versión más segura siguiendo las mejores prácticas:

‍

using System;

using System.Collections.Generic;

using System.Linq;

using System.Threading.Tasks;

using Microsoft.AspNetCore.Authorization;

using Microsoft.AspNetCore.Http;

using Microsoft.AspNetCore.Mvc;

‍

namespace BadFixesAPI.Controllers

{

    [Route("api/[controller]")]

    [ApiController]

    public class AlertsController : ControllerBase

    {

        private DatabaseContext context = new DatabaseContext();

‍

        [HttpGet(Name = "GetAlerts")]

        // No garantiza que el usuario esté autenticado

        public IEnumerable<Alert> Get()

        {

            return context.GetAlerts();

        }

‍

        [HttpGet(Name = "GetAlerts")]

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

        [Authorize()]

        public IEnumerable<Alert> GetBadFix()

        {

            return context.GetAlerts();

        }

‍

        [HttpGet(Name = "GetAlerts")]

        // Asegura que el usuario esté autenticado Y que tenga el rol de "Administrador"

        [Authorize(Roles = "Administrator")]

        public IEnumerable<Alert> GetGoodFix()

        {

            return context.GetAlerts();

        }

    }

}

‍

En el primer fragmento, no hay ninguna verificación de autenticación del usuario, lo cual es extremadamente inseguro. El segundo, aunque mejora al incluir una comprobación de autenticación, no examina los roles asignados ni si los permisos son suficientes para la información solicitada. El tercero verifica tanto la autenticación del usuario como que tenga asignado el rol de "Administrador". En una era donde el control de acceso basado en el principio de menor privilegio debería ser la norma, es fundamental configurar y verificar los roles para garantizar que la información solo sea accesible bajo necesidad de conocer.

La prioridad principal de los desarrolladores es crear funcionalidades. Aunque la seguridad no se deja de lado intencionadamente, no siempre poseen las habilidades para evitar patrones de codificación deficientes que generan vulnerabilidades, y el estándar de un buen ingeniero rara vez incluye la destreza en codificación segura. Fomentamos indirectamente estos malos hábitos si las funcionalidades son lo suficientemente impresionantes, y es esta mentalidad la que debe cambiar. El problema es que algunas rutas de aprendizaje que fomentan la remediación práctica de código también pueden reforzar un código que es seguro, pero de calidad inferior. Al aplicar una evaluación binaria de "es seguro / no es seguro", en lugar de profundizar en si es realmente el mejor enfoque para resolver el error y mantener la integridad del software, se pasan por alto detalles cruciales.

Sin guiar a los desarrolladores a través 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. Imaginen si todos obtuviéramos nuestras licencias basándonos únicamente en nuestra capacidad para llegar a un destino; una calificación aprobatoria a pesar de habernos saltado semáforos en rojo, atravesado un seto y casi atropellar a un peatón. Completamos el objetivo, pero el camino que tomamos para llegar allí es lo que más importa.

Es necesario capacitar a los desarrolladores para que se preocupen más por crear software seguro.

El desarrollador moderno tiene muchas responsabilidades, por lo que no sorprende que encuentre aburrida la formación en seguridad, especialmente cuando no se implementa pensando en su jornada laboral y le resta tiempo a sus prioridades y plazos. También es injusto cambiar sus KPI para enfatizar la codificación segura cuando no cuentan con las habilidades desarrolladas mediante oportunidades de aprendizaje adecuadas y herramientas complementarias. Sin embargo, la importancia del desarrollo de software seguro es innegable, y lograr que los desarrolladores se comprometan con esto es crucial.

Como exdesarrollador, generalmente queremos hacer un gran trabajo, y ser vistos como superiores en cuanto a la calidad de nuestro trabajo es muy motivador. Incentivar a los desarrolladores a participar en el desarrollo continuo de habilidades de seguridad es lógico, y deberían ser recompensados por reconocer la importancia de la seguridad a nivel de código. Los programas de campeones de seguridad, los programas de recompensas por errores y los hackathons pueden ser excelentes oportunidades para construir una cultura de seguridad positiva, y quienes se involucren activamente deberían recibir su recompensa.