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

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

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. 

Téléchargement de fichiers sans restrictions

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.