Les problèmes les plus courants en matière de sécurité informatique

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é.

Les mauvais mots de passe

When using an application, one of the first things that you run into will be some sort of authentication. This is usually a username and password combination. And of course, the requirements differ greatly from site to site. It is quite common to see requirements for upper- and lower-case letters, plus maybe some numbers and special characters thrown in as well. Length is also a major factor. A good guideline to follow is to keep it long enough to prevent brute forcing and complex enough that it will not show up in a dictionary. A good, recommended length is a minimum of AT LEAST 10 characters. Preferably much more. 

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

L'absence de mise en œuvre solide du protocole SSL 

Un outil astucieux pour évaluer l'état actuel de l'implémentation de SSL, SSL Labs is quick, easy to use, and comprehensive. There is also the tool  SSL Checker , a more simplified version and easier for a non-technical to understand. It also offers the added caveat of checking SSL Security Headers. Now we will not go into all the details concerning the SSL/TLS implementation, that would require at least several more pages to this post. So, we will have to return with a separate post about it. If you really want to know more right now, then there is another nifty tool. They call it Google; we think it is starting to catch on! Or contactret nous ferons en sorte que vous obteniez des informations correctes. 

 

L'énumération des utilisateurs 

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. 

 

Injection XSS/HTML/SQL 

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. 

 

Unrestricted file upload 

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. 

 

Contrôles d'accès défaillants (sécurité par l'obscurité) 

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.

 

Faible segmentation des utilisateurs/groupes (pratique du moindre privilège) 

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.  

 

Mauvaise gestion des correctifs / de la fin de vie 

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.  

 

Faible segmentation du réseau/de la base de données 

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.  

If you want to know more about the most common attacks and how to bring security into the development process, be sure to join our webinar in September where we will delve into these key areas. Register below. 

À PROPOS DE L'AUTEUR

Mattias-Recruiting

De nature très sympathique, Mattias Döj aime rencontrer et accueillir de nouvelles personnes. Au cours de sa carrière dans le domaine de la sécurité informatique, il a travaillé à l'échelle internationale et a voyagé dans le monde entier pour effectuer divers tests d'intrusion.

Replay Webinar

Focus : sécurité des applications

La plupart d’entre nous comprennent que la sécurité est importante, mais ne savent pas vraiment comment et par où commencer. Dans ce webinaire, nous parlerons de la sécurité des applications en mettant l’accent sur l’intégration de la sécurité dans le processus de développement, les attaques courantes,…

FAQ

Une question sur la cybersécurité ?

Pour éviter d’exposer son système à des dangers, il est nécessaire de sécuriser les applications, mais vous ne savez peut-être pas comment vous y prendre. Nous sommes là pour répondre à vos questions les plus fréquentes sur ce sujet.

Nos recommandations