CA2107 : Passez en revue l'utilisation des méthodes Deny et PermitOnly
TypeName |
ReviewDenyAndPermitOnlyUsage |
CheckId |
CA2107 |
Catégorie |
Microsoft.Security |
Modification avec rupture |
Oui |
Cause
Une méthode contient une vérification de la sécurité. Celle-ci spécifie l'action de sécurité PermitOnly ou Deny.
Description de la règle
Les actions de sécurité Utilisation de la méthode PermitOnly et CodeAccessPermission.Deny doivent être utilisées uniquement par des développeurs possédant une connaissance avancée de la sécurité du .NET Framework. Le code qui utilise ces actions de sécurité doit subir une révision de sécurité.
L'action de refus Deny modifie le comportement par défaut du parcours de la pile qui se produit en réponse à une demande de sécurité. Elle vous permet de spécifier des autorisations qui ne doivent pas être accordées sur la durée de la méthode de refus, indépendamment des autorisations réelles des appelants dans la pile des appels. Si le parcours de la pile détecte une méthode sécurisée par l'action Deny, et si l'autorisation demandée est intégrée aux autorisations refusées, le parcours de la pile échoue. L'action PermitOnly modifie également le comportement par défaut du parcours de la pile. Elle permet au code de spécifier uniquement les autorisations qui peuvent être accordées, indépendamment des autorisations dont disposent les appelants. Si le parcours de la pile détecte une méthode sécurisée par PermitOnly, et si l'autorisation demandée n'est pas intégrée aux autorisations spécifiées par l'action PermitOnly, le parcours de la pile échoue.
Un code qui repose sur ces actions doit faire l'objet d'une évaluation minutieuse en termes de faille de sécurité du fait de son utilité limitée et de son comportement subtil. Vous devez tenir compte des éléments suivants :
Les Demandes de liaison ne sont pas affectés par les actions Deny ou PermitOnly.
Si l'action Deny ou PermitOnly se produit dans le même frame de pile que la demande qui déclenche le parcours de la pile, les actions de sécurité n'ont aucun effet.
Les valeurs utilisées pour construire des autorisations fondées sur un chemin d'accès peuvent en général être spécifiées de plusieurs manières. Refuser l'accès à un des formulaires du chemin d'accès ne le refuse pas à tous les formulaires. Par exemple, si un partage de fichiers \\Server\Share est mappé à un lecteur réseau X:, pour refuser l'accès à un fichier de ce partage, vous devez le refuser à \\Server\Share\File, à X:\File, ainsi qu'à chaque autre chemin d'accès qui mène à ce fichier.
Un CodeAccessPermission.Assert peut mettre fin à un parcours de pile avant qu'une action Deny ou PermitOnly soit atteinte.
Si une action Deny a un effet, à savoir, lorsqu'un appelant voit une autorisation bloquée par Deny, cet appelant peut accéder directement à la ressource protégée, en ignorant l'action Deny. De même, si l'appelant ne dispose pas de l'autorisation refusée, le parcours de la pile échouera sans intervention de l'action Deny.
Comment corriger les violations
Toute utilisation de ces actions de sécurité provoquera une violation. Pour corriger une violation, n'utilisez pas ces actions de sécurité.
Quand supprimer les avertissements
Supprimez uniquement un avertissement de cette règle après avoir effectué une révision de sécurité.
Exemple
L'exemple suivant présente quelques limitations de l'action Deny.
La bibliothèque suivante contient une classe dotée de deux méthodes identiques en tout point exception faite des demandes de sécurité qui les protègent.
using System.Security;
using System.Security.Permissions;
using System;
namespace SecurityRulesLibrary
{
public class SomeSecuredMethods
{
// Demand immediate caller has suitable permission
// before revealing sensitive data.
[EnvironmentPermissionAttribute(SecurityAction.LinkDemand,
Read="COMPUTERNAME;USERNAME;USERDOMAIN")]
public static void MethodProtectedByLinkDemand()
{
Console.Write("LinkDemand: ");
}
[EnvironmentPermissionAttribute(SecurityAction.Demand,
Read="COMPUTERNAME;USERNAME;USERDOMAIN")]
public static void MethodProtectedByDemand()
{
Console.Write("Demand: ");
}
}
}
L'application suivante montre les effets de l'action Deny sur les méthodes sécurisées de la bibliothèque.
using System.Security;
using System.Security.Permissions;
using System;
using SecurityRulesLibrary;
namespace TestSecurityLibrary
{
// Violates rule: ReviewDenyAndPermitOnlyUsage.
public class TestPermitAndDeny
{
public static void TestAssertAndDeny()
{
EnvironmentPermission envPermission = new EnvironmentPermission(
EnvironmentPermissionAccess.Read,
"COMPUTERNAME;USERNAME;USERDOMAIN");
envPermission.Assert();
try
{
SomeSecuredMethods.MethodProtectedByDemand();
Console.WriteLine(
"Caller's Deny has no effect on Demand " +
"with the asserted permission.");
SomeSecuredMethods.MethodProtectedByLinkDemand();
Console.WriteLine(
"Caller's Deny has no effect on LinkDemand " +
"with the asserted permission.");
}
catch (SecurityException e)
{
Console.WriteLine(
"Caller's Deny protected the library.{0}", e);
}
}
public static void TestDenyAndLinkDemand()
{
try
{
SomeSecuredMethods.MethodProtectedByLinkDemand();
Console.WriteLine(
"Caller's Deny has no effect with " +
"LinkDemand-protected code.");
}
catch (SecurityException e)
{
Console.WriteLine(
"Caller's Deny protected the library.{0}",e);
}
}
public static void Main()
{
EnvironmentPermission envPermission = new EnvironmentPermission(
EnvironmentPermissionAccess.Read,
"COMPUTERNAME;USERNAME;USERDOMAIN");
envPermission.Deny();
//Test Deny and Assert interaction for LinkDemands and Demands.
TestAssertAndDeny();
//Test Deny's effects on code in different stack frame.
TestDenyAndLinkDemand();
//Test Deny's effect on code in same frame as deny.
try
{
SomeSecuredMethods.MethodProtectedByLinkDemand();
Console.WriteLine(
"This Deny has no effect with LinkDemand-protected code.");
}
catch (SecurityException e)
{
Console.WriteLine("This Deny protected the library.{0}",e);
}
}
}
}
Cet exemple génère la sortie suivante :
Voir aussi
Référence
CodeAccessPermission.PermitOnly
Concepts
Instructions de codage sécurisé