analyzing-code-security

Flux de travail d'audit de sécurité

Suivez ces étapes lors de la réalisation d'un audit de sécurité manuel du code :

1. Identifiez la surface d'attaque. Déterminez les points d'entrée : endpoints API, gestionnaires de messages, parseurs de fichiers, formulaires visibles. Lisez les définitions de routes et les enregistrements de contrôleurs pour établir une cartographie.
2. Tracez les flux de données des sources aux puits. Suivez les entrées non fiables (paramètres HTTP, en-têtes, corps de requête, téléchargements de fichiers, réponses d'API externes) à travers toutes les transformations jusqu'aux opérations dangereuses (requêtes de base de données, exécution de commandes, rendu HTML, accès au système de fichiers).
3. Vérifiez les franchissements de limites de confiance. À chaque point où les données franchissent une limite de confiance (client→serveur, service→service, entrée utilisateur→base de données), vérifiez que la validation, l'authentification et l'autorisation sont appliquées.
4. Appliquez les listes de contrôle des frameworks. Consultez references/framework-checklists.md pour les OWASP Web/API/Mobile Top 10 et CWE Top 25. Vérifiez chaque catégorie applicable par rapport au code en cours d'examen.
5. Adoptez une mentalité adversariale. Formulez une hypothèse (par exemple, « Je peux contourner SSO », « Je peux accéder au coffre d'un autre utilisateur ») et travaillez en arrière pour déterminer quelles conditions la rendraient exploitable.
6. Associez les résultats à des identifiants CWE. Chaque résultat doit inclure l'identifiant CWE spécifique, l'emplacement du code et le flux de données qui le rend exploitable.
7. Classifiez par exploitabilité pratique. Distinguez les vulnérabilités pratiquement exploitables des risques théoriques. Priorisez en conséquence mais documentez les deux.

Catégories de vulnérabilités clés

Les catégories les plus fréquemment rencontrées dans la pile Bitwarden :

• Injection (CWE-89, CWE-78, CWE-77) — Entrées non désinfectées atteignant les requêtes SQL, commandes OS ou requêtes LDAP. Utilisez toujours des requêtes paramétrées et évitez la concaténation de chaînes.
• Contrôle d'accès défaillant (CWE-862, CWE-287, CWE-306) — Vérifications d'autorisation manquantes, IDOR, escalade de privilèges. Vérifiez les vérifications de propriété par objet et l'application des rôles à chaque niveau.
• XSS (CWE-79) — Entrée utilisateur rendue en HTML sans encodage. Dans Angular, évitez innerHTML et bypassSecurityTrust* avec du contenu non fiable.
• SSRF (CWE-918) — URLs contrôlées par l'utilisateur dans les requêtes côté serveur. Validez par rapport à des listes d'hôtes autorisés.
• Désérialisation non sécurisée (CWE-502) — Gestion de types activée sur une entrée non fiable. Évitez TypeNameHandling.All dans JSON.NET.
• Traversée de répertoire (CWE-22) — Chemins fournis par l'utilisateur atteignant les opérations du système de fichiers. Normalisez et validez par rapport à un répertoire de base.
• Défaillances cryptographiques — Algorithmes faibles, clés codées en dur, IV prévisibles. Consultez la skill reviewing-security-architecture pour les algorithmes approuvés.

Pour les listes de contrôle complètes des frameworks (toutes les catégories OWASP et CWE), consultez references/framework-checklists.md.

Pour des exemples de code CORRECT/INCORRECT en C#, TypeScript et SQL, consultez references/vulnerability-patterns.md.

Mentalité d'audit adversarial

Adoptez une mentalité adversariale lors de l'audit de sécurité du code — cela diffère de l'examen de code régulier qui cherche à renforcer le code.

Comment penser de manière adversariale :

1. Créez une hypothèse — par exemple, « Je peux contourner SSO », « Je peux accéder au coffre d'un autre utilisateur », « Je peux escalader de membre à administrateur »
2. Travaillez en arrière — Quelles conditions devraient être vraies pour que l'attaque réussisse ? Ces conditions peuvent-elles être fabriquées ?
3. Questionnez les hypothèses — Cette vérification d'autorisation est-elle toujours atteinte ? Que se passe-t-il si le middleware échoue ? Que se passe-t-il si le token est mal formé mais pas invalide ?
4. Considérez les modes de défaillance — Que se passe-t-il quand les choses échouent ? Échouent-elles de manière ouverte (non sécurisée) ou fermée (sécurisée) ?

Règles critiques

• Authentification avant autorisation. Vérifiez toujours que l'utilisateur est qui il prétend être avant de vérifier ce qu'il est autorisé à faire. Ne sautez jamais les vérifications d'authentification sur les endpoints « internes ».
• Validez aux limites de confiance. Chaque point où les données franchissent une limite de confiance (client→serveur, service→service, entrée utilisateur→base de données) doit valider. Ne faites jamais confiance à la validation côté client seule.
• Associez les résultats à des identifiants CWE. Chaque résultat doit inclure un identifiant CWE spécifique avec preuve : l'emplacement du code et le flux de données qui le rend exploitable.
• Pratique plutôt que théorique. Distinguez les vulnérabilités pratiquement exploitables dans ce système des risques théoriques. Priorisez en conséquence mais documentez les deux.
• Vérifiez la chaîne complète. Une vulnérabilité n'est pas seulement le puits — tracez de la source (entrée utilisateur) à travers toutes les transformations jusqu'au puits (opération dangereuse). Si la chaîne est brisée par la désinfection, elle n'est pas exploitable.

Ressources supplémentaires

Fichiers de référence

Pour des listes de contrôle détaillées et des exemples de code, consultez :

• references/framework-checklists.md — OWASP Web Top 10, API Top 10, Mobile Top 10 (2024), tables de recherche CWE Top 25
• references/vulnerability-patterns.md — Exemples de code CORRECT/INCORRECT pour C#/.NET, TypeScript/Angular et SQL