Vulnérabilités des applications : pourquoi elles persistent et comment mener la défense

La plupart des incidents de sécurité qui font l’actualité n’exploitent pas une faille nouvelle et sophistiquée. Il exploite quelque chose qui est connu depuis des années, documenté, avec un correctif disponible, mais qui n'a tout simplement pas été résolu. La vulnérabilité n'était pas cachée. C’était sur la liste des choses à faire que personne n’a priorisée.

C’est inconfortable à admettre, mais c’est la vérité qui compte le plus pour ceux qui dirigent. Les catégories de vulnérabilités des applications sont remarquablement stables. L’OWASP, référence mondiale en matière de sécurité des applications, publie depuis plus de deux décennies la même liste, avec de légères variations, des risques les plus courants. Si les problèmes sont connus et les solutions existent, pourquoi persistent-ils ?

La réponse n’est pas technique. C'est la gestion. La sécurité des applications échoue moins à cause d’un manque de connaissances qu’à cause d’un manque de priorités, de processus et de culture. Ce texte traite de cela, écrit pour ceux qui décident où l'équipe passe son temps, pas seulement pour ceux qui écrivent du code.

Qu'est-ce qu'une vulnérabilité, sans mystification

Une vulnérabilité est une faiblesse d'un système qui peut être exploitée pour causer des dommages : fuite de données, altération d'informations, arrêt du service, prise de contrôle. Il n’est pas nécessaire d’avoir un génie maléfique pour l’explorer. La plupart sont découverts par des outils automatisés qui analysent l’intégralité d’Internet à la recherche exactement des mêmes erreurs répétées.

C'est pourquoi « personne ne sera intéressé par notre candidature » est une expression dangereuse. La numérisation est automatique et aveugle. Ce qui décide si vous êtes une cible, ce n’est pas la pertinence de votre entreprise, c’est l’existence de la faille.

Et le coût d’une faille exploitée va bien au-delà du technique. Il y a interruption du service, perte de confiance, atteinte à la réputation et, au Brésil, exposition à la LGPD lorsque des données personnelles sont impliquées. Une vulnérabilité non traitée constitue un handicap pour l’entreprise, pas seulement un bug.

Le Top 10 OWASP comme carte prioritaire

Le Top 10 de l'OWASP est le point de départ le plus judicieux pour toute organisation. Il ne s'agit pas d'une liste de contrôle de sécurité complète, mais il s'agit du consensus de la communauté sur les risques qui apparaissent le plus et causent le plus de dégâts. Il vaut la peine d’en connaître les principales catégories, traduites dans la langue de ceux qui décident.

Contrôle d'accès cassé

La catégorie la plus courante. Cela se produit lorsque le système ne vérifie pas correctement qui peut faire quoi. Un utilisateur accède aux données d'un autre en modifiant un numéro dans l'URL ; une personne ordinaire accomplit une action qui devrait être effectuée par un administrateur. C’est l’échec « la porte est ouverte à ceux qui savent pousser ».

Failles cryptographiques

Données sensibles voyageant ou stockées sans protection adéquate, mots de passe stockés de manière réversible, connexions sans cryptage. Dans le contexte de la LGPD, cela est particulièrement grave : les données personnelles exposées par un cryptage absent ou mal exécuté constituent un échec exigé par la loi.

###Injection

Lorsque les données envoyées par l'utilisateur sont interprétées comme une commande par le système. Le cas classique est l'injection SQL, dans laquelle un champ de formulaire devient une instruction pour la base de données. C’est l’une des erreurs les plus anciennes et encore les plus exploitées, car elle continue à se commettre.

Conception non sécurisée

Une catégorie plus récente et importante : les failles qui ne sont pas dans le code, mais dans la conception. Vous pouvez mettre en œuvre de manière transparente une architecture qui n’était pas sécurisée de par sa conception. La sécurité doit être dès la planche à dessin, et pas seulement lors de l’examen final.

Mauvaise configuration de la sécurité

Serveurs avec configuration par défaut, panneaux d'administration exposés, messages d'erreur révélant des détails internes, autorisations trop larges. Souvent, il n’y a pas de mauvais code, il y a un environnement mal configuré, ce qui est tout aussi dangereux.

Composants vulnérables et obsolètes

Presque tous les logiciels modernes reposent sur des bibliothèques tierces. Lorsqu'une de ces dépendances présente une faille connue et n'est pas mise à jour, votre application hérite du problème. Le maintien de l'inventaire et la mise à jour de ces pièces sont un travail continu et non occasionnel.

