Les causes les plus courantes

La cause principale des failles est tout simplement le manque de filtrage des données et la trop grande confiance accordée aux utilisateurs par le développeur. Il est primordial de filtrer chaque donnée aussi bien en entrée qu’en sortie et d’en vérifier la structure et le contenu. En effet, puisque le développeur connaît le type de données attendu et les caractères possibles dans cette donnée, il lui suffit alors de vérifier le type ainsi que les caractères présents pour en déterminer la validité. Pour cela, l’utilisation des “Expression régulières” est un bon moyen. Une grande majorité des failles pourraient ainsi être évitées. Certes, cela représente beaucoup de travail pour le développeur qui n’a pas toujours le temps de se pencher sur la question “sécurité” et qui s’assure avant tout du bon fonctionnement de son développement pour respecter les délais de livraison. Or, il est plus simple de corriger une vulnérabilité en amont qu’en aval. Une autre cause concerne l’utilisation des données par défaut, que ce soit dans un CMS, un serveur Web, un serveur de base de données ou autre. Trop souvent, par manque de temps, les administrateurs systèmes et les développeurs occultent ces paramètres. On retrouve donc des serveurs de base de données exécutés avec des paramètres “root” accordant au pirate, en cas d’injection SQL, une totale liberté d’action autour des serveurs Web dont l’affichage des bannières est activé, où le “Directory Listing” est activé, les sessions non protégées. Dans le cas du “PHP”, on remarque également des options critiques activées, comme l’inclusion de fichier distant, l’exécution de commande système, l’affichage de la version installée, l’affichage des messages d’erreurs, etc. Dans certains cas, nous observons même des “Web applications” dont les identifiants administrateur sont “root / password”. L’affichage des versions installées du serveur Web, de la base de données et des langages de développement permettra à un pirate d’aller directement rechercher les vulnérabilités connues pour ces versions et de les exploiter. Nous rencontrons aussi de nombreux sites dont les messages d’erreurs sont affichés en clair. A priori, pour la plupart des développeurs, cela ne constitue simplement qu’un “design” perturbé, mais pour les “hackers” en revanche, cela représente bien plus. En effet, dans le cas d’une “SQL Injection” si les erreurs SQL sont affichées, le pirate connaîtra alors la structure de la requête, le type et le nom des données attendues et économisera 80% de temps de recherche pour exploiter la faille. L’un des gros points noirs des outils “CMS” est qu’ils sont pour la plupart “Open Source”. En conséquence, un pirate peut facilement analyser le code source à la recherche de failles pendant des journées entières qu’il exploitera ensuite sur un site utilisant le même “CMS”.