Durcissement des applications Web et mobiles

Codage sécurisé

Trop de sites Web demandent aux utilisateurs d’enregistrer un nom d’utilisateur et un mot de passe. Alors que les professionnels de la sécurité exhortent les gens à utiliser des mots de passe différents – et les navigateurs Web généreront et stockeront automatiquement un mot de passe fort – de nombreuses personnes optent pour un mot de passe facile à retenir. Souvent, ils utiliseront le même mot de passe pour s’authentifier sur plusieurs sites Web. En tant que tel, le mot de passe de l’utilisateur est non seulement facile à déchiffrer, mais un pirate peut également essayer d’utiliser le même mot de passe pour cibler d’autres sites.

L’API OAuth est l’une des approches disponibles pour les sites Web qui souhaitent offrir une authentification sans obliger les utilisateurs à configurer un nouveau mot de passe. Il utilise l’authentification back-end de Facebook et Google, mais le coût de cette commodité est que Google et Facebook partageront certaines des informations de l’utilisateur avec l’organisation qui gère le site Web.

Le projet OWasp (Open Web Application Security Project) a créé un ensemble de directives dans le cadre de sa norme de vérification de la sécurité des applications. Dans ses recommandations, OWasp préconise l’utilisation des dernières méthodes d’authentification sécurisée des utilisateurs, telles que l’authentification multifacteur (MFA), la biométrie ou les mots de passe à usage unique. D’autres recommandations incluent un cryptage fort pour éviter la perte de données, des contrôles d’accès et la désinfection et la validation du contenu généré par l’utilisateur, tel que les données que l’utilisateur est censé taper dans une zone de saisie sur une application Web ou mobile.

La norme stipule que les développeurs d’applications Web et mobiles doivent implémenter des contrôles de validation des entrées. Selon OWasp, 90% de toutes les attaques par injection se produisent parce qu’une application ne parvient pas à vérifier correctement les données d’entrée. La version 4.0.2 de la norme de vérification de la sécurité des applications indique : « Les vérifications de la longueur et de la plage peuvent réduire davantage ce nombre. La validation d’entrée sécurisée est requise lors des sprints de conception de l’architecture d’application, du codage et des tests unitaires et d’intégration.

En effet, les développeurs d’applications doivent écrire du code d’une manière qui empêche l’utilisation de données d’entrée non autorisées comme vecteur d’attaque. Dans une attaque de style injection, des données soigneusement conçues sont utilisées pour provoquer une erreur qui oblige l’application à exécuter les données comme un autre programme. Une telle attaque peut être évitée si le programmeur écrit le logiciel pour gérer les données d’entrée d’une manière qui vérifie quelles données il attend. Par exemple, s’il attend un nombre, il doit rejeter tout ce qui n’a pas de sens. De même, les adresses et les dates de naissance ont des formats standard, qui peuvent être vérifiés.

L’un des nombreux défis auxquels les programmeurs sont confrontés lorsqu’ils tentent d’écrire du code sécurisé qui empêche les attaques par injection ou par débordement de la mémoire tampon est le fait que le développement de logiciels modernes est très hétérogène. « Si vous voulez vraiment les arrêter, vous devez rendre impossible l’écriture d’un débordement de tampon ou d’une attaque par injection », explique Owen Wright, directeur général de l’assurance chez Accenture.

Mais, alors que la plupart des logiciels étaient codés à la main, Wright affirme que les méthodes modernes de développement de logiciels s’appuient fortement sur des frameworks tiers, des bibliothèques et l’intégration avec les services cloud. Ceux fournis par les grands fournisseurs commerciaux peuvent avoir des équipes importantes dédiées au codage sécurisé, dit-il, mais « certaines bibliothèques open source bien utilisées sont maintenues par un seul or deux personnes [and] tout le monde s’appuie sur eux et assume [they are] bien entretenu ».

Au-delà du codage, Wright note que les organisations commencent à adopter une approche de « virage à gauche » de la sécurité informatique, où les développeurs assument plus de responsabilités dans la production de code sécurisé. « Les développeurs ne sont pas enseignés avec un état d’esprit de sécurité – ils sont d’abord des développeurs », dit-il. « Les organisations devraient se concentrer davantage sur la sensibilisation à la sécurité. »

Mais il y a une tension constante entre la vitesse, le coût et la qualité. Wright estime que le passage à un modèle DevSecOps pour les projets logiciels encourage les développeurs à résoudre le code du problème plus tôt qu’ils ne le feraient s’ils dépendaient des tests de pénétration une fois que l’application a été soumise. C’est l’un des principes du transfert de la responsabilité du codage sécurisé à gauche, de nouveau au développeur.

D’après l’expérience de Wright, cela coûte beaucoup moins cher que de corriger les erreurs de sécurité plus tard dans le cycle de vie du développement logiciel. Il suggère aux organisations de créer des modèles pour sécuriser les applications qui peuvent ensuite être déployées sur des projets ultérieurs.

