Techniques de revue de code sécurisée

La revue de code sécurisée permet d'identifier les vulnérabilités de sécurité dans le code source avant le déploiement. Contrairement à la revue fonctionnelle du code, elle se concentre sur les limites de confiance, les flux de données, les API dangereuses, les contrôles manquants et les erreurs de logique de sécurité, et non sur la justesse ou le style.

Les outils SAST automatisés (Semgrep, SonarQube, CodeQL) détectent rapidement les motifs connus, mais ne repèrent pas les défauts de logique métier, les vulnérabilités complexes impliquant plusieurs composants ni les problèmes dépendant du contexte. La revue manuelle détecte ce que l'automatisation ne voit pas. Les deux sont nécessaires.

Commencez la revue de sécurité en répertoriant tous les points d'entrée : points d'accès HTTP, gestionnaires de files de messages, téléversements de fichiers, tâches planifiées, rappels Web et arguments de CLI. Chaque point d'entrée qui accepte des données externes est un point d'injection potentiel qui exige un examen attentif.

Suivez les données contrôlées par l'utilisateur depuis leur point d'entrée jusqu'à leur utilisation finale dans l'application. Atteignent-elles une requête de base de données ? Une commande système ? Un modèle HTML ? Un appel d'API ? Suivez le flux de données et vérifiez chaque étape de transformation et d'assainissement.

Les décisions de sécurité sont prises aux limites de confiance, là où les données passent d'un contexte moins fiable (une requête HTTP) à un contexte plus fiable (une base de données, le système d'exploitation). Chaque franchissement d'une limite de confiance doit valider, assainir ou autoriser les données.

Signalez les utilisations de : eval(), exec(), system(), shell_exec(), innerHTML, dangerouslySetInnerHTML, deserialize(), pickle.loads(), Runtime.exec(), ProcessBuilder, les analyseurs XML dont l'expansion des entités n'est pas désactivée et les primitives cryptographiques utilisées directement au lieu d'API de haut niveau.

Vérifiez les points suivants : chaque point d'accès sensible est-il protégé par une authentification ? L'autorisation est-elle vérifiée côté serveur pour chaque action ? Un utilisateur peut-il accéder aux données d'un autre utilisateur en modifiant un paramètre ID (IDOR) ? Les opérations sensibles sont-elles protégées contre les CSRF ?

Recherchez les blocs de gestion des exceptions qui ignorent silencieusement les exceptions. Vérifiez que les messages d'erreur affichés aux utilisateurs ne révèlent ni chemins internes, ni traces de pile, ni structure de la base de données. Vérifiez que les exceptions de sécurité (AuthenticationException) sont journalisées et non ignorées discrètement.

Signalez les éléments suivants : l'utilisation de MD5 ou SHA-1 pour le hachage des mots de passe (utilisez bcrypt ou Argon2), les clés symétriques ou vecteurs d'initialisation codés en dur, le chiffrement en mode ECB (utilisez GCM ou CBC avec HMAC), les implémentations cryptographiques personnalisées et les générateurs de nombres aléatoires qui ne sont pas sûrs sur le plan cryptographique.

Examinez package.json/pom.xml pour repérer les dépendances obsolètes. Vérifiez dans la configuration de l'application que le mode de débogage n'est pas activé en production, que les pages d'erreur ne sont pas trop détaillées, qu'aucun identifiant administrateur ne figure dans les fichiers de configuration et qu'aucun en-tête de sécurité ne manque (HSTS, CSP, X-Frame-Options).

Les règles Semgrep mettent en correspondance des motifs syntaxiques en tenant compte de leur sémantique. Écrivez des règles personnalisées pour les motifs propres à votre base de code. CodeQL considère le code comme des données : écrivez des requêtes sur l'AST pour trouver les flux de données des sources vers les puits à travers les fichiers et les appels de fonctions.

Qu'est-ce qu'une vulnérabilité IDOR et où la rechercheriez-vous lors d'une revue de code ?

Une revue de code sécurisée efficace combine la cartographie des points d'entrée, le traçage des flux de données, l'analyse des limites de confiance, la détection des API dangereuses et les outils SAST automatisés. Elle détecte les problèmes de sécurité qui échappent à la revue fonctionnelle, en particulier les défauts de logique métier et les lacunes subtiles dans l'autorisation.