Bonnes Pratiques de Sécurité

Vue d'ensemble

Cette compétence fournit une description de la façon d'identifier le langage et les frameworks utilisés par le contexte actuel, puis de charger les informations du répertoire de références de cette compétence sur les bonnes pratiques de sécurité pour ce langage et/ou ces frameworks.

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

Flux de travail

L'étape initiale de cette compétence consiste à identifier TOUS les langages et TOUS les frameworks que vous êtes invité à utiliser ou qui existent déjà dans la portée du projet sur lequel vous travaillez. Concentrez-vous sur les frameworks essentiels principaux. Souvent, vous voudrez identifier à la fois les langages et frameworks frontend et backend.

Vérifiez ensuite le répertoire de références de cette compétence pour voir s'il existe une 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 au langage spécifique. Le format des noms de fichiers est <language>-<framework>-<stack>-security.md. Vous devriez également vérifier s'il existe un fichier <language>-general-<stack>-security.md qui est agnostique au framework que vous utilisez.

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 application web qui inclura à la fois un frontend et un backend, mais que le framework frontend n'est pas spécifié, consultez également 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 compétence, 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 une documentation sur les bonnes pratiques de sécurité.

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

1. Le mode principal est d'utiliser simplement 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 d'un nouveau code.

2. Le mode secondaire consiste à détecter passivement les vulnérabilités lors du travail dans le projet et de l'écriture de code pour l'utilisateur. Les vulnérabilités critiques ou très importantes ou les problèmes majeurs allant à l'encontre des directives de sécurité peuvent être signalés et l'utilisateur peut être informé. Ce mode passif devrait se concentrer sur les vulnérabilités ayant le plus grand impact et les paramètres par défaut sécurisés.

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

Arbre de décision du flux de travail

• Si le langage/framework n'est pas clair, inspectez le dépôt pour le déterminer et listez vos preuves.
• Si une orientation correspondante existe dans references/, chargez uniquement les fichiers pertinents et suivez leurs instructions.
• Si aucune orientation correspondante n'existe, considérez si vous connaissez des bonnes pratiques de sécurité bien connues pour le langage choisi et/ou les frameworks, mais si on vous demande de générer un rapport, informez l'utilisateur que des directives concrètes ne sont pas disponibles (vous pouvez toujours générer le rapport ou détecter avec certitude des vulnérabilités critiques)

Remplacements

Bien que ces références contiennent les bonnes pratiques de sécurité pour les langages et frameworks, les clients peuvent avoir des cas où ils ont besoin de contourner ou de remplacer ces pratiques. Faites attention aux règles spécifiques et aux instructions dans la documentation du projet et les fichiers d'invite qui peuvent vous obliger à remplacer certaines bonnes pratiques. Lors du remplacement d'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 également suggérer d'ajouter une documentation à ce sujet au projet pour qu'il soit clair pourquoi la bonne pratique n'est pas suivie et pour suivre ce contournement à l'avenir.

Format du rapport

Lors de la production d'un rapport, vous devez écrire le rapport comme un fichier markdown dans 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 en fonction de la sévérité de la vulnérabilité. Le rapport doit se concentrer sur les résultats les plus critiques car ils ont le plus grand impact pour l'utilisateur. Tous les résultats doivent être notés avec un ID numérique pour les rendre plus faciles à référencer.

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

Une fois le rapport écrit, signalez-le également à l'utilisateur directement, bien que vous puissiez être moins verbeux. Vous pouvez proposer d'expliquer l'un des résultats ou les raisons derrière les directives des bonnes pratiques de sécurité si l'utilisateur souhaite plus d'informations sur l'un des résultats.

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

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

Indiquez également à l'utilisateur où le rapport final a été écrit.

Corrections

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

Si vous avez trouvé passivement un résultat critique, notifiez l'utilisateur et demandez s'il souhaite que vous corrigiez ce résultat.

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

Considérez toujours si les modifications que vous souhaitez apporter auront un impact sur la fonctionnalité du code de l'utilisateur. Considérez si les modifications peuvent causer des régressions avec le fonctionnement actuel du projet. C'est souvent le cas que le code non sécurisé est dépendant pour d'autres raisons (et c'est pourquoi le code non sécurisé dure si longtemps). Évitez de casser le projet de l'utilisateur car cela peut le rendre réticent à appliquer les corrections de sécurité à l'avenir. Il est préférable d'écrire une correction bien réfléchie et bien informée par le reste du projet, qu'un changement rapide et désorganisé.

Suivez toujours le flux de changement ou de 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 sur les bonnes pratiques de sécurité. Essayez d'éviter de regrouper plusieurs résultats non liés dans un seul commit.

Suivez toujours les flux de test normaux que l'utilisateur a configurés (le cas échéant) pour confirmer que vos modifications n'introduisent pas de régressions. Considérez les impacts de second ordre que les modifications peuvent avoir et informez l'utilisateur avant de les apporter s'il y en a.

Conseils généraux de sécurité

Voici quelques conseils de codage sécurisé qui s'appliquent à presque tous les langages ou frameworks.

Évitez d'utiliser des ID croissants pour les ID publics des ressources

Lors de l'assignation d'un ID pour une ressource, qui sera ensuite utilisé de manière exposée sur Internet, évitez d'utiliser de petits ID auto-croissants. Utilisez plutôt une chaîne UUID4 plus longue ou aléatoire ou une chaîne hexadécimale aléatoire. Cela empêchera les utilisateurs de connaître la quantité d'une ressource et de pouvoir deviner les ID de ressources.

Une note sur TLS

Bien que TLS soit important pour les déploiements en production, la plupart des travaux de développement se feront avec TLS désactivé ou fourni par un proxy TLS hors de portée. Pour cette raison, soyez très prudent pour ne pas signaler l'absence de TLS comme un problème de sécurité. Soyez également très prudent autour de l'utilisation de cookies "sécurisés". 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 pour dev local ou des tests), cela cassera l'application. Vous pouvez fournir un env ou un autre flag pour remplacer la définition de secure comme un moyen de le garder désactivé jusqu'au déploiement en production avec TLS. De plus, évitez de recommander HSTS. C'est dangereux à utiliser sans une compréhension complète des impacts durables (peut causer des pannes majeures et des blocages utilisateur) et ce n'est généralement pas recommandé pour la portée des projets examinés par codex.