Cinq vulnérabilités communes dans les applis Web (et comment y remédier)
Voici les cinq vulnérabilités les plus courantes des applications Web. notre expert vous propose des méthodes qui permettant aux entreprises de s'en protéger.
Un grand nombre des vulnérabilités les plus courantes sont si répandues que les kits de programmes criminels contiennent des outils permettant de les déceler, facilitant ainsi leur exploitation par des pirates, même novices. Cet article passe en revue les cinq vulnérabilités les plus courantes et fournit des conseils permettant de corriger les problèmes d'origine et de lutter contre les attaques visant à exploiter ces failles.
Vulnérabilités par injection et cross-site scripting (XSS)
Les attaques par injection revêtent diverses formes, dont l'injection dans le code SQL, dans un système d'exploitation, dans les courriels et dans le protocole LDAP, qui reposent toutes sur l'envoi de données malveillantes à une application dans le cadre d'une commande ou d'une requête. Des données soigneusement conçues peuvent tromper une application afin qu'elle exécute des commandes non souhaitées ou accède à des données non autorisées.
Une injection SQL se produit lorsque des pirates prennent le contrôle de sites qui génèrent des requêtes SQL à partir de données fournies par les utilisateurs sans vérifier au préalable si ces données sont valides. Ces pirates sont alors en position d'envoyer des requêtes SQL malveillantes et de transmettre des commandes directement à une base de données. A titre d'exemple, on soupçonne que l'injection SQL a été utilisée pour accéder à la base de données Sony PlayStation et y implanter du code non autorisé dans le cadre des attaques de 2011 contre le PlayStation Network.
Les attaques XSS (Cross-site scripting) visent les utilisateurs d'une application en injectant du code, généralement un script côté client (tel que du JavaScript), dans la sortie d'une application Web. Dès que la sortie ou la page infectée est affichée, le navigateur exécute le code, permettant ainsi à un pirate de détourner des sessions utilisateur, de rediriger l'utilisateur vers un site malveillant ou simplement d'endommager la page. Les attaques XSS sont possibles dans le contenu d'une page générée dynamiquement, à partir du moment où une application intègre des données fournies par l'utilisateur sans les valider ni les convertir correctement.
Pour empêcher les attaques par injection et les attaques XSS, il faut configurer une application en partant du principe que toutes les données, qu'elles proviennent d'un formulaire, d'une URL, d'un cookie voire de la base de données de l'application, proviennent d'une source non fiable.
Passez en revue chaque étape au cours de laquelle des données fournies par l'utilisateur sont manipulées et traitées et vérifiez qu'elles sont validées.
Les fonctions de validation doivent nettoyer les caractères ou chaînes en entrée susceptibles d'être utilisés de façon malveillante avant de les transmettre à des scripts et à des bases de données.
Il convient donc de vérifier le type, la longueur, le format et la portée des entrées.
Les développeurs doivent faire appel aux bibliothèques de contrôle de sécurité existantes, comme la library Anti-Cross Site Scripting de Microsoft, au lieu d'écrire leurs propres contrôles de validation. Par ailleurs, veillez à ce que les valeurs acceptées à partir du client soient vérifiées, filtrées et codées avant d'être retransmises à l'utilisateur.
Problèmes d'authentification et de gestion des sessions
Les applications Web doivent gérer l'authentification des utilisateurs et établir des sessions pour suivre les demandes, car le protocole HTTP ne dispose pas de cette fonction.
Et aussi
Si toutes les informations d'authentification et les identifiants de session ne sont pas en permanence protégés par chiffrement, et protégés contre toute divulgation par d'autres failles telles que le XSS, un pirate peut détourner une session active et usurper l'identité d'un utilisateur.
Dans le cas où un pirate découvre une session de laquelle l'utilisateur d'origine ne s'est pas déconnecté (attaques « walk-by »), toutes les fonctions et transactions de gestion du compte doivent exiger une nouvelle authentification, même si l'utilisateur présente un ID de session valide. Une authentification à deux facteurs doit également être envisagée pour les transactions de grande valeur.
Pour déceler des problèmes d'authentification et de gestion des sessions, les entreprises peuvent procéder à une vérification du code et à des tests d'intrusion. Les développeurs disposent de scanneurs automatisés du code et des vulnérabilités pour détecter d'éventuels problèmes de sécurité.
Les domaines à surveiller plus particulièrement sont la gestion des identifiants de session et les méthodes utilisées pour modifier les informations d'identification d'un utilisateur. Si le budget est insuffisant pour se procurer des versions commerciales, il existe de nombreuses versions open source et simplifiées qui pointent les domaines dans lesquels une inspection plus approfondie du code ou des processus est nécessaire.
Références directes non sécurisées à un objet
Cette autre faille découle d'une mauvaise conception des applications, reposant sur l'hypothèse erronée que les utilisateurs suivent toujours les règles des applications. Par exemple, si l'ID de compte d'un utilisateur apparaît dans l'URL de la page ou dans un champ masqué, un utilisateur malveillant peut deviner l'ID d'un autre utilisateur et soumettre de nouveau la demande d'accès à ses données, en particulier si l'ID revêt une valeur prévisible.
Les meilleurs moyens de combattre cette vulnérabilité consistent à utiliser des ID et des noms de fichier et d'objet aléatoires, non prévisibles, et de ne jamais laisser apparaître les noms réels des objets.
Les données de ce type sont généralement exposées de façon incorrecte dans des URL et des liens, des champs de formulaire masqués, l'état d'affichage non protégé dans ASP.NET, des zones de liste déroulante, du code JavaScript et des objets côté client, tels que des applets Java.
En cas d'accès à des fichiers ou à du contenu sensibles, vérifiez que l'utilisateur dispose des autorisations nécessaires.
Mauvaise configuration de la sécurité
L'infrastructure qui prend en charge une application Web comporte de nombreux appareils et logiciels : serveurs, pare-feu, bases de données, systèmes d'exploitation et applications. Tous ces éléments doivent être configurés et gérés de façon sécurisée, l'application étant exécutée avec les privilèges minimaux requis. L'une des causes principales d'une administration système médiocre tient au manque de formation adéquate des personnes responsables de la gestion des applications Web et de l'infrastructure sous-jacente.
Si la sécurité et la confidentialité doivent rester une priorité dans toutes les phases du processus de développement, il est tout aussi essentiel de fournir une formation et des ressources appropriées aux personnes chargées de la gestion quotidienne des réseaux et des applications.
Enfin, planifiez un test d'intrusion pour les applications Web qui traitent des données sensibles. Cette méthode proactive permet d'évaluer la capacité à résister à une attaque et de détecter les vulnérabilités avant les pirates.
Conclusion
Depuis des années, ces cinq vulnérabilités courantes des applications Web représentent une épine dans le pied de la sécurité informatique. Ni ces problèmes ni leurs solutions ne datent d'hier, mais tant que la sécurité des applications Web n'est pas la priorité, les voleurs, fraudeurs et cyber-espions continueront à profiter de la situation.