Indications pour l'écriture de code sécurisé
Mise à jour : novembre 2007
Les indications suivantes fournissent plusieurs techniques pour l'écriture de code sécurisé.
Obligatoire
Utilisez des outils d'analyse du code.
Visual Studio Team System Development Edition est fourni avec des outils d'analyse du code qui peuvent augmenter sensiblement la possibilité de trouver des bogues de sécurité dans votre code. Ces outils recherchent les bogues plus efficacement et avec moins d'efforts. Pour plus d'informations, consultez Détection et correction des erreurs de code C/C++ et Détection et correction des erreurs du code managé.
Effectuez une révision de sécurité.
L'objectif de chaque révision de sécurité est soit d'améliorer la sécurité des produits qui ont déjà été diffusés - à l'aide de correctifs -, soit de garantir qu'aucun nouveau produit ne sera livré tant que sa sécurité ne sera pas optimale.
N'effectuez pas de révisions aléatoires du code. Préparez-vous à l'avance pour la révision de sécurité et commencez par créer soigneusement un modèle de menace. Si vous ne le faites pas, vous risquez de faire perdre beaucoup de temps à votre équipe. Classez par ordre de priorité le code qui doit recevoir la révision de sécurité la plus lourde et dont les bogues de sécurité doivent être traités.
Soyez précis à propos des éléments à rechercher dans une révision de sécurité. Lorsque vous recherchez des problèmes spécifiques, généralement vous les trouvez. Effectuez un contrôle encore plus strict si votre équipe trouve beaucoup de bogues de sécurité dans un domaine ; cela indique probablement un problème d'architecture qui doit être résolu. Si vous ne trouvez pas de bogues de sécurité, cela signifie généralement que la révision de sécurité n'a pas été effectuée correctement.
Considérez la révision de sécurité comme faisant partie de la stabilisation à chaque jalon, et comme étant un impératif plus large imposé par la direction pour la gamme de produits.
Utilisez une liste de vérification de révision du code pour la sécurité.
Indépendamment de votre rôle dans l'équipe de développement du logiciel, une liste de vérification vous sera utile pour garantir que la conception et le code satisfont des critères minimums.
Validez toutes les entrées d'utilisateur.
Si vous permettez à votre application d'accepter des entrées d'utilisateur, directement ou indirectement, vous devez valider ces entrées avant de les utiliser. Les utilisateurs malveillants essaieront de faire échouer votre application en modifiant les entrées pour qu'elles représentent des données non valides. La première règle d'une entrée d'utilisateur est : toute entrée est incorrecte jusqu'à preuve du contraire.
Soyez prudent lorsque vous utilisez des expressions régulières pour valider les entrées d'utilisateur. Pour les expressions complexes telles que les adresses de messagerie, il est facile de penser que vous effectuez une validation complète alors que ce n'est pas le cas. Demandez à des collègues de réviser toutes les expressions régulières.
Validez fortement tous les paramètres des interfaces de programmation d'applications exportées (API).
Vérifiez que tous les paramètres des API exportées sont valides. Cela inclut les entrées qui ont l'air cohérentes mais qui sortent de la plage de valeurs acceptées, par exemple les tailles de mémoire tampon énormes. N'utilisez pas d'assertions pour vérifier les paramètres des API exportées parce qu'elles seront supprimées dans la version release.
Utilisez les API de chiffrement de Windows.
Au lieu d'écrire votre propre logiciel de chiffrement, utilisez l'API de chiffrement de Microsoft qui est déjà disponible. L'utilisation de l'API de chiffrement de Microsoft permet aux développeurs de se concentrer sur la génération des applications. N'oubliez pas que le chiffrement résout très bien un petit ensemble de problèmes et est fréquemment utilisé d'une manière pour laquelle il n'a jamais été conçu. Pour plus d'informations, consultez Vue d'ensemble du chiffrement dans MSDN Library.
Évitez
Les dépassements de mémoire tampon.
Il y a dépassement de mémoire tampon statique lorsqu'une mémoire tampon déclarée sur la pile est remplacée par la copie d'une quantité de données plus importante que la taille de la mémoire tampon. Les variables déclarées sur la pile se trouvent à côté de l'adresse de retour de l'appelant de la fonction. Il peut également y avoir dépassement de mémoire tampon dans le tas, ce qui est tout aussi dangereux. Elle est généralement due à une entrée d'utilisateur passée à une fonction telle que strcpy, et le résultat est que l'adresse de retour de la fonction est remplacée par une adresse choisie par l'intrus. Pour prévenir les dépassements de mémoire tampon, la meilleure solution consiste à écrire une application fiable.
Assertions de vérification des entrées externes.
Les assertions ne sont pas compilées dans les versions commerciales. N'utilisez pas d'assertions pour vérifier les entrées externes. Tous les paramètres des fonctions et des méthodes exportées, toutes les entrées d'utilisateur et toutes les données de fichier et de socket doivent faire l'objet d'une vérification soigneuse de validité et être rejetés s'ils sont erronés.
ID d'utilisateur codé en dur et paires de mots de passe.
N'utilisez pas de mots de passe codés en dur. Modifiez le programme d'installation afin que, lors de la création des comptes d'utilisateurs intégrés, l'administrateur sera invité à spécifier des mots de passe forts pour chaque compte. Cela permet de préserver la sécurité des systèmes de niveau de production des clients.
L'utilisation du chiffrement résout tous les problèmes de sécurité.
Le chiffrement résout très bien un petit ensemble de problèmes et est fréquemment utilisé d'une manière pour laquelle il n'a jamais été conçu.
Chemins d'accès canoniques et URL.
Évitez les situations où l'emplacement d'un fichier ou d'une URL est important. Utilisez les ACL du système de fichiers plutôt que des règles basées sur des noms de fichiers canoniques.
Recommandé
Révisez toutes les anciennes erreurs de sécurité dans votre application.
N'oubliez pas les erreurs de sécurité que vous avez faites dans le passé. Généralement, ceux qui écrivent du code répètent les mêmes schémas. Par conséquent, si une personne introduit un bogue quelque part, il y a des chances pour que d'autres personnes introduisent le même bogue ailleurs.
Révisez tous les chemins d'erreur.
Souvent, le code présent dans les chemins d'erreur n'est pas bien testé et ne nettoie pas tous les objets, tels que les verrouillages ou la mémoire allouée. Révisez soigneusement ces chemins et, si nécessaire, créez des tests d'injection d'erreurs pour tester le code.
Non recommandé
Droits d'administrateur nécessaires à l'exécution de votre application.
Les applications doivent s'exécuter avec les droits les plus faibles nécessaires à leur bon fonctionnement. Si un utilisateur malveillant trouve des failles de sécurité et injecte du code dans votre processus, le code malveillant s'exécutera avec les mêmes droits que le processus hôte. Si le processus s'exécute en tant qu'administrateur, le code malveillant s'exécute en tant qu'administrateur. Pour plus d'informations, consultez Développement d'applications sécurisées (en anglais) dans MSDN Library.