Liste de contrôle : examen de la sécurité du code géré

Les menaces potentielles sont clairement référencées (elles dépendent du scénario spécifique et du type d'assembly).

Le code est développé en fonction des directives de codage de .NET Framework et des directives de codage sécurisé indiquées à l'adresse http://msdn.microsoft.com/library/default.asp?url=/library/en-us/cpgenref/html/cpconnetframeworkdesignguidelines.asp.

L'outil d'analyse FXCop est exécuté sur des assemblys et des avertissements de sécurité sont envoyés.

Les assemblys ont un nom fort (les assemblys de page Web ASP.NET générés dynamiquement ne peuvent pas actuellement avoir de nom fort).

Vous avez songé à la temporisation de signature pour protéger et restreindre la clé privée utilisée par le nom fort et le processus de signature.

Les assemblys intègrent des attributs de sécurité déclaratifs (avec SecurityAction.RequestMinimum) pour spécifier des exigences minimum d'autorisation.

Les assemblys hautement privilégiés sont séparés des assemblys moins privilégiés. Lorsque l'assembly doit être utilisé dans un environnement partiellement sécurisé (par exemple, lorsqu'il est appelé par une application Web partiellement sécurisée), le code privilégié est mis en sandbox dans un autre assembly.

La visibilité de la classe et du membre est restreinte. Le modificateur d'accès le plus restrictif est utilisé (privé si possible).

Les classes hors base sont scellées.

Les entrées issues de l'extérieur de la limite sécurisée actuelle sont validées. Les données d'entrée sont limitées et validées en fonction du type, de la longueur, du format et de la plage.

Le code met en œuvre des contrôles déclaratifs lorsque des méthodes internes virtuelles sont utilisées.

L'accès aux classes et aux méthodes publiques est limité par les demandes d'autorisation principales (le cas échéant).

Les champs sont privés. Lorsque cela est nécessaire, les valeurs du champ sont exposées à l'aide des propriétés publiques de lecture/écriture ou de lecture seule.

Les propriétés de lecture seule sont utilisées si possible.

Les types renvoyés par les méthodes qui ne sont pas conçues pour être créées indépendamment contiennent des constructeurs privés par défaut.

Les types publics non scellés n'ont pas de membres virtuels internes.

L'utilisation de gestionnaires d'événements est minutieusement examinée.

Les constructeurs statiques sont privés.

Le code utilise la cryptographie fournie par la plate-forme et n'utilise pas les implémentations personnalisées.

Des clés aléatoires sont générées à l'aide de RNGCryptoServiceProvider (et non de la classe Aléatoire).

PasswordDeriveBytes est utilisé pour le cryptage basé sur un mot de passe.

DPAPI permet de crypter les secrets de configuration afin d'éviter les problèmes de gestion des clés.

Des tailles de clé appropriées sont utilisées pour l'algorithme choisi. Dans le cas contraire, les raisons sont identifiées et résolues.

Les clés ne sont pas contenues dans le code.

L'accès aux clés persistantes est restreint.

Les clés changent régulièrement.

Les clés privées exportées sont protégées.

Les secrets ne sont pas pré-programmés.

Les secrets en texte plein ne sont pas stockés dans les fichiers de configuration.

Les secrets en texte plein ne sont pas stockés dans la mémoire pour de longues durées.

Le code utilise la gestion des exceptions. Consignez uniquement les exceptions que vous connaissez.

Les détails de l'exception sont enregistrés sur le serveur pour permettre de diagnostiquer les problèmes.

Les informations renvoyées à l'utilisateur final sont limitées et sécurisées.

Un code qui utilise les filtres d'exceptions n'est pas sensible à la séquence d'exécution du filtre (le filtre s'exécute avant un bloc finally).

Le code échoue rapidement pour éviter un traitement inutile consommateur de ressources.

Les conditions d'exception ne permettent pas à l'utilisateur d'ignorer les contrôles de sécurité pour exécuter un code privilégié.

