CA2107: Controllare l'utilizzo di Deny e PermitOnly
TypeName |
ReviewDenyAndPermitOnlyUsage |
CheckId |
CA2107 |
Categoria |
Microsoft.Security |
Breaking Change |
Breaking |
Causa
Un metodo contiene un controllo di sicurezza che specifica l'azione di sicurezza PermitOnly o Deny.
Descrizione della regola
Le azioni di sicurezza Utilizzo del metodo PermitOnly e CodeAccessPermission.Deny devono essere utilizzate esclusivamente da utenti che possiedono una conoscenza approfondita della sicurezza .NET Framework.Il codice che utilizza queste azioni di sicurezza deve essere sottoposto a una revisione della sicurezza.
Deny altera il comportamento predefinito del percorso chiamate nello stack che si verifica in risposta a una richiesta di sicurezza.Consente di specificare le autorizzazioni che non devono essere concesse per la durata del metodo Deny, indipendentemente dalle autorizzazioni effettive dei chiamanti nello stack di chiamate.Se nel percorso stack viene rilevato un metodo protetto da Deny e l'autorizzazione richiesta è inclusa nelle autorizzazioni negate, il percorso stack avrà esito negativo.Anche PermitOnly altera il comportamento predefinito del percorso chiamate nello stack.Consente al codice di specificare solo le autorizzazioni che è possibile concedere, indipendentemente dalle autorizzazioni dei chiamanti.Se nel percorso stack viene rilevato un metodo protetto da PermitOnly e le autorizzazioni richieste non sono incluse nelle autorizzazioni specificate da PermitOnly, il percorso stack avrà esito negativo.
Il codice che si basa su queste azioni deve essere valutato attentamente per individuarne le vulnerabilità di sicurezza a causa della limitata utilità e del particolare comportamento.Si consideri quanto segue.
Deny e PermitOnly non hanno effetto su Richieste di collegamento.
Se Deny o PermitOnly si verifica nello stesso stack frame della richiesta che causa il percorso stack, le azioni di sicurezza non avranno effetto.
I valori utilizzati per costruire le autorizzazioni basate su percorso possono in genere essere specificati in molti modi.Negando l'accesso a un formato del percorso non si nega l'accesso a tutte le forme.Se ad esempio una condivisione file \\Server\Condivisione è mappata su un'unità di rete X:, per negare l'accesso a un file in tale condivisione sarà necessario negare \\Server\Condivisione\File, X:\File e ogni altro percorso che consente di accedere al file.
Un metodo CodeAccessPermission.Assert può terminare un percorso stack prima che venga raggiunta l'operazione Deny o PermitOnly.
Se l'operazione Deny produce un qualsiasi effetto, ovvero se un'autorizzazione di un chiamante è bloccata da Deny, il chiamante potrà accedere direttamente alla risorsa protetta, ignorando Deny.Analogamente, se il chiamante non dispone dell'autorizzazione negata, il percorso stack avrà esito negativo senza l'operazione Deny.
Come correggere le violazioni
Qualsiasi utilizzo di queste azioni di sicurezza causerà una violazione.Per correggere una violazione, non utilizzare queste azioni di sicurezza.
Esclusione di avvisi
Escludere un avviso da questa regola dopo aver completato una revisione della sicurezza.
Esempio
Nell'esempio riportato di seguito vengono illustrate alcune limitazioni di Deny.
La libreria riportata di seguito contiene una classe con due metodi identici, ad eccezione delle richieste di sicurezza che li proteggono.
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'applicazione riportata di seguito dimostra gli effetti di Deny sui metodi protetti della libreria.
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);
}
}
}
}
Questo esempio produce l'output che segue.
Vedere anche
Riferimenti
CodeAccessPermission.PermitOnly
Concetti
Override dei controlli di sicurezza
Utilizzo del metodo PermitOnly