La plupart des produits que vous achetez sont destinés à la sécurité des réseaux et des points d'accès. Ils ne seront pas très efficaces contre les vulnérabilités des applications web. Dans cet article, nous mettons donc en lumière les problèmes les plus courants que nous rencontrons dans notre travail, de la faiblesse du réseau à l'énumération des utilisateurs. Comprendre ces défis est essentiel non seulement pour les professionnels de l'informatique, mais aussi pour les individus et les organisations qui s'efforcent d'améliorer leur sécurité dans un monde de plus en plus interconnecté.
Lorsque vous utilisez une application, l'une des premières choses que vous rencontrez est une sorte d'authentification. Il s'agit généralement d'une combinaison de nom d'utilisateur et de mot de passe. Bien entendu, les exigences varient considérablement d'un site à l'autre. Il est assez courant de voir des exigences concernant les lettres majuscules et minuscules, ainsi que des chiffres et des caractères spéciaux. La longueur est également un facteur important. Une bonne ligne de conduite à suivre est de le garder suffisamment long pour éviter le forçage brutal et suffisamment complexe pour qu'il n'apparaisse pas dans un dictionnaire. Une bonne longueur recommandée est un minimum d'AU MOINS 10 caractères. De préférence beaucoup plus.
Nous avons rencontré de nombreuses applications dans lesquelles la seule exigence était une longueur de six caractères. Ainsi, un mot de passe tel que "111111" serait parfaitement acceptable. Il faudrait peu de temps, même à un ordinateur bas de gamme, pour déchiffrer un hachage de ce mot de passe. De plus, ce mot de passe figure probablement dans un dictionnaire, de sorte qu'il serait tout à fait possible de le forcer brutalement. Pour en savoir plus sur la manière dont les mots de passe sont déchiffrés, cliquez ici.
Un outil astucieux pour évaluer l'état actuel de l'implémentation de SSL, SSL Labs est rapide, facile à utiliser et complet. Il existe également l'outil SSL Checker, une version plus simplifiée et plus facile à comprendre pour un non-technicien. Il offre également la possibilité de vérifier les en-têtes de sécurité SSL. Nous n'allons pas entrer dans tous les détails concernant l'implémentation de SSL/TLS, cela nécessiterait au moins plusieurs pages supplémentaires à ce billet. Nous devrons donc revenir avec un article séparé à ce sujet. Si vous voulez vraiment en savoir plus tout de suite, il existe un autre outil astucieux. Ils l'appellent Google ; nous pensons qu'il commence à faire son chemin ! Ou contactez-nous et nous ferons en sorte que vous obteniez des informations correctes.
Les applications vous permettent d'énumérer les utilisateurs valides de plusieurs manières. L'une des plus courantes et des plus faciles à réaliser est la fonction de connexion. Un exemple : Vous vous connectez à une application. Si vous tapez le bon nom, mais que vous vous trompez dans le mot de passe et que la réponse indique "le mot de passe est incorrect", il s'agit d'un indice que l'utilisateur n'est pas valide. C'est un indice que l'utilisateur est un utilisateur valide. Si vous essayez un autre nom d'utilisateur (qui n'est pas valide) et que la réponse indique "Pas un utilisateur valide", vous pouvez facilement déterminer que le premier utilisateur était en fait un utilisateur valide.
Pour un hacker, ce serait une bonne occasion d'essayer de forcer les utilisateurs de l'application. L'application répondra et vous informera si l'utilisateur est valide ou non.
La question numéro un de 2017 et 2018 a été celle des injections de toutes sortes. Qu'est-ce qui peut être injecté ? Des requêtes SQL, des commandes OS, du contenu HTML, des pages entières de contenu et des scripts. Où quelqu'un pourrait-il injecter cela ? Partout où une entrée utilisateur est requise, ou où les utilisateurs peuvent modifier des données, c'est-à-dire une zone de texte, un champ de nom d'utilisateur/mot de passe, des fonctions de recherche, des champs de commentaires et de rétroaction, des URL, etc.
Les fichiers téléchargés peuvent avoir de graves répercussions sur l'application et le système de fichiers. On constate souvent qu'il n'y a pas de filtre sur les types d'extensions de fichiers qui peuvent être téléchargés. Si seuls un ou deux types de fichiers sont nécessaires, tous les autres devraient figurer sur la liste des indésirables.
Imaginez 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 images (JPG et PNG). Mais d'autres formats de fichiers peuvent également être téléchargés. Dans ce cas, puisque nous avons affaire à PHP (et que PHP peut interagir directement avec le système d'exploitation), nous téléchargeons un code PHP amusant qui nous permettra de communiquer directement avec le système de fichiers du serveur lui-même. Cela peut conduire à des choses problématiques telles que la compromission d'informations et l'accès potentiel à des parties plus profondes du réseau.
Cela se produit lorsque des vérifications appropriées ne sont pas effectuées pour l'ensemble du plan du site. Cela permet à un utilisateur d'accéder à des informations que ses permissions ne devraient pas autoriser (ou de manière totalement non authentifiée). Imaginez que vous naviguez dans votre application de relevé d'heures avec votre compte à faible privilège, la seule chose qui vous empêche d'approuver votre propre relevé d'heures est essentiellement d'ordre cosmétique. Le bouton d'approbation n'est pas visible par votre compte, mais uniquement par les administrateurs de l'application. En réalité, si vous connaissiez les données de la demande, vous pourriez approuver le rapport d'activité vous-même.
Dans cette application, vous et votre entreprise avez stocké des documents internes contenant ce que l'on peut appeler des informations sensibles. Vous accédez à l'un des fichiers PDF et le téléchargez, après vous être authentifié. Si vous vous déconnectez de l'application et que vous accédez ensuite à la même URL pour ce document, et que le fichier est accessible, cela prouverait une fois de plus que les contrôles d'accès ont été rompus.
Permissions uniformes pour les utilisateurs et les groupes. Il serait agréable de vivre dans un monde où tous seraient égaux. Dans le domaine de l'informatique, c'est un non-sens absolu, mais c'est encore très courant. Tous les comptes d'une application ou d'un réseau ont les mêmes privilèges, ce qui entraîne le chaos, surtout si ces informations d'identification sont compromises par un pirate. Cela revient plus ou moins à donner à l'attaquant les clés du royaume et c'est ce que l'on appelle plus communément "une mauvaise idée". Ce qu'il faut se demander ici, c'est si Janice, de la comptabilité, a 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 la pratique du moindre privilège : ce que vous n'avez pas besoin de savoir, vous ne devez tout simplement pas le savoir ou y avoir accès.
L'épidémie WannaCry/EternalBlue du 12 mai 2017 est un excellent exemple de ce problème. Des infrastructures du monde entier ont été touchées par cette vulnérabilité, des entreprises de différentes tailles ont vu leurs serveurs et ordinateurs infectés par un cryptolocker. Les dommages totaux signalés s'élèvent à plus de 8 milliards de dollars dans 150 pays, rien que pour l'incident WannaCry, selon IBM X-Force. Je pense que cela se passe de commentaires : si vous gérez vos propres données et serveurs, vous pouvez contrôler quand et ce qu'il faut corriger. Avec un fournisseur tiers, vous n'avez pas la moindre idée de ce qu'il fait. C'est pourquoi c'est une bonne question à poser à tout fournisseur tiers que vous envisagez d'utiliser.
Il est arrivé que l'on nous dise que le réseau ou la base de données était correctement segmenté, du moins d'après les personnes à qui nous avons parlé. Lorsque nous les recontactons quelque temps plus tard, nous avons la preuve que ce n'est pas le cas. Applications où la version de pré-production et la version de production sont stockées sur le même serveur que la base de données "correctement segmentée". La segmentation réelle de la base de données n'était en fait que deux branches distinctes dans la même base de données. Cela signifie que l'injection SQL trouvée dans l'application de pré-production a également conduit à une compromission totale de la base de données de production. Cette situation a également été observée dans le cas de systèmes multi-locataires dans lesquels les données de plusieurs entreprises sont toutes stockées dans la même base de données.