02 • 34 • 09 • 31 • 70
Qu’est-ce qu’une faille de sécurité ?
Une faille de sécurité ou vulnérabilité, désigne en informatique toute faiblesse d’un système (ex : une application web), qui permettrait à une personne potentiellement malveillante d'altérer le fonctionnement normal du système ou encore d'accéder à des données non autorisées.
L’origine est généralement involontaire et peut résider dans la conception du logiciel ou un problème plus profond au niveau matériel.
Quelles sont les failles majeures ?
Les failles de sécurité sont des éléments importants à prendre en compte dans le développement de tout projet informatique. Un ensemble de bonnes pratiques et de réflexions permet déjà de s’en prémunir naturellement.
Le OWASP, ou Open Web Application Security Project, est une fondation qui publie et préconise un ensemble d’informations concernant les failles de sécurité sur le WEB.
Elle publie notamment un top 10 des failles de sécurité tous les 3/4 ans. Le dernier en date, de 2017, reprend les failles suivantes comme failles majeures :
Les injections
Une injection consiste à envoyer et faire exécuter du code par le serveur. L’idée est de capitaliser sur une faiblesse dans l’écriture du code de la partie backend permettant à un utilisateur de récupérer des données auxquelles il n’est pas censé avoir accès.
Un exemple classique est celui des injections SQL. L’exemple ci-dessous illustre une possible faille en altérant la requête SQL générée de son objectif initial, si l’utilisateur lui passe des paramètres non contrôlés.
Ainsi, si l'argument qu'envoie l'utilisateur est équivalent à ceci :
Une requête permettant de supprimer toutes les données pourra être exécutée :
Broken Authentication
Les failles de sécurité les plus répondues sont souvent les plus simples et exploitent parfois même les failles humaines via par exemple des “scam” ou arnaque visant à récupérer le mot de passe de l’utilisateur que celui-ci saisit délibérément croyant être sur un site bienveillant.
Cette faille comprend l’utilisation de mot de passe connu ou suffisamment faible (peu de complexité) pour qu’un logiciel puisse le retrouver facilement. Ou encore que justement le système d’authentification d’un système repose uniquement sur un mot de passe et non un couple mot de passe/validation par téléphone par exemple.
L'exposition de données sensibles
L’idée est ici pour un attaquant d'accéder ou d'altérer des données mal protégées. Il est très important, par exemple, de bien chiffrer les mots de passe stockés dans la base de données de son projet. En effet, même si demain une personne réussit à accéder à la base de données, il est important que celui-ci ne puisse pas lire ou déchiffrer les mots de passe suffisamment chiffrés, et ainsi limiter la valeur du butin que celui-ci aurait récupéré.
XML External Entities (XXE)
La communication entre deux éléments basés sur des échanges XML est un processus relativement ancien, bien qu'évidemment toujours utilisé. (Voir article : API REST vs SOAP vs Graph). Par extension de cela, il arrive que ce soit de vieux systèmes et potentiellement mal configurés qui utilisent cette technologie.
Il devient alors possible d’envoyer des XML contenant du code malicieux, permettant, au choix : de récupérer des fichiers (clé de chiffrement de mot de passe par exemple), d'accéder à des ressources privées ou encore de générer des attaques par déni de service sur la lecture de fichier potentiellement très grand.
Broken Access Control
Là encore, l’idée est assez simple : essayer d'accéder à des ressources non autorisées. Il arrive dans certaines applications que la gestion des rôles et les niveaux de sécurité soient mal implémentés. Ainsi, on peut imaginer, par exemple, un cas d’usage où une page est censée être uniquement accessible aux administrateurs. Pour aller sur cette page, l’utilisateur doit d’abord passer par un écran de connexion. Or, la faille pourrait résider dans le fait que si une personne rentre l’URL finale de destination, ici n’est pas le lieu la vérification du rôle d’administrateur et que donc la page soit accessible par tous.
Mauvaise configuration de sécurité
Des services mal configurés sont source de potentielles failles de sécurité. Il est parfois nécessaire de court-circuiter certains comportements de son application (ex : authentification en “dur”) lors du développement afin de faciliter le développement de celle-ci. Il est impératif de retirer ce genre de comportement lors d’une phase de production.
Il peut s’agir de code d’exemple laissé en place, qui fait office de démonstration en développement mais qui sont de véritables portes ouvertes en production. Ou encore, laisser l'accès à l’exploration du répertoire de l’application et ainsi rendre possible pour un attaquant de récupérer les codes sources.
Cross-Site Scripting XSS
Dans une application web dans laquelle l’utilisateur peut entrer des informations (ex : un forum) et que celles-ci peuvent générer donc du HTML ou JS à afficher sur d’autres pages, (ex : un commentaire, etc.), des failles XSS peuvent être présentes. L’idée est que grâce à ces entrées utilisateurs, une personne malveillante puisse inscrire du code qui pourrait être exécuté par d’autres utilisateurs sur leurs postes. Il devient alors possible de rediriger l'utilisateur vers un autre site, ou encore de lui voler ses cookies de connexion.
Désérialisation non sécurisée
Dans le cas d’une application moderne, le fonctionnement est généralement le suivant : une partie front communique avec avec une partie back via des API. Pour authentifier l’utilisateur, la partie back renvoie au front un token unique d’authentification. Ce jeton contient l’ensemble des informations de l’utilisateur : nom, rôles, etc. Si le jeton parvient à être déchiffré puis rechiffré grâce à une clé de chiffrement faible, il devient possible alors de modifier son rôle dans l’application et d’avoir accès à des ressources d’administrateur.
Utilisation de composants avec des failles de sécurité connues
Le problème s’explique de lui-même, il ne faut pas utiliser des composants ayant des failles de sécurité connues, et si c’est déjà le cas, il faut chercher à mettre à jour ou changer les composants en question.
Manque d'administration et de log
Bien qu’il ne s’agisse pas d’une faille en soi, le manque d’outil de supervision est un véritable problème dans la lutte, la recherche et la résolution d’une faille de sécurité. Comment trouver la source d’un problème sans données analytiques, et pire encore, comment être au courant de la présence d’une faille qui est actuellement exploitée ?
Les failles ont toujours existé dans les systèmes informatiques et existeront toujours. Le cœur de l’erreur est souvent humain, et la meilleure solution pour s’en prémunir est d’être au courant, rigoureux dans son travail et de prendre les mesures nécessaires. C’est ici que Next Decision intervient pour la réalisation de projets sécurisés.
Notre équipe Next Decision est à votre écoute pour réaliser de vos projets sécurisés ! Contactez-nous !