Avertissements liés à la sécurité

Les avertissements de sécurité prennent en charge des bibliothèques et des applications plus sûres. Ces avertissements contribuent à empêcher la présence de défauts de sécurité dans votre programme. Si vous désactivez chacun de ces avertissements, vous devez indiquer clairement le motif de l'opération dans le code et également en informer le responsable de la sécurité désigné pour votre projet de développement.

Dans cette section

Règle	Description
CA2100 : Rechercher des failles de sécurité dans des requêtes SQL	Une méthode définit la propriété System.Data.IDbCommand.CommandText à l'aide d'une chaîne générée à partir d'un argument de chaîne à la méthode. Cette règle suppose que l'argument de chaîne contient des entrées d'utilisateur. Une chaîne de commande SQL construite à partir d'entrées d'utilisateur est vulnérable aux attaques d'injection SQL.
CA2102 : Interceptez les exceptions non CLSCompliant dans les gestionnaires généraux	Un membre dans un assembly qui n'est pas marqué avec RuntimeCompatibilityAttribute ou qui est marqué avec RuntimeCompatibility(WrapNonExceptionThrows = false) contient un bloc catch qui gère System.Exception et ne contient pas de bloc catch général immédiatement après.
CA2103 : Vérifiez la sécurité impérative	Une méthode utilise la sécurité impérative et est susceptible de construire l'autorisation à l'aide d'informations d'état ou de valeurs de retour qui peuvent changer pendant que la demande est active. Utilisez la sécurité de déclaration dès que possible.
CA2104 : Ne déclarez pas les types référence mutables en lecture seule	Un type visible de l'extérieur contient un champ en lecture seule visible de l'extérieur qui constitue un type référence mutable. Un type mutable est un type dont les données d'instance peuvent être modifiées.
CA2105 : Les champs de tableau ne doivent pas être en lecture seule	Lorsque vous appliquez le modificateur en lecture seule (ReadOnly en Visual Basic) à un champ qui contient un tableau, ce champ ne peut pas être modifié pour référencer un tableau différent. Toutefois, les éléments du tableau stockés dans un champ en lecture seule peuvent être modifiés.
CA2106 : Assertions sécurisées	Une méthode déclare une autorisation et aucune vérification de sécurité n'est exécutée sur l'appelant. L'assertion d'une autorisation de sécurité effectuée sans vérification de sécurité peut rendre votre code vulnérable et facile à exploiter.
CA2107 : Passez en revue l'utilisation des méthodes Deny et PermitOnly	La méthode PermitOnly et les actions de sécurité CodeAccessPermission.Deny doivent être uniquement utilisées par les développeurs ayant des connaissances approfondies de la sécurité du .NET Framework. Le code qui utilise ces actions de sécurité doit subir une révision de sécurité.
CA2108 : Vérifiez la sécurité déclarative dans les types valeur	Un type valeur public ou protégé est sécurisé par l'accès aux données ou des demandes de liaison.
CA2109 : Passez en revue les gestionnaires d'événements visibles	Une méthode de gestion d'événements publique ou protégée a été détectée. Les méthodes de gestion d'événements ne doivent pas être exposées sauf nécessité absolue.
CA2111 : Les pointeurs ne doivent pas être visibles	Un pointeur n'est ni privé, ni interne ni en lecture seule. Un code malveillant peut modifier la valeur du pointeur, autorisant potentiellement l'accès aux emplacements arbitraires en mémoire ou provoquant des défaillances des applications ou du système.
CA2112 : Les types sécurisés ne doivent pas exposer de champs	Un type public ou protégé contient des champs publics et est sécurisé par des demandes de liaison. Si un code a accès à une instance d'un type sécurisé par une demande de liaison, ce code n'a pas besoin de satisfaire la demande de liaison pour accéder aux champs du type.
CA2114 :La sécurité de la méthode doit être un sur-ensemble du type	Pour une même action, une méthode ne doit pas présenter de sécurité déclarative à la fois au niveau méthode et au niveau type.
CA2115 : Appelez GC.KeepAlive lorsque vous utilisez des ressources natives	Cette règle détecte les erreurs susceptibles de se produire du fait qu'une ressource non managée est en cours de finalisation alors qu'elle est encore utilisée dans un code non managé.
CA2116 : Les méthodes APTCA doivent uniquement appeler des méthodes APTCA	Lorsque l'attribut APTCA (AllowPartiallyTrustedCallers) est présent sur un assembly doté d'une confiance totale, et lorsque cet assembly exécute un code dans un autre assembly qui n'autorise pas les appelants dotés d'une confiance partielle, il devient possible d'exploiter une faille dans la sécurité.
CA2117 : Les types APTCA doivent uniquement étendre des types de base APTCA	Lorsque l'attribut APTCA (AllowPartiallyTrustedCallers) est présent sur un assembly doté d'une confiance totale et lorsqu'un type présent dans l'assembly hérite d'un type qui n'autorise pas les appelants partiellement approuvés, une exploitation de la sécurité devient possible.
CA2118 : Révision de l'utilisation de SuppressUnmanagedCodeSecurityAttribute	SuppressUnmanagedCodeSecurityAttribute modifie le comportement par défaut du système en matière de sécurité pour les membres qui exécutent le code non managé utilisant COM Interop ou l'appel de code non managé. Cet attribut est essentiellement utilisé pour accroître les performances ; toutefois, les gains de performance s'accompagnent de risques substantiels pour la sécurité.
CA2119 : Scellez les méthodes qui satisfont les interfaces privées	Un type public pouvant être hérité fournit une implémentation de méthode substituable d'une interface interne (Friend en Visual Basic). Pour corriger une violation de cette règle, empêchez la méthode d'être substituée en dehors de l'assembly.
CA2120 : Sécurisez les constructeurs de sérialisation	Ce type possède un constructeur qui accepte un objet System.Runtime.Serialization.SerializationInfo et un objet System.Runtime.Serialization.StreamingContext (la signature du constructeur de sérialisation). Ce constructeur n'est pas sécurisé par une vérification de la sécurité, mais au moins un des constructeurs normaux dans le type est sécurisé.
CA2121 : Les constructeurs statiques doivent être privés	Le système appelle le constructeur statique avant la création de la première instance du type ou le référencement de tout membre statique. Si un constructeur statique n'est pas privé, il peut être appelé par un code autre que le système. Selon les opérations effectuées dans le constructeur, cette possibilité peut provoquer un comportement inattendu.
CA2122 : N'exposez pas indirectement des méthodes avec des demandes de liaison	Un membre public ou protégé a des demandes de liaison et est appelé par un membre qui ne procède à aucune vérification de la sécurité. Une demande de liaison vérifie uniquement les autorisations de l'appelant immédiat.
CA2123 : Les demandes de liaison de substitution doivent être identiques au composant de base	Cette règle met en correspondance une méthode et sa méthode de base, qui est soit une interface, soit une méthode virtuelle dans un autre type, puis compare les demandes de liaison sur chacune. Si cette règle est violée, un appelant malveillant peut ignorer la demande de liaison simplement en appelant la méthode non protégée.
CA2124 : Incluez dans un wrapper les clauses finally vulnérables dans un bloc try externe	Une méthode publique ou protégée contient un bloc try/finally. Le bloc finally semble réinitialiser l'état de sécurité et n'est lui-même placé dans aucun bloc finally.
CA2126 : Les demandes de liaison de types nécessitent des demandes d'héritage	Un type unsealed public est protégé par une demande de liaison et a une méthode substituable. Ni le type ni la méthode n'est protégé par une demande d'héritage.
CA2136 : Les membres ne doivent pas avoir d'annotations de transparence conflictuelles	Le code critique ne peut pas apparaître dans un assembly entièrement transparent. Cette règle analyse les assemblys entièrement transparents pour toutes les annotations SecurityCritical au niveau du type, du champ et de la méthode.
CA2147 : Les méthodes transparentes ne peuvent pas utiliser d'assertions de sécurité	Cette règle analyse toutes les méthodes et tous les types dans un assembly qui est entièrement transparent ou mi-transparent et mi-critique, et elle signale toutes les utilisations déclaratives ou impératives d'Assert.
CA2140 : Le code transparent ne doit pas faire référence à des éléments critiques de sécurité	Les méthodes marquées avec SecurityTransparentAttribute appellent des membres non publics marqués en tant que SecurityCritical. Cette règle analyse toutes les méthodes et tous les types dans un assembly qui est mi-transparent et mi-critique, et elle signale tous les appels du code transparent au code critique non public qui ne sont pas marqués comme SecurityTreatAsSafe.

