De mauvais schémas de codage peuvent entraîner de graves problèmes de sécurité... alors pourquoi les encourager ?

Une version de cet article a été publiée dans DZone. Elle a été mise à jour et publiée ici.

‍

Pendant ce qui semble être une éternité, nous avons discuté du "déplacement vers la gauche" dans le SDLC, en prenant en compte les meilleures pratiques de sécurité dès le début du développement du logiciel. DevSecOps a été un grand pas en avant, en grande partie parce qu'il met l'accent sur le partage des responsabilités en matière de sécurité et sur la capacité d'un développeur sensibilisé à la sécurité à déjouer les vulnérabilités courantes au fur et à mesure qu'il écrit le code. 

Nous savons également - là encore, depuis des lustres - que le type de formation au code sécurisé choisi pour impliquer et perfectionner les développeurs fait toute la différence. Les solutions à faible effort motivées uniquement par la conformité réglementaire ne permettent pas de former les brillants esprits de sécurité de demain, et la plupart des professionnels de la sensibilisation à la sécurité l'ont compris. Un apprentissage dynamique et adapté au contexte est préférable, mais il est essentiel de comprendre les nuances qu'il comporte. 

Si nous voulons avoir une chance de nous battre contre les acteurs de la menace - et ils ont toujours une longueur d'avance sur une organisation - les développeurs ont besoin d'un environnement de formation holistique, avec un apprentissage en couches qui renforce continuellement les compétences ancrées dans les meilleures pratiques.

Les mesures de sécurité défensives prises par les développeurs ne sont pas automatiquement gagnantes.

Notre philosophie repose sur le fait que le développeur est au cœur d'une stratégie de sécurité préventive, dès le niveau du code. C'est une évidence, et les développeurs compétents en matière de sécurité constituent la voie la plus facile pour contrecarrer les types de bogues de sécurité courants qui sont apparents dans les modèles de codage médiocres (comme Log4Shell, qui est un exemple récent et dévastateur).

Cependant, les techniques défensives que nous pouvons utiliser pour améliorer les compétences des développeurs varient, même si elles peuvent à juste titre exister dans le même panier de formation. 

Imaginez, par exemple, que l'on vous dise comment faire un gâteau, en utilisant uniquement des instructions basées sur ce qu'il ne faut pas faire. "Ne pas trop le cuire" et "ne pas oublier les œufs" laissent place à l'interprétation et à un énorme potentiel d'erreurs qui donneront un résultat final digne d'un gâteau. C'est raté !. Il en va de même pour l'éducation à la sécurité défensive ; ce qu'il ne faut pas faire est une partie très limitée de la conversation, et n'offre aucun conseil pratique pour agir véritablement avec un état d'esprit défensif. Vous pouvez dire aux développeurs "ne configurez pas mal cette API", mais si vous ne comprenez pas ce qu'est une configuration correcte et sûre, il y a beaucoup de place pour l'erreur.

Les développeurs n'auront pas d'impact positif sur la réduction des vulnérabilités sans une compréhension fondamentale du fonctionnement des vulnérabilités, de la raison pour laquelle elles sont dangereuses, des modèles qui les causent et des modèles de conception ou de codage qui les corrigent dans un contexte qui a du sens dans leur monde. Une approche par échafaudage permet aux couches de connaissances de donner une image complète de ce que signifie coder en toute sécurité, défendre une base de code et se tenir debout en tant que développeur conscient de la sécurité. Et oui, une partie de cet apprentissage en couches doit être consacrée à l'offensive et à la compréhension de l'état d'esprit d'un attaquant ; c'est essentiel pour affiner les compétences de pensée latérale, qui sont inestimables dans la modélisation des menaces et la stratégie défensive. 

Renforcer les mauvaises habitudes de codage est un piège que nous ne pouvons pas ignorer.

Malheureusement, certaines méthodes de formation des développeurs ont pour effet que la partie "défensive" - même lorsque la formation est structurée avec des techniques offensives - peut renforcer les mauvaises habitudes, même si elles valident techniquement la sécurité du code. 

La production d'un code de haute qualité devrait être la base de tout développement de logiciel, mais la définition de la "qualité" semble toujours faire l'objet d'un débat. En réalité, un code non sécurisé ne peut pas être considéré comme un code de qualité, même s'il est par ailleurs fonctionnel et beau. Le comble, c'est que le codesécurisé n'est pas non plus intrinsèquement de haute qualité. En d'autres termes, de mauvais schémas de codage peuvent résoudre un problème de sécurité, mais, ce faisant, en introduire un autre, voire casser entièrement le logiciel. 

Examinons un exemple de code de mauvaise qualité sous la forme d'un correctif pour une authentification défectueuse, ainsi que la version la plus sûre pour les meilleures pratiques :

‍

en utilisant System ;

using System.Collections.Generic ;

