CA2147 : Les méthodes transparentes ne peuvent pas utiliser d'assertions de sécurité
TypeName |
SecurityTransparentCodeShouldNotAssert |
CheckId |
CA2147 |
Catégorie |
Microsoft.Security |
Modification avec rupture |
Oui |
Cause
Aucune autorisation suffisante n'est accordée à un code marqué comme SecurityTransparentAttribute pour procéder à une assertion.
Description de la règle
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 de Assert.
Au moment de l'exécution, tous les appels à Assert à partir d'un code transparent provoqueront la levée de InvalidOperationException.Cela peut se produire dans les assemblys entièrement transparents ainsi que dans les assemblys mi-transparents et mi-critiques, où une méthode ou un type est déclaré transparent, mais inclut une assertion déclarative ou impérative.
La version .NET Framework 2.0 a introduit une fonctionnalité appelée transparence.Les méthodes, les champs, les interfaces, les classes et les types individuels peuvent être transparents ou critiques.
Le code transparent n'est pas autorisé à élever les privilèges de sécurité.Par conséquent, toutes les autorisations accordées ou sollicitées sont automatiquement passées du code à l'appelant ou au domaine d'application d'hôte.Les exemples d'élévations incluent les assertions, les LinkDemands, l'attribut SuppressUnmanagedCode et le code unsafe.
Comment corriger les violations
Pour résoudre le problème, marquez le code qui appelle l'assertion en tant que SecurityCriticalAttribute ou supprimez l'assertion.
Quand supprimer les avertissements
Ne supprimez aucun message de cette règle.
Exemple
Ce code échouera si SecurityTestClass est transparent, lorsque la méthode Assert lève une InvalidOperationException.
using System;
using System.Security;
using System.Security.Permissions;
namespace TransparencyWarningsDemo
{
public class TransparentMethodsUseSecurityAssertsClass
{
// CA2147 violation - transparent code using a security assert declaratively. This can be fixed by
// any of:
// 1. Make DeclarativeAssert critical
// 2. Make DeclarativeAssert safe critical
// 3. Remove the assert attribute
[PermissionSet(SecurityAction.Assert, Unrestricted = true)]
public void DeclarativeAssert()
{
}
public void ImperativeAssert()
{
// CA2147 violation - transparent code using a security assert imperatively. This can be fixed by
// any of:
// 1. Make ImperativeAssert critical
// 2. Make ImperativeAssert safe critical
// 3. Remove the assert call
new PermissionSet(PermissionState.Unrestricted).Assert();
}
}
}
Une option consiste à réviser le code de la méthode SecurityTransparentMethod comme dans l'exemple ci-dessous, et si la méthode est considérée comme sans risque pour l'élévation, à la marquer comme critique sécurisée. Cela requiert qu'un audit de sécurité exempt d'erreurs, détaillé et exhaustif soit exécuté sur la méthode avec toutes les sorties d'appel qui se produisent dans cette dernière sous l'assertion :
using System;
using System.Security.Permissions;
namespace SecurityTestClassLibrary
{
public class SecurityTestClass
{
[System.Security.SecurityCritical]
void SecurityCriticalMethod()
{
new FileIOPermission(PermissionState.Unrestricted).Assert();
// perform I/O operations under Assert
}
}
}
Il est également possible de supprimer l'assertion du code et de permettre la transmission de toutes les demandes d'autorisation d'accès E/S au fichier suivantes au-delà de SecurityTransparentMethod par l'appelant.Cela permet des vérifications de sécurité.Dans ce cas, aucun audit de sécurité n'est habituellement nécessaire, car les demandes d'autorisation sont transmises à l'appelant et/ou au domaine d'application.Les demandes d'autorisation sont contrôlées attentivement au moyen de la stratégie de sécurité, de l'environnement d'hébergement et des autorisations liées à la source du code.