Protection des applications Web

Les attaques de la couche Application, également appelées attaques de couche 7 ou L7, tentent de surcharger les serveurs en envoyant des requêtes HTTP légitimes en continu.

Selon iGéant de l’infrastructure nternet Cloudflare, l’efficacité sous-jacente de la plupart des attaques par déni de service distribué (DDoS) provient de la disparité entre le volume de ressources nécessaire pour lancer une attaque par rapport au volume de ressources nécessaires pour en absorber ou en atténuer une. Il dit qu’une attaque de la couche application crée plus de dégâts avec moins de bande passante totale.

Par exemple, si un utilisateur souhaite accéder à un service Web, par exemple Gmail, ou effectuer une transaction web sur un site de commerce électronique, le serveur reçoit une demande du logiciel client s’exécutant sur le navigateur ou l’appareil de l’utilisateur et doit ensuite effectuer une requête de base de données ou appeler une API pour répondre à la demande de l’utilisateur.

Cloudflare note qu’une attaque par déni de service tire parti du fait qu’il peut y avoir une disparité dans la capacité du serveur à effectuer cette tâche lorsque de nombreux appareils ciblent une seule propriété Web. « L’effet peut submerger le serveur ciblé. Dans de nombreux cas, le simple fait de cibler une API avec une attaque de couche 7 suffit à mettre le service hors connexion », avertit-il dans un article examinant la sécurité au niveau de l’application.

Gartner’s Magic Quadrant pour les pare-feu d’applications Web , publié en octobre 2020, prévoit que d’ici 2023, plus de 30 % des applications web et des API publiques seront protégées par des services de protection des APPLICATIONS WEB ET DES API (WAAP) dans le cloud. D’ici 2024, Gartner s’attend à ce que la plupart des organisations mettant en œuvre des stratégies multicloud pour les applications Web en production n’utilisent que les services WAAP cloud.

Public cloud WAFs

Gartner’s Magic Quadrant pour les pare-feu d’applications Web le rapport nomme Akamai et Imperva en tant que « leaders » dans le domaine du pare-feu d’applications Web (WAF).

Cloudflare, Fortinet, F5 et Barracuda constituent le quadrant « challenger » de Gartner. Avec les deux leaders, ces entreprises ont tendance à être sur la liste restreinte lorsque les décideurs informatiques examinent leurs options sur le marché WAF.

Le fournisseur de services de protection DDoS Radware et la start-up WAF Signal Sciences forment le quadrant « visionnaire » de Gartner, reconnaissant l’utilisation innovante de la technologie dans leurs offres de produits. Gartner note que Radware utilise l’apprentissage automatique dans son pare-feu d’applications Web pour lutter contre les menaces, tandis que Signal Sciences se concentre sur la sécurisation des applications cloud natives.

Les fournisseurs de cloud public offrent également des fonctionnalités de pare-feu d’applications Web dans le cadre de leurs plates-formes. Cependant, Microsoft Azure et Amazon Web Services (AWS) sont considérés comme des acteurs de « niche » par Gartner.

Par exemple, le rapport Magic Quadrant note qu’AWS WAF fournit une protection de base des bots via l’ensemble de règles gérées et la capacité de protection de l’infrastructure fournis par AWS. Cependant, les auteurs du rapport avertissent qu’AWS WAF ne dispose pas de nombreuses fonctionnalités avancées de protection des bots spécifiques aux applications que l’on trouve dans les produits concurrents, telles que l’empreinte digitale des appareils, la détection du comportement des utilisateurs et les défis JavaScript.

En examinant l’offre de Microsoft, Gartner indique qu’Azure WAF est disponible dans d’autres régions Azure.Looking to Microsoft’s offering, Gartner says Azure WAF is being available in more Azure regions. Le rapport met en évidence le travail de Microsoft pour intégrer Azure WAF à d’autres services Azure.The report highlights Microsoft’s work to integrate Azure WAF with other Azure services. Par exemple, Gartner note qu’Azure WAF s’intègre désormais en mode natif au contrôleur d’entrée Azure Kubernetes Service pour la protection des microservices, peut envoyer des événements à Azure Sentinel de Microsoft pour une surveillance intégrée et fait un meilleur usage de l’infrastructure technique Microsoft pour bloquer les bots connus.

Le GaLe rapport rtner mentionne également de nouvelles fonctionnalités dans le service d’atténuation WAF et DDoS Cloud Armor de Google, disponible sur Google Cloud Platform (GCP). Les auteurs du rapport affirment que Google a ajouté des « fonctionnalités utiles », telles que des listes de contrôle IP et le filtrage géo-IP, des règles prédéfinies pour le blocage des scripts inter-sites (XSS) et de l’injection SQL (SQLi), ainsi que la création de règles personnalisées. Selon Gartner, Google montre des signes de volonté d’étendre ses capacités.