CA2118 : Révision de l'utilisation de SuppressUnmanagedCodeSecurityAttribute
TypeName |
ReviewSuppressUnmanagedCodeSecurityUsage |
CheckId |
CA2118 |
Catégorie |
Microsoft.Security |
Modification avec rupture |
Oui |
Cause
Un type ou un membre public ou protégé dispose de l'attribut System.Security.SuppressUnmanagedCodeSecurityAttribute.
Description de la règle
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é à l'aide de COM Interop ou de l'appel de code non managé.En général, le système effectue un Données et modélisation dans le .NET Framework pour l'autorisation de code non managé.Cette demande se produit au moment de l'exécution pour chaque appel au membre et vérifie l'autorisation de chaque appelant présent dans la pile des appels.Lorsque l'attribut est présent, le système effectue un Demandes de liaison pour l'autorisation : les autorisations de l'appelant immédiat sont vérifiées lorsque celui-ci est traité par le compilateur JIT.
Cet attribut est essentiellement utilisé pour accroître les performances ; toutefois, les gains de performance s'accompagnent de risques substantiels pour la sécurité.Si vous placez l'attribut sur des membres publics qui appellent des méthodes natives, les appelants présents dans la pile des appels (autre que l'appelant immédiat) n'ont pas besoin d'autorisation pour exécuter le code non managé.Selon les actions du membre public et la gestion des entrées, les appelants non fiables de confiance peuvent accéder à des fonctionnalités normalement restreintes à un code fiable.
Le .NET Framework repose sur des vérifications de sécurité visant à empêcher des appelants d'obtenir un accès direct à l'espace d'adressage du processus actuel.Sachant que cet attribut contourne la sécurité normale, votre code constitue une sérieuse menace s'il peut être utilisé pour effectuer des opérations de lecture ou d'écriture dans la mémoire du processus.Notez que le risque ne se limite pas aux méthodes qui donnent intentionnellement accès à la mémoire d'un processus : il est également présent dans tout scénario où un code malveillant peut obtenir un accès par quelque moyen que ce soit ; par exemple, en fournissant des entrées déconcertantes, incorrectes ou non valides.
La stratégie de sécurité par défaut n'accorde à un code non managé aucune autorisation d'accès à un assembly, saut s'il s'exécute à partir de l'ordinateur local ou s'il est membre de l'un des groupes suivants :
Groupe de code de la zone Poste de travail
Groupe de code des noms forts Microsoft
Groupe de code des noms forts ECMA
Comment corriger les violations
Passez méticuleusement en revue votre code pour vous assurer que cet attribut est absolument nécessaire.Si vous êtes peu familiarisé avec la sécurité du code managé, ou si vous ne comprenez pas les implications en termes de sécurité de l'utilisation de cet attribut, supprimez-le de votre code.Si l'attribut est requis, vous devez vous assurer que les appelants ne peuvent pas utiliser votre code de manière néfaste.Si votre code n'est pas autorisé à exécuter un code non managé, cet attribut n'a aucun effet et doit être supprimé.
Quand supprimer les avertissements
Pour supprimer sans risque un avertissement de cette règle, vous devez vous assurer que votre code ne donne aux appelants aucun accès à des opérations ou des ressources natives susceptibles d'être utilisées de façon néfaste.
Exemple
L'exemple suivant enfreint la règle.
using System.Security;
// These two classes are identical
// except for the location of the attribute.
namespace SecurityRulesLibrary
{
public class MyBadMemberClass
{
[SuppressUnmanagedCodeSecurityAttribute()]
public void DoWork()
{
FormatHardDisk();
}
void FormatHardDisk()
{
// Code that calls unmanaged code.
}
}
[SuppressUnmanagedCodeSecurityAttribute()]
public class MyBadTypeClass
{
public void DoWork()
{
FormatHardDisk();
}
void FormatHardDisk()
{
// Code that calls unmanaged code.
}
}
}
Dans l'exemple suivant, la méthode DoWork fournit un chemin d'accès de code publiquement accessible à la méthode d'appel de code non managé FormatHardDisk.
using System.Security;
using System.Runtime.InteropServices;
namespace SecurityRulesLibrary
{
public class SuppressIsOnPlatformInvoke
{
// The DoWork method is public and provides unsecured access
// to the platform invoke method FormatHardDisk.
[SuppressUnmanagedCodeSecurityAttribute()]
[DllImport("native.dll")]
private static extern void FormatHardDisk();
public void DoWork()
{
FormatHardDisk();
}
}
// Having the attribute on the type also violates the rule.
[SuppressUnmanagedCodeSecurityAttribute()]
public class SuppressIsOnType
{
[DllImport("native.dll")]
private static extern void FormatHardDisk();
public void DoWork()
{
FormatHardDisk();
}
}
}
Dans l'exemple suivant, la méthode publique DoDangerousThing entraîne une violation.Pour corriger la violation, DoDangerousThing doit être rendu privée, et l'accès à celle-ci doit se faire par le biais d'une méthode publique sécurisée par une demande de sécurité, comme illustré par la méthode DoWork.
using System.Security;
using System.Security.Permissions;
using System.Runtime.InteropServices;
namespace SecurityRulesLibrary
{
[SuppressUnmanagedCodeSecurityAttribute()]
public class BadTypeWithPublicPInvokeAndSuppress
{
[DllImport("native.dll")]
public static extern void DoDangerousThing();
public void DoWork()
{
// Note that because DoDangerousThing is public, this
// security check does not resolve the violation.
// This only checks callers that go through DoWork().
SecurityPermission secPerm = new SecurityPermission(
SecurityPermissionFlag.ControlPolicy |
SecurityPermissionFlag.ControlEvidence
);
secPerm.Demand();
DoDangerousThing();
}
}
}
Voir aussi
Référence
System.Security.SuppressUnmanagedCodeSecurityAttribute