Ensemble de règles des règles de sécurité pour le code managé
Vous devez inclure l'ensemble de Règles de sécurité Microsoft pour optimiser le nombre de problèmes de sécurité éventuels qui sont détectés.
Règle |
Description |
---|---|
CA2100 : Rechercher des failles de sécurité dans des requêtes SQL |
|
Interceptez les exceptions non CLSCompliant dans les gestionnaires généraux |
|
Vérifiez la sécurité impérative |
|
Ne déclarez pas les types référence mutables en lecture seule |
|
Les champs de tableau ne doivent pas être en lecture seule |
|
Assertions sécurisées |
|
Passez en revue l'utilisation des méthodes Deny et PermitOnly |
|
Vérifiez la sécurité déclarative dans les types valeur |
|
Passez en revue les gestionnaires d'événements visibles |
|
Les pointeurs ne doivent pas être visibles |
|
Les types sécurisés ne doivent pas exposer de champs |
|
La sécurité de la méthode doit être un sur-ensemble du type |
|
Appelez GC.KeepAlive lorsque vous utilisez des ressources natives |
|
Les méthodes APTCA doivent uniquement appeler des méthodes APTCA |
|
Les types APTCA doivent uniquement étendre des types de base APTCA |
|
CA2118 : Révision de l'utilisation de SuppressUnmanagedCodeSecurityAttribute |
|
Scellez les méthodes qui satisfont les interfaces privées |
|
Sécurisez les constructeurs de sérialisation |
|
Les constructeurs statiques doivent être privés |
|
N'exposez pas indirectement des méthodes avec des demandes de liaison |
|
Les demandes de liaison de surcharge doivent être identiques au composant de base |
|
Incluez dans un wrapper les clauses finally vulnérables dans un bloc try externe |
|
Les demandes de liaison de types nécessitent des demandes d'héritage |
|
Les constantes critiques de sécurité doivent être transparentes |
|
Les types critiques de sécurité ne peuvent pas participer à l'équivalence des types |
|
Les constructeurs par défaut doivent être au moins aussi critiques que les constructeurs par défaut de type de base |
|
Les délégués doivent lier les méthodes avec une transparence cohérente |
|
Les méthodes doivent garder une transparence consistente lors de la surcharge de méthodes de base |
|
Les assemblies de niveau 2 ne doivent pas contenir de LinkDemands |
|
Les membres ne doivent pas avoir d'annotations de transparence conflictuelles |
|
Les méthodes transparentes doivent contenir uniquement des IL vérifiables |
|
Les méthodes transparentes ne doivent pas appeler les méthodes ayant l'attribut SuppressUnmanagedCodeSecurity |
|
Les méthodes transparentes ne peuvent pas utiliser l'attribut HandleProcessCorruptingExceptions |
|
Le code transparent ne doit pas faire référence à des éléments critiques de sécurité |
|
Les méthodes transparentes ne répondent pas aux LinkDemands |
|
Le code transparent ne doit pas être protégé avec des LinkDemands |
|
Les méthodes transparentes ne doivent pas utiliser de demandes de sécurité |
|
Le code transparent ne doit pas charger d'assemblies depuis des tableaux d'octets |
|
Les méthodes transparentes ne doivent pas être décorées avec SuppressUnmanagedCodeSecurityAttribute |
|
Les types doivent être au moins aussi critiques que les types de base et les interfaces |
|
Les méthodes transparentes ne peuvent pas utiliser d'assertions de sécurité |
|
Les méthodes transparentes ne doivent pas appeler du code natif |
|
CA2210 : Les assemblys doivent porter des noms forts valides |