Codage sécurisé, dans le code.
ISO 27001:2022 A.8.28 (codage sécurisé) consiste à appliquer des principes de codage sécurisé afin que les logiciels ne contiennent pas les types de failles exploitées par les attaquants : injection, gestion non sécurisée des entrées et sorties, valeurs par défaut non sécurisées. Parmi tous les contrôles de l'annexe A, c'est celui qui s'applique le plus directement au code, ce qui fait de la pull request l'endroit naturel pour le vérifier.
The shapes the same control failure takes.
A.8.28 est affaibli lorsqu'une modification introduit un motif connu comme dangereux ou supprime une protection contre celui-ci. Les motifs récurrents :
Une requête est construite par concaténation de chaînes
L'entrée utilisateur est interpolée directement dans une chaîne SQL, shell ou de requête au lieu d'être passée en paramètre, ouvrant ainsi une voie à l'injection.
La sortie est rendue sans échappement
Des données contrôlées par l'utilisateur sont écrites dans du HTML, un modèle ou une réponse sans échappement, ouvrant une voie à l'exécution de scripts inter-sites.
Une vérification ou un linter de sécurité est désactivé
Une règle d'analyse statique ou un linter de sécurité est désactivé (une ignore en ligne, une règle désactivée) pour faire passer une modification plutôt que de corriger ce qu'il a signalé.
Une entrée non fiable est désérialisée
Des données provenant de l'extérieur de la frontière de confiance sont désérialisées en objets ou évaluées, un motif classique d'exécution de code à distance.
La validation est supprimée
La validation ou l'assainissement des entrées qui protégeait un chemin est supprimé lors d'un refactoring, permettant ainsi à des entrées malformées ou hostiles d'atteindre la logique sous-jacente.
Une requête assemblée à partir d'une entrée utilisateur.
Une fonctionnalité de recherche est ajoutée. La méthode la plus rapide pour filtrer selon le terme de l'utilisateur consiste à l'insérer directement dans la chaîne SQL. Cela fonctionne pour des entrées normales, mais cela constitue une injection SQL : un terme spécialement conçu peut lire ou modifier des donnéesqu'il ne devrait jamais atteindre.
- const rows = await db.query("SELECT * FROM items WHERE name = $1", [term])+ const rows = await db.query(`SELECT * FROM items WHERE name = '${term}'`)return rowsL'interpolation du terme de recherche dans la chaîne SQL crée une voie d'injection SQL : un terme spécialement conçu peut sortir de la chaîne et s'exécuter comme logique de requête. A.8.28 (codage sécurisé) exige précisément que ce type de faille soit évité. Revenez à une requête paramétrée, qui maintient l'entrée comme donnée plutôt que comme code.
Le codage sécurisé est vérifié au niveau des pratiques et du code.
Un auditeur recherche des preuves que le codage sécurisé fait partie de votre processus : revue de code, analyse statique, analyse des dépendances, et que les résultats sont pris en compte. Une modification qui introduit une voie d'injection ou désactive une vérification de sécurité est l'échec concret derrière ce processus, et il est visible dans le diff. Le fait de le détecter lors de la revue constitue à la fois la correction et la preuve que la pratique fonctionne.
Une revue, pas une suite SAST complète.
heygrc signale les modifications qui concernent A.8.28 et cite le contrôle afin que la correction ait lieu dans la pull request. Ce n'est pas un remplacement pour votre analyse statique ou vos tests de sécurité ; c'est la couche consciente du cadre qui relie une faille de codage sécurisé au contrôle qu'elle enfreint.