Bonnes pratiques de sécurité

Vue d'ensemble

Cette skill fournit une description de comment identifier le langage et les frameworks utilisés par le contexte actuel, puis charger les informations du répertoire de références de cette skill concernant les bonnes pratiques de sécurité pour ce langage et/ou ces frameworks.

Ces informations, si présentes, peuvent être utilisées pour écrire du code sécurisé par défaut, ou pour détecter passivement les problèmes majeurs dans du code existant, ou (si demandé par l'utilisateur) fournir un rapport de vulnérabilité et suggérer des corrections.

Workflow

L'étape initiale pour cette skill est d'identifier TOUS les langages et TOUS les frameworks que vous êtes invité à utiliser ou qui existent déjà dans le périmètre du projet sur lequel vous travaillez. Concentrez-vous sur les frameworks core principaux. Souvent vous voudrez identifier à la fois les langages et frameworks frontend et backend.

Ensuite, vérifiez le répertoire de références de cette skill pour voir s'il existe de la documentation pertinente pour le langage et/ou les frameworks. Assurez-vous de lire TOUS les fichiers de référence qui se rapportent au framework ou langage spécifique. Le format des noms de fichiers est <language>-<framework>-<stack>-security.md. Vous devriez aussi vérifier s'il existe un fichier <language>-general-<stack>-security.md qui est agnostique au framework que vous pourriez utiliser.

Si vous travaillez sur une application web qui inclut un frontend et un backend, assurez-vous d'avoir vérifié les documents de référence pour LE FRONTEND ET LE BACKEND !

Si on vous demande de créer une web app qui inclura à la fois un frontend et un backend, mais que le framework frontend n'est pas spécifié, consultez aussi javascript-general-web-frontend-security.md. Il est important que vous compreniez comment sécuriser à la fois le frontend et le backend.

Si aucune information pertinente n'est disponible dans le répertoire de références de la skill, réfléchissez un peu à ce que vous savez sur le langage, le framework, et toutes les bonnes pratiques de sécurité bien connues pour celui-ci. Si vous n'êtes pas sûr, vous pouvez essayer de rechercher en ligne de la documentation sur les bonnes pratiques de sécurité.

À partir de là, elle peut fonctionner de plusieurs façons.

1. Le mode principal est simplement d'utiliser les informations pour écrire du code sécurisé par défaut à partir de ce moment. C'est utile pour démarrer un nouveau projet ou lors de l'écriture de nouveau code.

2. Le mode secondaire est de détecter passivement les vulnérabilités tout en travaillant dans le projet et en écrivant du code pour l'utilisateur. Les vulnérabilités critiques ou très importantes ou les problèmes majeurs allant à l'encontre des conseils de sécurité peuvent être signalés et l'utilisateur peut en être informé. Ce mode passif devrait se concentrer sur les vulnérabilités ayant le plus grand impact et les défauts de sécurité.

3. L'utilisateur peut demander un rapport de sécurité ou l'amélioration de la sécurité de la base de code. Dans ce cas, un rapport complet doit être produit décrivant toutes les façons dont le projet ne suit pas les conseils des bonnes pratiques de sécurité. Le rapport doit être priorisé et avoir des sections claires de sévérité et d'urgence. Ensuite, proposez de commencer à travailler sur les corrections de ces problèmes. Voir la section #fixes ci-dessous.

Arbre de décision du workflow

• Si le langage/framework n'est pas clair, inspectez le repo pour le déterminer et listez vos preuves.
• Si des conseils correspondants existent dans references/, chargez uniquement les fichiers pertinents et suivez leurs instructions.
• Si aucun conseil correspondant n'existe, réfléchissez à ce que vous connaissez sur les bonnes pratiques de sécurité bien connues pour le langage et/ou les frameworks choisis, mais si on vous demande de générer un rapport, laissez l'utilisateur savoir que des conseils concrets ne sont pas disponibles (vous pouvez quand même générer le rapport ou détecter avec certitude les vulnérabilités critiques)

Dérogations

Bien que ces références contiennent les bonnes pratiques de sécurité pour les langages et frameworks, les clients peuvent avoir besoin de contourner ou de déroger à ces pratiques. Portez attention à des règles et instructions spécifiques dans la documentation et les fichiers de prompt du projet qui pourraient vous demander de déroger à certaines bonnes pratiques. Lorsque vous dérogez à une bonne pratique, vous POUVEZ le signaler à l'utilisateur, mais ne vous battez pas avec lui. Si une bonne pratique de sécurité doit être contournée/ignorée pour une raison spécifique au projet, vous pouvez aussi suggérer d'ajouter de la documentation sur ce point au projet afin qu'il soit clair pourquoi la bonne pratique n'est pas suivie et de suivre ce contournement à l'avenir.

Format du rapport

Lors de la production d'un rapport, vous devez écrire le rapport dans un fichier markdown security_best_practices_report.md ou un autre emplacement si fourni par l'utilisateur. Vous pouvez demander à l'utilisateur où il souhaite que le rapport soit écrit.

Le rapport doit avoir un court résumé exécutif en haut.

Le rapport doit être clairement délimité en plusieurs sections selon la sévérité de la vulnérabilité. Le rapport doit se concentrer sur les conclusions les plus critiques car celles-ci ont le plus grand impact pour l'utilisateur. Tous les résultats doivent être notés avec un ID numérique pour faciliter leur référence.

Pour les conclusions critiques, incluez une déclaration d'impact d'une phrase.

Une fois le rapport écrit, signalez-le aussi directement à l'utilisateur, bien que vous puissiez être moins verbeux. Vous pouvez proposer d'expliquer l'une quelconque des conclusions ou les raisons derrière les conseils des bonnes pratiques de sécurité si l'utilisateur veut plus d'infos sur l'une quelconque des conclusions.

Important : Lorsque vous référencez du code dans le rapport, assurez-vous de trouver et d'inclure les numéros de ligne pour le code que vous référencez.

Après avoir écrit le fichier du rapport, résumez les conclusions à l'utilisateur.

Dites aussi à l'utilisateur où le rapport final a été écrit.

Corrections

Si vous avez produit un rapport, laissez l'utilisateur lire le rapport et demandez à commencer à effectuer les corrections.

Si vous avez trouvé passivement une conclusion critique, notifiez l'utilisateur et demandez s'il souhaite que vous corrigiez cette conclusion.

Lors de la production des corrections, concentrez-vous sur la correction d'une seule conclusion à la fois. Les corrections doivent avoir des commentaires concis et clairs expliquant que le nouveau code est basé sur la bonne pratique de sécurité spécifique, et peut-être une très courte raison pour laquelle ce serait dangereux de ne pas le faire de cette façon.

Considérez toujours si les modifications que vous voulez apporter auront un impact sur la fonctionnalité du code de l'utilisateur. Réfléchissez à si les modifications peuvent causer des régressions avec la façon dont le projet fonctionne actuellement. Il arrive souvent que du code non sécurisé soit utilisé pour d'autres raisons (et c'est pourquoi du code non sécurisé persiste depuis longtemps). Évitez de casser le projet de l'utilisateur car cela pourrait le rendre réticent à appliquer des corrections de sécurité à l'avenir. Il est préférable de rédiger une correction bien réfléchie, bien informée par le reste du projet, qu'un changement rapide et mal ficelé.

Suivez toujours tout flux de modification ou commit normal que l'utilisateur a configuré. Si vous effectuez des commits git, fournissez des messages de commit clairs expliquant que c'est pour s'aligner avec les bonnes pratiques de sécurité. Essayez d'éviter de regrouper un nombre de conclusions non liées dans un seul commit.

Suivez toujours tout flux de test normal que l'utilisateur a configuré (s'il en existe) pour confirmer que vos modifications ne provoquent pas de régressions. Considérez les impacts secondaires que les modifications peuvent avoir et informez l'utilisateur avant de les effectuer s'il y en a.

Conseils généraux de sécurité

Voici quelques conseils de codage sécurisé qui s'appliquent à presque n'importe quel langage ou framework.

Éviter d'utiliser des IDs auto-incrémentés pour les IDs publics des ressources

Lorsque vous assignez un ID pour une ressource, qui sera ensuite utilisé et exposé à Internet, évitez d'utiliser des petits IDs auto-incrémentés. Utilisez plutôt une UUID4 plus long ou une chaîne hex aléatoire. Cela empêchera les utilisateurs d'apprendre la quantité d'une ressource et de pouvoir deviner des IDs de ressources.

Une note sur TLS

Bien que TLS soit important pour les déploiements en production, la plupart du travail de développement se fera avec TLS désactivé ou fourni par un proxy TLS hors de portée. Du fait de cela, soyez très prudent de ne pas signaler le manque de TLS comme un problème de sécurité. Soyez aussi très prudent autour de l'utilisation de cookies « secure ». Ils ne doivent être définis que si l'application sera réellement sur TLS. S'ils sont définis sur des applications non-TLS (comme lors du déploiement en développement local ou test), cela cassera l'application. Vous pouvez fournir une env ou un autre drapeau pour déroger au paramètre secure afin de le garder désactivé jusqu'au déploiement en production avec TLS. De plus, évitez de recommander HSTS. C'est dangereux à utiliser sans compréhension complète des impacts durables (peut causer des pannes majeures et des blocages utilisateur) et n'est généralement pas recommandé pour le périmètre des projets examinés par codex.