Dès que votre site web, mini-programme ou App fournit des services externes, il sera immanquablement scanné, sondé et attaqué ; la seule différence est de savoir si cela a été détecté ou non. De nombreuses équipes concentrent toute leur énergie sur le développement fonctionnel et la rapidité de mise en production, tout en repoussant sans cesse les tests de sécurité. Résultat : une interface sujette à l'élévation de privilèges ou un point d'upload suffit à faire tomber tout le système. Dans ses services de tests de sécurité et de tests de reverse engineering de longue durée, MIC Studio observe sans cesse la même règle : ce qui perce réellement un système n'est souvent pas une technologie très sophistiquée, mais plusieurs catégories de vieux problèmes négligés. Cet article explique en profondeur les vulnérabilités les plus courantes dans les tests de sécurité web et fournit des recommandations de renforcement directement applicables.
I. Clarifier d'abord les objectifs et le périmètre des tests de sécurité
Un test de sécurité ne consiste pas à acheter une suite de scanners, à l'exécuter une fois et à rendre sa copie. Il doit répondre à trois questions : par quelle entrée l'attaquant peut-il pénétrer ? Une fois entré, que peut-il obtenir ? Et après l'avoir obtenu, quel niveau de dégâts peut-il causer ?
Selon la méthode de test, on distingue généralement trois catégories :
- Test en boîte noire : simule entièrement un attaquant externe, sans disposer du code source ni de comptes, ce qui se rapproche le plus d'un scénario d'attaque réel ;
- Test en boîte blanche : combine l'audit du code source et permet de découvrir des problèmes logiques profonds que la boîte noire ne peut pas détecter ;
- Test en boîte grise : dispose d'une partie des comptes ou de la documentation des interfaces, avec la meilleure efficacité, adapté aux projets à itérations fréquentes.
Pour la plupart des projets de petite et moyenne taille, il est plus rentable de tester en priorité la couche interface et la couche permissions. En effet, ces deux parties posent le plus souvent problème et les conséquences sont les plus graves : fuite de données, opérations non autorisées, prise de contrôle du back-office, tout commence généralement là.
II. Injection SQL : un vieux problème, toujours un tueur numéro un
L'injection SQL existe depuis plus de vingt ans, mais reste encore aujourd'hui un habitué des classements de vulnérabilités. La raison est simple : dès qu'une requête SQL est construite par concaténation, elle peut être exploitée.
Scénarios typiques :
- L'interface de connexion utilise une concaténation de chaînes pour interroger l'utilisateur ; saisir `' or '1'='1` contourne directement le mot de passe ;
- Les champs de tri et les conditions de recherche d'une requête de liste sont directement concaténés dans le SQL, entraînant une injection par erreur ou une injection temporelle aveugle ;
- Certains anciens systèmes utilisent un ORM mais concatènent du SQL natif, ce qui présente également un risque.
Recommandations de renforcement :
- Utiliser systématiquement des requêtes paramétrées (instructions précompilées) et interdire la concaténation de chaînes SQL au niveau des normes de code ;
- Pour les champs de tri, noms de tables et autres emplacements non paramétrables, utiliser une validation par liste blanche en n'autorisant que des valeurs prédéfinies ;
- Le compte de base de données doit suivre le principe du moindre privilège ; le compte métier ne doit pas disposer de privilèges à haut risque tels que DROP, FILE, GRANT ;
- Désactiver l'affichage détaillé des erreurs en production pour éviter de divulguer la structure des tables et la version de la base de données ;
- Introduire un WAF comme ligne de défense complémentaire, mais ne pas en faire l'unique protection.
III. XSS (cross-site scripting) : l'injection la plus longtemps latente
L'essence du XSS est qu'une entrée utilisateur est exécutée comme du code. Le XSS stocké est le plus dangereux, car il reste longtemps dans la page et affecte chaque visiteur.
Scénarios typiques :
- Les commentaires, pseudonymes et signatures personnelles sont directement affichés dans la page ;
- L'éditeur de texte enrichi autorise les balises `