Les catégories restantes, échecs d’identification et d’authentification, échecs d’intégrité des données et des logiciels, échecs de journalisation et de surveillance et falsification de requêtes côté serveur, complètent la liste. Le but n’est pas de mémoriser les dix. C'est comprendre qu'il existe une carte publique des risques les plus probables et que l'ignorer est un choix.

La thèse : la sécurité est une décision de gestion, pas une tâche de fin de projet

Ma position est que la plus grande faiblesse de la plupart des applications n’est pas technique, mais organisationnelle. Les développeurs, en général, savent ce que sont l’injection et le contrôle d’accès brisé. Ce qui manque, c'est du temps, des priorités et un processus qui intègre la sécurité au travail, et non une chose supplémentaire qui peut être faite « lorsque cela est possible ».

Quand la sécurité est traitée comme une étape de fin de projet, un audit hâtif avant le lancement, c'est perdant. La pression des délais l’emporte toujours sur les soins qui n’ont pas de propriétaire clair. Les échecs coûteux sont ceux qui ont été connus et dépriorisés, et non ceux que personne n’a vus.

Un leadership technologique qui prend la sécurité au sérieux n’exige pas l’héroïsme de l’équipe. Créez un système dans lequel faire ce qu'il faut est le moyen le plus simple : révision du code avec un œil de sécurité, tests automatisés qui détectent les failles courantes, mise à jour des dépendances de manière routinière et clarté sur le fait que la livraison non sécurisée n'est pas assurée.

Comment réduire les vulnérabilités en pratique

Une défense efficace est faite d’habitudes et non d’un seul grand projet. Traiter la sécurité comme faisant partie du cycle de développement, plutôt que comme un événement isolé, est ce qui différencie les organisations matures.

Certaines pratiques ont un rendement disproportionné. La validation et le traitement de toutes les entrées utilisateur comme non fiables éliminent des classes entières de l'injection. L'application du principe du moindre privilège, donnant à chaque partie du système uniquement l'accès dont elle a besoin, limite les dégâts en cas de panne. Garder les dépendances à jour ferme la porte aux failles connues. L'enregistrement et la surveillance vous permettent de découvrir un incident en quelques heures, et non en quelques mois.

Il vaut également la peine d’adopter des analyses automatisées dans le flux de développement lui-même, afin que les défauts courants soient identifiés avant d’atteindre la production. L’automatisation ne remplace pas la réflexion, mais elle supprime le travail répétitif de recherche d’erreurs déjà cataloguées.

Pour les systèmes qui traitent les données des citoyens, courants dans le secteur public, cela se connecte directement à la LGPD et à la continuité du service. Une panne n’est pas seulement un risque technique ; Il s’agit d’un risque juridique et de confiance du public.

Limites et pièges

Il est honnête de reconnaître que la sécurité absolue n’existe pas. L’objectif n’est pas de rendre l’application inviolable, mais de la rendre suffisamment coûteuse pour être attaquée et suffisamment résiliente pour détecter et réagir en cas de problème.

Le piège le plus courant est le théâtre de sécurité : des politiques détaillées, des documents de conformité et des outils coûteux qui donnent un sentiment de protection sans réduire le risque réel. La conformité sur papier n’est pas la sécurité dans la pratique. Ce qui protège, c'est ce qui est implémenté et testé, et non ce qui est écrit.

Un autre piège consiste à considérer la sécurité comme la responsabilité exclusive d'un spécialiste ou d'une zone isolée. Lorsque la sécurité est « le problème des gens de la sécurité », le reste de l’équipe perd ses responsabilités. La vraie défense est distribuée : quiconque écrit ou configure quelque chose a un rôle.

Une vulnérabilité connue et ignorée est une décision, pas un accident

La phrase à retenir est simple : presque toutes les vulnérabilités exploitées étaient connues et évitables. C’est effrayant, mais aussi libérateur, car cela signifie que la plupart des risques sont sous notre contrôle. Nous ne dépendons pas de la prévision d’une attaque sans précédent. Nous dépendons du traitement de ce que nous savons déjà.

La sécurité des applications de pointe est, par essence, une priorité absolue. Il s'agit de décider que la fourniture d'une assurance fait partie de la prestation, que la mise à jour des dépendances n'est pas une perte de temps, qu'un échec connu et négligé est une décision à laquelle quelqu'un réagit. L'OWASP nous donne la carte. Ce qui manque, presque toujours, c’est la volonté de le suivre.

Si votre organisation considère la sécurité comme une étape finale plutôt que comme une pratique continue, il vaut la peine de revoir ce processus avant que le prochain incident ne le fasse à votre place. J'ai d'autres textes sur le blog sur la sécurité, la LGPD et le développement sécurisé, et je suis disponible pour parler à celui qui structure ce front.