Utilisation d’un cycle de vie de développement sécurisé
Objectifs de formation
Une fois cette unité terminée, vous pourrez :
- Expliquer l’importance de sécuriser le cycle de vie du développement
- Répertorier les attaques importantes (injection, XSS) qui profitent du manque d’assainissement et de validation
Protection du cycle de vie du développement logiciel
- Planifier les exigences et les cas d’utilisation auxquels une application répondra.
- Concevoir l’application.
- Implémenter l’application en ayant recours à la programmation.
- Tester si l’application fonctionne correctement.
- Déployer l’application auprès du client.
- Assurer la maintenance de l’application.
La liste précédente présente les six étapes d’un cycle de vie de développement logiciel (SDLC) typique. Si vous avez déjà travaillé au sein d’une équipe de développement d’applications, vous connaissez probablement chaque phase de ce cycle. Toutefois, vous n’avez peut-être pas connaissance de la manière dont un ingénieur en sécurité des applications intervient au cours de ce cycle. L’ingénieur teste-t-il surtout la sécurité de l’application avant qu’elle ne soit déployée auprès du client ? Se concentre-t-il sur le maintien de la sécurité de l’application en corrigeant les vulnérabilités critiques ? Sinon, suggère-t-il à l’entreprise que des fonctionnalités de sécurité particulières soient intégrées à la conception ?
La réponse est qu’un ingénieur en sécurité des applications joue un rôle essentiel à chaque étape du SDLC. Étant donné que des problèmes de sécurité peuvent être introduits ou découverts à n’importe quelle phase du cycle de vie d’une application, l’ingénieur en sécurité des applications a un rôle permanent à jouer afin de protéger la confidentialité, l’intégrité et la disponibilité des données de l’application. La sécurité est souvent associée à la problématique dite du « maillon faible ». Tout comme une chaîne métallique solide peut être brisée si l’un de ses maillons est fragilisé, la sécurité de chaque phase du SDLC doit être assurée pour sécuriser le développement, le déploiement et la maintenance de l’application dans son ensemble.
Par exemple, pendant la phase d’implémentation du SDLC, des vulnérabilités peuvent être introduites dans le code si les développeurs ne parviennent pas à mettre en place des contrôles qui assainissent et valident les saisies. Cela pourrait donner la possibilité à un attaquant d’effectuer au sein de l’application des saisies qui lui permettraient d’accéder de manière inappropriée aux données d’un autre utilisateur ou à des fonctions d’administration.
De plus, les équipes de développement ont souvent recours à du code open source lors du développement d’applications. Le code open source est développé de manière collaborative par de nombreuses personnes travaillant ensemble sur Internet. Bien que ce code puisse être davantage sécurisé en raison du grand nombre de développeurs travaillant ensemble pour le développer et le réviser, il peut aussi parfois comporter des vulnérabilités. Les équipes de développement doivent rester vigilantes et vérifier ces bibliothèques de codes pour s’assurer qu’elles n’emploient pas de composants présentant des vulnérabilités connues.
Dans le monde du développement agile, où les équipes de développement d’applications proposent continuellement de nouveaux services et fonctionnalités tout en devant respecter des délais de plus en plus serrés, l’attention qu’il convient de porter à la cyberhygiène et à la gestion des changements peut souvent être négligée.
Les ingénieurs en sécurité des applications travaillent en étroite collaboration avec les équipes de développement durant toutes les phases du SDLC. Ils jouent le rôle de sensibilisateurs, de consultants et d’experts spécialisés pour garantir que les applications sont conçues en toute sécurité, que le code est implémenté avec des validations de sécurité effectives et que des vulnérabilités ne sont pas introduites lors de la transition de la phase de développement à celle d’assurance qualité, puis jusqu’à la mise en production.
Protection contre les injections et les scripts inter-sites (XSS)
La sécurisation du SDLC est particulièrement importante pour se prémunir contre deux risques de sécurité importants et facilement exploitables auxquels les applications sont sujettes : l’injection et les scripts inter-sites (XSS). Réfléchissez au fonctionnement d’une application. L’une des fonctionnalités les plus importantes de presque toute application est la possibilité de stocker et de récupérer des données à partir d’une banque de données (telle qu’une base de données). Les développeurs utilisent des langages de programmation pour indiquer à l’application comment interagir avec la base de données en fonction des saisies de l’utilisateur. Par exemple, lorsqu’un utilisateur se connecte à une application, il saisit son nom d’utilisateur et son mot de passe. Lorsqu’il appuie sur Entrée, il déclenche une requête dans la base de données : si cette requête réussit, l’utilisateur peut accéder au système.
Malheureusement, chaque interaction d’un utilisateur légitime avec une application peut également être exploitée par un attaquant à des fins malveillantes. Une faille d’injection se produit lorsqu’un attaquant envoie des données non fiables en tant qu’éléments d’une commande ou d’une requête. Si les développeurs n’ont pas correctement validé/assaini les saisies, un attaquant pourrait exécuter des commandes inattendues ou accéder à des données sans autorisation appropriée. Cela peut entraîner une perte, une corruption ou une divulgation de données.
Voilà un scénario plutôt effrayant ! Toutefois, les ingénieurs en sécurité des applications ont justement la lourde tâche de veiller à ce que ce type de scénario ne se produise pas. Ils utilisent tout un ensemble d’outils et de techniques pour aider l’équipe de développement à protéger l’application et les données de leurs clients contre ce type d’attaque.
- Examens de code source : il s’agit d’un processus principalement manuel au cours duquel l’ingénieur en sécurité des applications lit une partie du code source pour vérifier que les données sont validées et assainies de manière appropriée.
- Réalisation de tests statiques : cette méthode de réalisation de tests logiciels examine le code du programme mais ne requiert pas que le programme soit exécuté pendant ce temps. Par exemple, l’analyse de code statique peut permettre de vérifier un flux de données associé à des saisies utilisateur non fiables dans une application Web et d’examiner si les données s’exécutent en tant que commande (ce qui est un résultat non souhaité).
- Réalisation de tests dynamiques : cette méthode de réalisation de tests logiciels examine le code du programme pendant son exécution.
- Réalisation de tests d’automatisation : cette méthode emploie des scripts de test pour évaluer le logiciel en comparant le résultat réel du code au résultat attendu.
- Séparation des commandes et des requêtes : ici, il est question d’assurer une séparation entre les données des commandes et des requêtes. L’idée est que chaque méthode doit être soit une commande qui effectue une action, soit une requête qui renvoie des données à l’appelant, mais jamais les deux. Une requête ne doit jamais modifier l’état d’une application ou de ses données, tandis qu’une commande peut modifier leur état, mais ne doit jamais renvoyer de valeur. Cela empêche un attaquant de renseigner des commandes au sein du système d’exploitation via une interface Web afin de les exécuter et de charger des programmes malveillants ou d’obtenir des mots de passe.
- Utilisation de listes d’autorisations : l’implémentation de listes d’autorisation répertoriant les caractères ou les commandes admissibles peut permettre de valider les entrées des utilisateurs, ainsi que garantir que les données d’URL et de formulaire ne puissent pas exécuter de commandes non autorisées ou employant ces caractères. Par exemple, une liste d’autorisations peut échapper ou filtrer des caractères spéciaux, tels que ( ) < > & * ‘ | = ? ; [ ] ^ ~ ! . ” % @ / \ : + , `
- Outil complémentaire : l’énumération des faiblesses courantes de l’organisation Mitre (CWE) constitue une ressource utile en ce qui concerne les autres considérations relatives à la protection contre les injections de commandes.
Outre les injections, le fait de ne pas sécuriser le SDLC en procédant à la validation et à l’assainissement des données, ainsi que via les tests et l’analyse du code, présente un autre risque : celui que l’application s’avère vulnérable aux scripts inter-sites (XSS). Une vulnérabilité XSS se manifeste lorsqu’une application inclut des données non fiables dans une nouvelle page Web sans procéder à la validation appropriée.
L’image illustre le fonctionnement des XSS. Tout d’abord, un attaquant injecte du code malveillant dans un site Web de confiance afin d’envoyer ce code à un utilisateur peu méfiant. Suite à cela, la page Web enregistre le script malveillant dans une base de données. Ensuite, la victime visite le site Web et demande des données au serveur, en pensant que celles-ci sont sûres. Les données contenant le script malveillant transitent alors par le serveur de pages Web vers l’ordinateur de l’utilisateur, où le script s’exécute. Enfin, le script communique avec l’attaquant, compromettant ainsi les informations de l’utilisateur, tandis que ce dernier croit interagir avec un site Web de confiance dans le cadre d’une session en ligne sécurisée.
En exécutant des scripts malveillants au sein du navigateur d’une victime via des XSS, une personne malveillante peut détourner la session d’un utilisateur, dégrader un site Web ou rediriger un utilisateur vers un site frauduleux où il peut être invité à télécharger un logiciel malveillant ou à saisir ses identifiants pour que l’attaquant puisse les voler. Ainsi, la victime peut se faire dérober ses informations sensibles ou son ordinateur peut se faire infecter par un logiciel malveillant. Ce dernier peut également être intégré à un réseau de machines zombies, que les attaquants peuvent utiliser pour exécuter des attaques par déni de service distribué qui inondent de trafic le réseau d’une organisation, ce qui limite l’accès des utilisateurs légitimes.
Les ingénieurs en sécurité des applications doivent se préoccuper des XSS, car il s’agit d’un vecteur d’attaque facilement exploitable et d’une faille de sécurité répandue dont les pirates peuvent tirer parti à l’aide d’outils automatisés et disponibles gratuitement.
Une estimation a révélé que des vulnérabilités aux XSS sont présentes dans deux tiers de l’ensemble des applications. Bien que cela semble effrayant, cela signifie également que les ingénieurs en sécurité des applications ont un rôle passionnant et important à jouer dans la sécurisation du SDLC. Dans cette optique, les ingénieurs s’assurent que l’application valide les saisies des utilisateurs et ne stocke pas de saisies douteuses qui peuvent être consultées ultérieurement par un autre utilisateur ou administrateur. Pour ce faire, ils séparent les données non fiables du contenu actif du navigateur, en utilisant des cadres de programmation qui échappent automatiquement les XSS de façon native, ainsi qu’en appliquant un encodage contextuel.
Conclusion
Vous avez découvert plusieurs aspects dont il est crucial de tenir compte pour protéger les applications et leurs données tout au long du SDLC. Il est maintenant temps d’en apprendre davantage sur une autre considération essentielle pour un ingénieur en sécurité des applications : le fait de configurer correctement les composants d’application.