CA2130 : Les constantes critiques de sécurité doivent être transparentes	La mise en application de la transparence n'est pas effectuée pour les valeurs de constante car les compilateurs alignent les valeurs de constante afin qu'aucune recherche ne soit requise au moment de l'exécution. Les champs constants doivent être transparents de sécurité (security-transparent) afin que les relecteurs de code ne supposent pas que le code transparent ne peut pas accéder à la constante.
CA2131 : Les types critiques de sécurité ne peuvent pas participer à l'équivalence des types	Un type participe à l'équivalence des types et un type lui-même, ou un membre ou champ du type, est marqué à l'aide de l'attribut SecurityCriticalAttribute. Cette règle se déclenche sur tout type ou type critique contenant des méthodes critiques ou des champs qui participent à l'équivalence de type. Lorsque le CLR détecte un tel type, il ne peut pas le charger avec une exception TypeLoadException au moment de l'exécution. En général, cette règle se déclenche uniquement lorsque les utilisateurs implémentent l'équivalence de type manuellement plutôt qu'en comptant sur tlbimp et les compilateurs pour faire l'équivalence de type.
CA2132 : Les constructeurs par défaut doivent être au moins aussi critiques que les constructeurs par défaut de type de base	Les types et les membres qui possèdent l'attribut SecurityCriticalAttribute ne peuvent pas être utilisés par le code d'application Silverlight. Les types et membres critiques de sécurité (security-critical) peuvent être uniquement utilisés par le code de confiance dans la bibliothèque de classes .NET Framework pour Silverlight. Dans la mesure où une construction publique ou protégée dans une classe dérivée doit avoir la même transparence ou une transparence supérieure à sa classe de base, une classe dans une application ne peut pas être dérivée d'une classe marquée SecurityCritical.
CA2133 : Les délégués doivent lier les méthodes avec une transparence cohérente	Cet avertissement se déclenche sur une méthode qui lie un délégué marqué à l'aide de SecurityCriticalAttribute à une méthode transparente ou marquée à l'aide de SecuritySafeCriticalAttribute. L'avertissement déclenche également une méthode qui lie un délégué transparent ou critique sécurisé à une méthode critique.
CA2134 : La transparence des méthodes doit rester cohérente lors de la substitution de méthodes de base	Cette règle se déclenche lorsqu'une méthode marquée à l'aide de SecurityCriticalAttribute substitue une méthode qui est transparente ou marquée à l'aide de SecuritySafeCriticalAttribute. Cette règle se déclenche également lorsqu'une méthode qui est transparente ou marquée à l'aide de SecuritySafeCriticalAttribute substitue une méthode marquée à l'aide de SecurityCriticalAttribute. La règle est appliquée lors de la substitution d'une méthode virtuelle ou de l'implémentation d'une interface.
CA2135 : Les assemblys de niveau 2 ne doivent pas contenir de LinkDemands	L'utilisation de LinkDemands est déconseillée dans l'ensemble de règles de sécurité de niveau 2. Au lieu d'utiliser LinkDemands pour implémenter la sécurité au moment de la compilation juste-à-temps (JIT), marquez les méthodes, types et champs avec l'attribut SecurityCriticalAttribute.
CA2136 : Les membres ne doivent pas avoir d'annotations de transparence conflictuelles	Les attributs de transparence sont appliqués à partir d'éléments de code de plus grande portée à des éléments de plus petite portée. Les attributs de transparence d'éléments de code avec une plus grande portée sont prioritaires sur les attributs de transparence des éléments de code contenus dans le premier élément. Par exemple, une classe marquée à l'aide de l'attribut SecurityCriticalAttribute ne peut pas contenir de méthode marquée à l'aide de l'attribut SecuritySafeCriticalAttribute.
CA2137 : Les méthodes transparentes doivent contenir uniquement des IL vérifiables	Une méthode contient du code non vérifiable ou retourne un type par référence. Cette règle se déclenche lorsque le code transparent de sécurité tente d'exécuter du code MSIL (Microsoft Intermediate Language) non vérifiable. Toutefois, la règle ne contient pas de vérificateur IL (Intermediate Language) complet, et à la place utilise l'heuristique pour intercepter la plupart des violations de vérification MSIL.
CA2138 : Les méthodes transparentes ne doivent pas appeler les méthodes ayant l'attribut SuppressUnmanagedCodeSecurity	Une méthode transparente de sécurité appelle une méthode qui est marquée à l'aide de l'attribut SuppressUnmanagedCodeSecurityAttribute.
CA2139 : Les méthodes transparentes ne peuvent pas utiliser l'attribut HandleProcessCorruptingExceptions	Cette règle déclenche toute méthode transparente qui essaie de gérer une exception qui endommage un processus à l'aide de l'attribut HandleProcessCorruptedStateExceptionsAttribute. Une exception qui endommage un processus est une classification d'exception CLR version 4.0 des exceptions comme AccessViolationException. L'attribut HandleProcessCorruptedStateExceptionsAttribute peut uniquement être utilisé par des méthodes critiques de sécurité et sera ignoré s'il s'applique à une méthode transparente.
CA2140 : Le code transparent ne doit pas faire référence à des éléments critiques de sécurité	Un élément de code marqué à l'aide de l'attribut SecurityCriticalAttribute est critique de sécurité. Une méthode transparente ne peut pas utiliser un élément critique de sécurité. Si un type transparent essaie d'utiliser un type critique de sécurité, TypeAccessException, MethodAccessException ou FieldAccessException est déclenché.
CA2141 : Les méthodes transparentes ne répondent pas aux LinkDemands	Une méthode transparente de sécurité appelle une méthode dans un assembly qui n'est pas marqué à l'aide de l'attribut APTCA (AllowPartiallyTrustedCallersAttribute), ou une méthode transparente de sécurité satisfait une demande LinkDemand pour un type ou une méthode.
CA2142 : Le code transparent ne doit pas être protégé avec des LinkDemands	Cette règle se déclenche sur les méthodes transparentes qui requièrent l'accès de LinkDemands. Le code transparent de sécurité ne doit pas être responsable de la vérification de la sécurité d'une opération. Par conséquent, il ne doit pas demander d'autorisations.
CA2143 : Les méthodes transparentes ne doivent pas utiliser de demandes de sécurité	Le code transparent de sécurité ne doit pas être responsable de la vérification de la sécurité d'une opération. Par conséquent, il ne doit pas demander d'autorisations. Le code transparent de sécurité doit utiliser des demandes complètes pour prendre des décisions de sécurité et le code critique sécurisé ne doit pas dépendre du code transparent pour l'exécution de ces demandes.
CA2144 : Le code transparent ne doit pas charger d'assemblys depuis des tableaux d'octets	La révision de sécurité du code transparent n'est pas aussi complète que la révision de sécurité du code critique, car le code transparent ne peut pas exécuter d'actions relatives à la sécurité. Les assemblys chargés à partir d'un tableau d'octets peuvent ne pas être remarqués dans du code transparent, et ce tableau d'octets peut contenir du code critique, voire critique de sécurité, qui doit être audité.
CA2145 : Les méthodes transparentes ne doivent pas être décorées avec SuppressUnmanagedCodeSecurityAttribute	Les méthodes décorées avec l'attribut SuppressUnmanagedCodeSecurityAttribute ont un LinkDemand implicite sur toute méthode qui l'appelle. Ce LinkDemand requiert que le code appelant soit critique de sécurité. Le marquage de la méthode qui utilise SuppressUnmanagedCodeSecurity avec l'attribut SecurityCriticalAttribute rend cette spécification plus évidente pour les appelants de la méthode.
CA2146 : Les types doivent être au moins aussi critiques que les types de base et les interfaces	Cette règle se déclenche lorsqu'un type dérivé a un attribut de transparence de sécurité qui n'est pas aussi critique que son type de base ou l'interface implémentée. Seuls les types critiques peuvent dériver des types de base critiques ou implémenter des interfaces critiques, et seuls les types critiques ou critiques sécurisés peuvent dériver des types de base critiques sécurisés ou implémenter des interfaces critiques sécurisées.
CA2147 : Les méthodes transparentes ne peuvent pas utiliser d'assertions de sécurité	Aucune autorisation suffisante n'est accordée à un code marqué comme attribut SecurityTransparentAttribute pour procéder à une assertion.
CA2149 : Les méthodes transparentes ne doivent pas appeler du code natif	Cette règle se déclenche sur toute méthode transparente qui appelle directement en code natif (par exemple, via un appel P/Invoke). Les violations de cette règle provoquent une exception MethodAccessException dans le modèle de transparence de niveau 2, et une demande complète pour le code UnmanagedCode dans le modèle de transparence de niveau 1.