Les délégués de sources non sécurisées ne sont pas acceptés.

Si le code accepte le délégué d'un code non sécurisé, il limite le délégué avant de l'appeler à l'aide des autorisations de sécurité de SecurityAction.PermitOnly.

Les autorisations ne sont pas certifiées avant d'appeler un délégué.

La sérialisation se limite au code privilégié.

Les données sensibles ne sont pas sérialisées.

Les données des flux de données sérialisées sont validées.

L'implémentation ISerializable.GetObjectData est protégée par une demande d'autorisation d'identité lorsque vous souhaitez indiquer quel code peut sérialiser l'objet.

Les résultats des contrôles de sécurité ne sont pas mis en cache.

Des jetons d'emprunt d'identité sont utilisés lors de la création de nouveaux threads (un jeton de thread existant n'est pas passé au nouveau thread).

Les threads sont synchronisés dans les constructeurs de classe statique pour un code d'application multithread.

Le code d'implémentation d'objet est conçu et créé de manière sécurisée pour les threads.

Les threads sont synchronisés dans des constructeurs de classe statique.

L'appelant ne peut pas influencer le code généré dynamiquement (par exemple, en passant les noms d'assembly et de type comme arguments d'entrée).

Le code exige une autorisation de l'utilisateur lorsque les assemblys sont chargés de manière dynamique.

Les chaînes d'entrée et de sortie qui passent entre le code géré et le code non géré sont limitées et validées.

Les tailles de tableau sont contrôlées.

Les longueurs de chemin d'accès aux fichiers sont contrôlées et ne dépassent pas la limite MAX_PATH.

Le code non géré est compilé à l'aide du switch /GS.

L'utilisation d'API « dangereuses » par le code non géré est minutieusement contrôlée. Celles-ci comprennent notamment LogonUser, RevertToSelf, CreateThread, les API de réseau et les API de sockets.

Des conventions de dénomination (sécurisée, native, non sécurisée) sont appliquées aux API non gérées.

Les assemblys qui appellent un code non géré spécifient des exigences d'autorisation non gérée à l'aide de l'attribut de sécurité déclaratif (SecurityAction.RequestMinimum).

Les appels d'API non gérées sont mis en sandbox et isolés dans un assembly wrappers.

L'utilisation de SuppressUnmanagedCodeSecurityAttribute est minutieusement examinée et des contrôles de sécurité supplémentaires sont mis en œuvre.

Les types ne sont pas annotés avec SuppressUnmanagedCodeSecurityAttribute.
(Cet attribut est plutôt utilisé sur des déclarations de méthode P/Invoke spécifiques.)

Le code appelant reçoit l'autorisation appropriée à l'aide d'une demande de parcours intégral de pile
(avec une autorisation .NET Framework ou une autorisation personnalisée).

Les types ou handles non gérés ne sont jamais exposés au code partiellement sécurisé.

Les pointeurs sont des champs privés.

Les méthodes utilisant les champs IntPtr dans un type intégrant une finalisation appellent GC.KeepAlive(objet).

Aucune décision relative à la sécurité n'est basée sur des noms de fichiers.

Les chemins d'accès au fichier d'entrée et les noms de fichiers sont corrects.

Les variables d'environnement ne sont pas utilisées pour construire les chemins d'accès au fichier.

L'accès au fichier est limité au contexte de l'application (à l'aide d'une autorisation restreinte FileIOPermission).

Les exigences d'E/S sur fichier d'assembly sont spécifiées à l'aide d'attributs de sécurité déclaratifs (avec SecurityAction.RequestMinimum).

Le code d'accès au journal d'événements est limité par l'autorisation EventLogPermission. Celle-ci s'applique en particulier lorsque votre code de journalisation d'événements peut être appelé par des appelants non sécurisés.

Les sources d'événements sont créées au moment de l'installation (ou le compte utilisé pour exécuter le code qui écrit dans le journal d'événements doit être autorisé à créer des sources d'événements en configurant une ACL appropriée dans le Registre).

Les données sensibles à la sécurité, telles que les mots de passe, ne sont pas écrites dans le journal d'événements.

Les données sensibles, telles que les chaînes de connexion à la base de données ou les informations d'authentification, sont cryptées avant d'être stockées dans le Registre.

Les clés sont limitées. Si une clé se trouvant sous HKEY_CURRENT_MACHINE est utilisée, elle est configurée avec une liste de contrôle d'accès restreinte. Sinon, la clé HKEY_CURRENT_USER est utilisée.

L'accès au Registre est limité par l'autorisation RegistryPermission. Celle-ci s'applique en particulier lorsque votre code d'accès au Registre peut être appelé par des appelants non sécurisés.

Le code qui accède aux variables d'environnement est limité par l'autorisation EnvironmentPermission. Celle-ci s'applique en particulier lorsque votre code peut être appelé par un code non sécurisé.

Les exigences d'autorisation de l'environnement sont déclarées à l'aide d'attributs de sécurité déclaratifs avec SecurityAction.RequestMinimum.

Les assemblys marqués avec AllowPartiallyTrustedCallersAttribute (APTCA) n'exposent pas les objets des autres assemblys.

Un code prenant uniquement en charge les appelants entièrement sécurisés dispose d'un nom fort ou exige explicitement le jeu d'autorisations de confiance totale.

Toutes les utilisations de Assert sont minutieusement contrôlées.

Tous les appels vers Assert sont mis en correspondance avec un appel adéquat vers RevertAssert.

*La fenêtre d'assertion est aussi petite que possible.

*Les assertions sont effectuées avec une demande d'autorisation complète.

*L'utilisation de Deny ou de PermitOnly est minutieusement contrôlée.

Toutes les utilisations de LinkDemand sont minutieusement contrôlées. (Pourquoi utiliser LinkDemand et non une demande complète ?)

Les LinkDemands des déclarations d'Interface sont mises en correspondance avec les LinkDemands de l'implémentation de la méthode.

*Les membres non sécurisés n'appellent pas des membres protégés par une LinkDemand.

Aucune autorisation n'est demandée pour les ressources auxquelles on accède via les classes .NET Framework.

L'accès aux ressources personnalisées (via un code non géré) est protégé par les autorisations d'accès au code personnalisées.

L'accès aux données mises en cache est protégé par des demandes d'autorisation appropriées.

Si les LinkDemands sont utilisées sur des structures, celles-ci contiennent des constructeurs spécifiquement définis.

*Les méthodes qui écrasent d'autres méthodes protégées par des LinkDemands produisent également la même LinkDemand.

*Les LinkDemands sur types ne sont pas utilisées pour protéger l'accès aux champs à l'intérieur de ces types.

*Les méthodes partiellement sécurisées appellent uniquement d'autres méthodes partiellement sécurisées.

*Les types partiellement sécurisés étendent uniquement d'autres types partiellement sécurisés.

*Les membres qui appellent des membres de liaison tardive intègrent des contrôles de sécurité déclaratifs.

*La sécurité déclarative au niveau de la méthode n'écrase pas par erreur les contrôles de sécurité au niveau de la classe.

L'utilisation des autorisations « potentiellement dangereuses » suivantes est minutieusement contrôlée :
SecurityPermission
Unmanaged Code
SkipVerification
ControlEvidence
ControlPolicy
SerializationFormatter
ControlPrincipal
ControlThread
ReflectionPermission
MemberAccess

Les demandes d'autorisation d'identité du code permettent d'autoriser un code appelant lorsque vous connaissez par avance la plage d'appelants possibles (par exemple, si vous souhaitez limiter le code appelant à une application spécifique).

Les demandes d'autorisation de .NET Framework ne sont pas dupliquées.

L'héritage peut être limité par SecurityAction.InheritanceDemand lorsque vous souhaitez indiquer quel code peut être dérivé de votre code.