Il s'agit du premier matériel d'une série d'articles sur le projet OWASP Top 10, un projet qui a commencé comme une idée pour les passionnés et est devenu la source la plus fiable pour classer les vecteurs d'attaque et les vulnérabilités dans les applications Web.
Dans cet article, nous analyserons brièvement toutes les principales vulnérabilités de la liste Top 10 OWASP, et verrons également pourquoi il est si important de connaître les vulnérabilités typiques afin de développer des applications sécurisées.
Il y a environ 10 ans, une personne très observatrice a formulé un nouveau mantra - HTTP est un nouveau TCP. Bien sûr, pas dans le sens où la personne a décidé de mettre HTTP au niveau du transport. Pas question! C'est juste que pour les communications modernes, le protocole HTTP remplit la même fonction que TCP à son niveau - la grande majorité des applications modernes, y compris les applications mobiles, utilisent HTTP comme transport. Et avec l'avènement de HTTP 2.0, cette situation a bronzé et dans un avenir proche, apparemment, cela ne changera pas. Le protocole est devenu la norme de livraison de contenu de facto et HTTP ne peut plus être considéré comme un protocole Web.
Il peut sembler que HTTP a toujours existé, et cela est presque vrai si l'on considère que la première spécification officielle de RFC est apparue en 1997, bien que le protocole lui-même ait commencé à être utilisé beaucoup plus tôt.
Il a fallu pas mal de temps pour comprendre que dès que le protocole deviendra populaire, tout le monde commencera à l'utiliser pour fournir du contenu, souvent sans qualifications appropriées. Et le résultat sera des centaines de milliers de systèmes vulnérables dans le monde et de vagues perspectives pour remédier à la situation.
Dans le cas de décisions de fournisseurs spécifiques, vous pouvez toujours vous tourner vers ses documents ou demander directement: "quelle est la meilleure façon d'agir?" - et obtenir une réponse qualifiée, car au final seul le vendeur est responsable de son produit. Lorsqu'il s'agit d'utiliser des normes et des outils ouverts pour créer des applications, une source impartiale d'informations sur les meilleures pratiques est nécessaire. Une telle source peut être des passionnés, ou peut-être toute une communauté de professionnels dans ce domaine.
Guêpe volant
Dans le domaine de la sécurité des applications Web, l'OWASP (Open Web Application Security Project) est devenu une telle communauté. Bien sûr, OWASP est une organisation à but non lucratif qui n'est affiliée à aucune entreprise technologique. Cette situation vous permet de fournir des informations pratiques impartiales sur les technologies de protection des applications Web pour les organisations, les établissements d'enseignement, les services gouvernementaux et même les personnes intéressées par le problème.
Alors que fait exactement OWASP? Dans le cadre de ses compétences, l'OWASP a deux tâches principales: produire de la documentation et fournir des outils, et ce, absolument gratuitement.
Dans cette série d'articles, nous analyserons, peut-être, le matériel OWASP TOP 10 Project le plus populaire. Il s'agit d'un document répertoriant les risques les plus importants et les plus critiques des applications Web. La décision d'inclure des vulnérabilités dans cette liste est basée sur l'opinion d'experts d'experts en sécurité de l'information du monde entier (où sans elle), et dans l'ensemble, la compréhension de ces vulnérabilités est la première étape afin de changer la culture du développement logiciel.
Vous devez comprendre clairement que, en règle générale, toutes ces vulnérabilités ne sont pas basées sur les erreurs de programmeurs spécifiques ou les vulnérabilités des protocoles eux-mêmes, mais sur les problèmes architecturaux de la conception de logiciels.
Dix sorts mortels
La liste des vulnérabilités est constamment mise à jour et pour 2017 est la suivante:
• A1: 2017 - Injections, alias «Code Injection»
Nous parlons de tous les types d'injections: SQL, NoSQL, LDAP - n'importe quoi. L'injection de code devient possible lorsque des données non vérifiées sont envoyées à l'interpréteur dans le cadre d'une commande ou d'une demande. Une telle demande «malveillante» est exécutée en toute sécurité et fait son propre tort. Dans 90% des cas, lorsque vous apprenez qu'une base de données privée a été accessible via le Web, il s'agit simplement de notre A1.
• A2: 2017 - Authentification incorrecte
Les fonctions d'application responsables de l'authentification et de la gestion de session sont souvent utilisées de manière incorrecte, ce qui implique la compromission des mots de passe, des clés, des jetons de session et même la possibilité d'intercepter complètement une session utilisateur. Lorsque vous vous asseyez dans le wifi public et découvrez soudainement que certaines actions sont effectuées en votre nom sur des ressources Web publiques - c'est A2.
• A3: 2017 - Divulgation d'informations sensibles
De nombreuses applications Web et API peuvent stocker et traiter de manière incorrecte des informations sensibles, telles que des données personnelles. Les attaquants peuvent voler ou modifier ces informations, ce qui peut devenir la base de graves pertes financières ou de réputation. Les informations sensibles doivent être correctement stockées et également protégées lors de la transmission sur les canaux de communication.
• A4: 2017 - Implémentation d'entités XML externes (XXE)
De nombreux processeurs XML plus anciens ou configurés de manière croisée peuvent utiliser des données externes à partir de liens dans des fichiers XML. Ces données externes peuvent contenir du code malveillant qui vous permettra d'exécuter presque n'importe quel code superflu sur la machine cible.
• A5: 2017 - Contrôle d'accès violé
La matrice d'accès, qui était si bonne sur le papier, peut être mal essayée pour un système spécifique, de sorte que les utilisateurs illégitimes ont facilement accès à des zones fermées de sites ou ont la possibilité de modifier les droits sur les ressources à leur discrétion.
• A6: 2017-Security Misconfiguration - Erreurs de configuration
Nous parlons ici de quelques éléments plus globaux, tels que le manque de mises à jour opportunes du serveur et des logiciels d'application, la présence d'informations importantes dans les messages d'erreur ou même dans les en-têtes HTTP. L'application peut être presque parfaite, mais si le serveur Web sur lequel elle s'exécute a des problèmes avec la configuration de base, alors tout est inutile.
• A7: 2017 - Crossite Scripting (XSS)
XSS se produit lorsqu'une application inclut des données non fiables sans vérification appropriée. Par exemple, le code de programme d'une bannière publicitaire peut contenir un script pour intercepter les données des utilisateurs, le visage du site, ou même rediriger de manière transparente vers d'autres sites.
• A8: 2017 - Désérialisation dangereuse
Une désérialisation non sécurisée conduit généralement à l'exécution de code à distance. L'essentiel est que les données non fiables peuvent détruire la logique de votre application dès qu'elle est désérialisée. Une vulnérabilité plutôt exotique à première vue, cependant, prend sa place d'honneur dans la liste.
• A9: 2017 - Utilisation de composants avec des vulnérabilités connues
Les bibliothèques, cadres, systèmes d'exploitation et autres composants des systèmes d'information doivent être mis à jour en temps opportun. Sinon, une vulnérabilité connue dans une bibliothèque peut compromettre un grand service qui utilise même une fonction d'une bibliothèque vulnérable.
• A10: 2017 - Enregistrement et surveillance inadéquats
Tout est simple ici - vous avez construit un merveilleux système, mais vous avez oublié de fixer les outils de surveillance. Il ne s'agit même pas d'un système SIEM connecté, mais simplement de l'enregistrement banal des événements du serveur principal. Malheureusement, il n'est pas rare que des systèmes de piratage soient détectés six mois après le piratage lui-même, et ils en apprennent non pas à partir des journaux, mais à partir d'observateurs externes.
Dans les articles suivants, nous allons commencer à analyser plus en détail chacune de ces vulnérabilités. Nous nous armerons des outils nécessaires et verrons comment ces vulnérabilités sont mises en œuvre dans la pratique.
Préparé par
Sergey Polunin .