using System.Linq ;

using System.Threading.Tasks ;

using Microsoft.AspNetCore.Authorization ;

using Microsoft.AspNetCore.Http ;

utilisant Microsoft.AspNetCore.Mvc ;

‍

namespace BadFixesAPI.Controllers

{

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

    [ApiController]

    public class AlertsController : ControllerBase

    {

        private DatabaseContext context = new DatabaseContext() ;

‍

        [HttpGet(Name = "GetAlerts")]

        // Does not ensure that the user is authenticated 

        public IEnumerable<Alert> Get()

        {

            return context.GetAlerts() ;

        }

‍

        [HttpGet(Name = "GetAlerts")]

        // Ensures that the user is authenticated, but does not check any roles

        [Authorize()]

        public IEnumerable<Alert> GetBadFix()

        {

            return context.GetAlerts() ;

        }

‍

        [HttpGet(Name = "GetAlerts")]

        // Ensures that the user is authenticated, AND that they have the "Administrator" role

        [Authorize(Roles = "Administrator")]

        public IEnumerable<Alert> GetGoodFix()

        {

            return context.GetAlerts() ;

        }

    }

}

‍

Dans le premier extrait, aucun contrôle n'est effectué pour vérifier que l'utilisateur est authentifié, ce qui est à peu près aussi peu sûr que possible. Le deuxième extrait, bien que meilleur en termes de vérification de l'authentification, n'examine pas les rôles attribués et ne vérifie pas si les autorisations sont suffisamment élevées pour permettre l'accès aux informations demandées. La troisième vérifie à la fois l'authentification de l'utilisateur et l' attribution du rôle d'"administrateur". À une époque où le contrôle de l'accès au moindre privilège devrait être la norme dans la plupart des cas, il est essentiel que les rôles soient définis et vérifiés pour s'assurer que les informations ne sont accessibles que sur la base du besoin de savoir. 

La priorité absolue des développeurs est de créer des fonctionnalités, et même si la sécurité n'est pas intentionnellement mise de côté, ils n'ont pas nécessairement les compétences nécessaires pour éviter les mauvais schémas de codage qui conduisent à des bogues de sécurité, et la référence d'un bon ingénieur inclut rarement des prouesses en matière de codage sécurisé. Nous encourageons indirectement ces mauvaises habitudes si les fonctionnalités sont suffisamment géniales, et c'est cet état d'esprit qui doit changer. Le problème est que la façon dont certains parcours d'apprentissage encouragent la remédiation pratique du code renforce aussi potentiellement le code qui est sûr, mais de qualité inférieure. En appliquant une approche binaire du type "oui c'est sûr / non ce n'est pas sûr" assessment, au lieu de chercher à savoir si c'est vraiment la meilleure approche pour résoudre le bogue et maintenir l'intégrité du logiciel, il y a des diables dans les détails qui passent inaperçus. 

Si elle n'accompagne pas les développeurs tout au long du processus pour leur donner une vue d'ensemble du codage sécurisé, cette approche perpétue les mêmes problèmes qu'elle tente de résoudre. Imaginez que nous obtenions tous notre permis de conduire sur la seule base de notre capacité à conduire un véhicule jusqu'à une destination ; une note de passage même si nous avons grillé des feux rouges, traversé une haie et manqué de peu un piéton qui traversait la rue pour arriver à destination. Nous avons atteint l'objectif, mais c'est le voyage que nous avons effectué pour y parvenir qui compte le plus. 

Il faut permettre aux développeurs de se préoccuper davantage de la création de logiciels sûrs.

Le développeur moderne doit faire tourner beaucoup de choses, et il n'est pas surprenant qu'il trouve la formation à la sécurité ennuyeuse, surtout lorsqu'elle n'est pas mise en œuvre en tenant compte de sa journée de travail, et qu'elle l'éloigne de ses échéances et de ses priorités. Il est également tout à fait injuste de modifier leurs indicateurs clés de performance pour mettre l'accent sur le codage sécurisé, alors qu'ils ne disposent pas des compétences acquises grâce à des opportunités d'apprentissage régulières et adaptées et à des outils supplémentaires. Cependant, on ne saurait trop insister sur l'importance du développement de logiciels sécurisés, et il est crucial de rallier les développeurs à cette cause. 

En tant qu'ancien développeur, nous voulons généralement faire du bon travail et il est très motivant d'être considéré comme supérieur aux autres en termes de qualité de production. Inciter les développeurs à s'engager dans un renforcement continu des compétences en matière de sécurité est une évidence, et ils devraient être récompensés pour avoir reconnu l'importance de la sécurité au niveau du code. Les programmes de champions de la sécurité, les primes aux bogues et les hackathons peuvent être d'excellentes occasions de créer une culture positive de la sécurité, et ceux qui se retroussent les manches et s'impliquent devraient recevoir le butin.