Indications pour l'écriture de code sécurisé
Les indications suivantes fournissent plusieurs techniques pour l'écriture de code sécurisé.
Obligatoire
Utilisez des outils d'analyse du code.
Visual Studio Premium est fourni avec des outils d'analyse du code qui peuvent augmenter sensiblement le risque 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 l'une des rubriques suivantes :
Effectuez une révision de sécurité.
L'objectif de chaque révision de sécurité est de renforcer la sécurité des produits déjà commercialisés en fournissant des mises à jour ou de garantir qu'aucun nouveau produit n'est commercialisé tant qu'il ne présente pas la meilleure sécurité possible.
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. Persistez dans cette tâche si votre équipe détecte de nombreux bogues de sécurité dans une zone. Cela indique probablement un problème d'architecture qui doit impérativement ê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.
Insistez sur la validation de tous les paramètres des API exportées et publiques.
Assurez-vous que tous les paramètres des API exportées et publiques 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 des tailles de mémoire tampon très importantes. 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 Référence du chiffrement (page éventuellement en anglais) 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. Il est généralement dû à une entrée d'utilisateur transmise à une fonction telle que strcpy, dont 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.
Utilisation du chiffrement pour résoudre 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. Pour plus d'informations, consultez la section « Input Validation » du document Design Guidelines for Secure Web Applications et la même section du document Architecture and Design Review for Security, disponibles dans MSDN Library.
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 de logiciels dans Visual Studio .NET sans les privilèges d'administrateur dans MSDN Library.