.svg){kind=logo}
Back
La plupart des produits que vous achetez sont destinés à la sécurité des réseaux et des terminaux. Ceux-ci ne seront pas très efficaces contre les vulnérabilités des applications web. C'est pourquoi, dans cet article, nous mettons en lumière les problèmes les plus courants que nous rencontrons dans notre travail, allant de la fragilité des réseaux à l'énumération des utilisateurs. Comprendre ces défis est essentiel non seulement pour les professionnels de l'informatique, mais aussi pour les particuliers et les organisations qui s'efforcent de renforcer leur sécurité dans un monde de plus en plus interconnecté.
Mots de passe peu sûrs
Lorsque vous utilisez une application, l’une des premières étapes consiste généralement à vous authentifier. Cela se fait généralement à l’aide d’une combinaison nom d’utilisateur/mot de passe. Et bien sûr, les exigences varient considérablement d’un site à l’autre. Il est assez courant de voir des exigences imposant l’utilisation de lettres majuscules et minuscules, auxquelles s’ajoutent parfois des chiffres et des caractères spéciaux. La longueur est également un facteur important. Une bonne règle à suivre consiste à choisir un mot de passe suffisamment long pour empêcher les attaques par force brute, et suffisamment complexe pour qu’il ne figure pas dans un dictionnaire. Une bonne longueur recommandée est d’au moins 10 caractères. De préférence bien plus.
Nous avons rencontré de nombreuses applications dont la seule exigence était une longueur de six caractères. Ainsi, un mot de passe tel que « 111111 » serait parfaitement acceptable. Même un ordinateur bas de gamme mettrait très peu de temps à déchiffrer le hachage de ce mot de passe. Sans compter qu’il figure probablement dans un dictionnaire, ce qui rendrait également tout à fait possible une attaque par force brute. Pour en savoir plus sur la manière dont les mots de passe sont piratés, cliquez ici.
Absence de mise en œuvre SSL sécurisée
SSLLabs est un outil très pratique pour évaluer l’état actuel de la mise en œuvre du protocole SSL :il est rapide, facile à utiliser et complet. Il existe également l’outilSSLChecker, une version plus simplifiée et plus facile à comprendre pour les non-initiés. Il offre en outre la possibilité de vérifier les en-têtes de sécurité SSL. Nous n’allons pas entrer ici dans tous les détails concernant la mise en œuvre SSL/TLS, car cela nécessiterait d’ajouter au moins plusieurs pages supplémentaires à cet article. Nous devrons donc y revenir dans un article distinct. Si vous souhaitez vraiment en savoir plus dès maintenant, il existe un autre outil très pratique. On l’appelle Google ; nous pensons qu’il commence à faire son chemin !Vous pouvez également n’hésitez pas à nouscontacter et nous veillerons à ce que vous obteniez les informations correctes.
Énumération des utilisateurs
Il existe plusieurs méthodes courantes permettant aux applications de vous laisser énumérer les utilisateurs valides. L’une des plus courantes et des plus simples consiste à utiliser la fonction de connexion. Un exemple : vous vous connectez à une application. Si vous saisissez le nom correct, mais que vous vous trompez de mot de passe, et que la réponse indique « le mot de passe est incorrect ». C’est un indice qui montre que l’utilisateur est bien valide. Si vous essayez un autre nom d’utilisateur (qui n’est pas valide) et que la réponse indique « Utilisateur non valide », vous pouvez alors facilement déterminer que le premier utilisateur était bel et bien valide.
Pour un pirate, ce serait une bonne occasion de tenter une attaque par force brute contre les utilisateurs de l’application. En effet, l’application vous indiquera si l’utilisateur est valide ou non.
Injection XSS/HTML/SQL
Le principal problème en 2017 et 2018 a été celui des injections de toutes sortes. Alors, que peut-on injecter ? Des requêtes SQL, des commandes du système d’exploitation, du contenu HTML, des pages entières de contenu et des scripts. Où peut-on injecter cela ? Partout où une saisie utilisateur est requise, ou là où les utilisateurs peuvent modifier des données, c’est-à-dire dans une zone de texte, un champ de nom d’utilisateur/mot de passe, des fonctions de recherche, des champs de commentaires et de retours d’expérience, des URL, etc.
Téléchargement de fichiers sans restriction
Les fichiers téléchargés peuvent avoir de graves répercussions sur l’application ainsi que sur le système de fichiers. On constate souvent qu’aucun filtre n’est appliqué aux types d’extensions de fichiers autorisés. Si seuls un ou deux types de fichiers sont nécessaires, tous les autres devraient figurer sur la liste noire.
Imaginons une application écrite en PHP, dans laquelle l’utilisateur peut télécharger une photo de profil. On pourrait supposer que cette fonction n’autorise que le téléchargement de fichiers image (JPG et PNG). Or, d’autres formats de fichiers sont également autorisés. Dans ce cas, comme nous avons affaire à PHP (et que PHP peut interagir directement avec le système d’exploitation), nous téléversons un bout de code PHP « amusant » qui nous permettra de communiquer directement avec le système de fichiers du serveur lui-même. Cela peut mener à des conséquences bien plus graves, telles que la compromission d’informations, voire une intrusion plus profonde dans le réseau.
Contrôles d’accès défaillants (sécurité par obscurité)
Cela se produit lorsque des vérifications adéquates ne sont pas effectuées sur l’ensemble du plan du site. Cela permet à un utilisateur d’accéder à des informations auxquelles ses droits d’accès ne devraient pas lui donner accès (ou sans aucune authentification). Imaginez que vous naviguiez sur votre application de gestion des feuilles de temps avec votre compte à faibles privilèges : la seule chose qui vous empêche d’approuver votre propre feuille de temps est essentiellement d’ordre esthétique. Le bouton d’approbation n’est pas visible pour votre compte, mais uniquement pour les administrateurs de l’application. Or, en réalité, si vous connaissiez les données de la requête, vous pourriez approuver vous-même la feuille de temps.
Dans cette application, vous et votre entreprise avez stocké certains documents internes contenant ce que l’on peut qualifier d’informations sensibles. Vous accédez à l’un des fichiers PDF et le téléchargez, après vous être authentifié. Si vous vous déconnectiez de l’application puis accédiez à cette même URL pour ce document, et que le fichier était accessible, cela constituerait une nouvelle preuve de défaillance des contrôles d’accès.
Segmentation insuffisante des utilisateurs/groupes (principe du privilège minimal)
Autorisations uniformes pour les utilisateurs et les groupes. Ce serait bien de vivre dans un monde où tout le monde serait égal. Mais en matière d’informatique, c’est absolument à proscrire, même si cela reste très courant. Tous les comptes d’une application ou d’un réseau disposent des mêmes privilèges, ce qui engendre le chaos, surtout si ces identifiants venaient à être compromis par un attaquant. Cela revient plus ou moins à donner à l’attaquant les clés du royaume, ce qui est communément considéré comme « une très mauvaise idée ». La question qu’il faut se poser ici est la suivante : Janice, de la comptabilité, a-t-elle réellement besoin d’accéder aux documents top secrets destinés à Leann et Kurt ? Les rôles des utilisateurs doivent être attribués selon le principe du « privilège minimal » : ce que vous n’avez pas besoin de savoir, vous ne devez tout simplement pas le savoir ni y avoir accès.
Mauvaise gestion des correctifs / Gestion de la fin de vie
L’épidémie de WannaCry/EternalBlue du 12 mai 2017 en est un excellent exemple. Des infrastructures du monde entier ont été touchées par cette vulnérabilité ; des entreprises de toutes tailles ont vu leurs serveurs et leurs ordinateurs infectés par un cryptolocker. SelonIBM X-Force,le préjudice total s'élèverait à plus de 8 milliards de dollars dans 150 pays, rien que pour l'incident WannaCry. Je pense que cela parle de soi : si vous gérez vous-même vos données et vos serveurs, vous pouvez contrôler quand et quels correctifs appliquer. Avec un prestataire tiers, vous n’avez aucune idée de ce qu’il fait. C’est pourquoi il s’agit d’une question pertinente à poser à tout prestataire tiers dont vous envisagez de faire appel aux services.
Segmentation insuffisante du réseau et des bases de données
Nous avons déjà rencontré des cas où l’on nous a affirmé que le réseau ou la base de données était correctement segmenté, du moins selon les personnes à qui nous avons parlé. Lorsque nous les avons recontactées quelque temps plus tard, nous avons démontré que ce n’était pas le cas. Il s’agissait d’applications dont les versions de pré-production et de production étaient stockées sur le même serveur que la base de données « correctement segmentée ». En réalité, la segmentation de la base de données se résumait à la présence de deux branches distinctes au sein d’une même base de données. Cela signifiait que la faille de type « injection SQL » détectée dans l’application de pré-production entraînait également la compromission totale de la base de données de production. Ce phénomène a également été observé dans des systèmes multi-locataires où les données de plusieurs entreprises sont toutes stockées dans la même base de données.
.png)
