Avvisi di sicurezza

Gli avvisi di sicurezza supportano librerie e applicazioni più sicure.Questi avvisi contribuiscono ad evitare che il programma presenti difetti nella sicurezza.Se si disabilita qualsiasi di questi avvisi, è opportuno indicarne chiaramente il motivo nel codice e informare il responsabile della sicurezza designato per il progetto di sviluppo.

In questa sezione

Regola	Descrizione
CA2100: Controllare la vulnerabilità della sicurezza nelle query SQL	Un metodo imposta la proprietà utilizzando una stringa compilata da un argomento stringa nel metodo.La regola presuppone che l'argomento stringa contenga l'input dell'utente.Una stringa di comando SQL compilata in base all'input dell'utente è vulnerabile agli attacchi SQL injection.
CA2102: Individuare le eccezioni non conformi a CLS nei gestori generali	Un membro in un assembly che non è contrassegnato con l'attributo RuntimeCompatibilityAttribute o che è contrassegnato con RuntimeCompatibility(WrapNonExceptionThrows = false) contiene un blocco catch che gestisce System.Exception e non contiene un blocco catch generale immediatamente successivo.
CA2103: Controllare la sicurezza imperativa	Un metodo utilizza la sicurezza imperativa e potrebbe costruire l'autorizzazione tramite le informazioni sullo stato o i valori restituiti che possono essere modificati mentre la richiesta è attiva.Utilizzare la sicurezza dichiarativa quando possibile.
CA2104: Non dichiarare tipi di riferimento modificabili in sola lettura	Un tipo visibile esternamente contiene un campo in sola lettura visibile esternamente che costituisce un tipo di riferimento modificabile.Un tipo modificabile è un tipo i cui dati di istanza possono essere modificati.
CA2105: I campi di matrici non devono essere di sola lettura	Quando si applica il modificatore (ReadOnly in Visual Basic) in sola lettura a un campo contenente una matrice, il campo non può essere modificato in modo da fare riferimento a una matrice diversa.È tuttavia possibile modificare gli elementi della matrice archiviati in un campo in sola lettura.
CA2106: Asserzioni protette	Un metodo asserisce un'autorizzazione e non vengono eseguiti controlli di sicurezza sul chiamante.Quando si asserisce un'autorizzazione di sicurezza senza eseguire alcun controllo di sicurezza, nel codice potrebbero restare punti deboli nella sicurezza.
CA2107: Controllare l'utilizzo di Deny e PermitOnly	Il metodo PermitOnly e le azioni di sicurezza CodeAccessPermission.Deny devono essere utilizzati esclusivamente da utenti con una conoscenza approfondita della sicurezza .NET Framework.Il codice che utilizza queste azioni di sicurezza deve essere sottoposto a una revisione della sicurezza.
CA2108: Controllare la sicurezza dichiarativa sui tipi di valori	Un tipo di valore pubblico o protetto è protetto da richieste di collegamento o accesso ai dati.
CA2109: Controllare i gestori di eventi visibili	È stato rilevato un metodo di gestione eventi pubblico o protetto.I metodi di gestione eventi non devono essere esposti se non assolutamente necessario.
CA2111: I puntatori non devono essere visibili	Un puntatore non è privato, interno o in sola lettura.Il valore del puntatore può essere modificato dal codice dannoso, consentendo potenzialmente l'accesso a percorsi arbitrari nella memoria o causando errori dell'applicazione o del sistema.
CA2112: I tipi protetti non devono esporre campi	In un tipo pubblico o protetto sono inclusi campi pubblici; tale tipo viene protetto da richieste di collegamento.Se il codice ha accesso a un'istanza di un tipo protetta da una richiesta di collegamento, non è necessario che il codice soddisfi la richiesta di collegamento per accedere ai campi del tipo.
CA2114: La sicurezza del metodo deve essere un superset del tipo	Un metodo non può presentare sicurezza dichiarativa sia a livello di metodo sia a livello di tipo per la stessa azione.
CA2115: Chiamare GC.KeepAlive durante l'utilizzo di risorse native	Questa regola rileva gli errori che possono verificarsi qualora una risorsa non gestita venga completata mentre è ancora utilizzata da codice non gestito.
CA2116: I metodi APTCA devono chiamare solo metodi APTCA	Quando l'attributo APTCA (AllowPartiallyTrustedCallers) è presente su un assembly completamente attendibile e l'assembly esegue codice in un altro assembly che non consente chiamanti parzialmente attendibili, è possibile che si verifichi una violazione della sicurezza.
CA2117: I tipi APTCA devono estendere solo tipi di base APTCA	Quando l'attributo APTCA (AllowPartiallyTrustedCallers) è presente su un assembly completamente attendibile e un tipo nell'assembly eredita da un tipo che non consente chiamanti parzialmente attendibili, è possibile che si verifichi una violazione della sicurezza.
CA2118: Verificare la sintassi di SuppressUnmanagedCodeSecurityAttribute	SuppressUnmanagedCodeSecurityAttribute consente di modificare il comportamento del sistema di sicurezza predefinito per i membri che eseguono codice non gestito mediante interoperabilità COM o chiamata al sistema operativo.Questo attributo viene principalmente utilizzato per aumentare le prestazioni. L'aumento delle prestazioni, tuttavia, comporta notevoli rischi in termini di sicurezza.
CA2119: Impostare come sealed i metodi che soddisfano interfacce private	Un tipo pubblico ereditabile fornisce un'implementazione di metodo sottoponibile a override di un'interfaccia interna (Friend in Visual Basic).Per correggere una violazione di questa regola, impedire che venga eseguito l'override del metodo esternamente all'assembly.
CA2120: Proteggere i costruttori di serializzazione	Questo tipo dispone di un costruttore che accetta un oggetto System.Runtime.Serialization.SerializationInfo e un oggetto System.Runtime.Serialization.StreamingContext (la firma del costruttore della serializzazione).Questo costruttore non è protetto da un controllo di sicurezza, ma uno o più costruttori regolari nel tipo sono protetti.
CA2121: I costruttori statici devono essere privati	Il costruttore statico viene chiamato prima che venga creata la prima istanza del tipo o venga fatto riferimento a qualsiasi membro statico.Se un costruttore statico non è privato, può essere chiamato da codice esterno al sistema.A seconda delle operazioni eseguite nel costruttore, questa situazione può causare comportamenti imprevisti.
CA2122: Non esporre in modo indiretto metodi con richieste di collegamento	Un membro pubblico o protetto presenta richieste di collegamento e viene chiamato da un membro che non esegue alcun controllo della sicurezza.Una richiesta di collegamento controlla esclusivamente le autorizzazioni del chiamante immediato.
CA2123: Le richieste di collegamento negli verrine devono essere identiche a quelle nei metodi di base	Questa regola associa un metodo al relativo metodo di base che può essere un'interfaccia o un metodo virtuale in un altro tipo, quindi confronta le richieste di collegamento in ognuno.Se questa regola viene violata, un chiamante malintenzionato può ignorare la richiesta di collegamento chiamando semplicemente il metodo non sicuro.
CA2124: Eseguire il wrapping delle clausole finally vulnerabili in un try esterno	Un metodo pubblico o protetto contiene un blocco try/finally.Il blocco finally dovrebbe reimpostare lo stato di sicurezza e non è incluso in un altro blocco finally.
CA2126: Per le richieste di collegamento dei tipi sono necessarie richieste di ereditarietà	Un tipo non sealed pubblico è protetto con una richiesta di collegamento e dispone di un metodo sottoponibile a override.Né il tipo né il metodo sono protetti con una richiesta di ereditarietà.
CA2136: I membri non devono avere annotazioni di trasparenza in conflitto	In un assembly trasparente al 100% non è possibile riscontrare codice critico.Questa regola verifica l'eventuale presenza di annotazioni SecurityCritical a livello di tipo, campo e metodo all'interno di assembly trasparenti al 100%.
CA2147: Il codice Transparent non può utilizzare asserzioni di sicurezza	Questa regola analizza tutti i metodi e i tipi in un assembly trasparente al 100% o trasparente/critico e contrassegna l'utilizzo dichiarativo o imperativo di Assert.
CA2140: Il codice Transparent non deve far riferimento a elementi SecurityCritical	I metodi contrassegnati con SecurityTransparentAttribute chiamano membri non pubblici, a loro volta contrassegnati con SecurityCritical.Questa regola analizza tutti i metodi e i tipi in un assembly trasparente/critico e contrassegna qualsiasi chiamata da codice trasparente a codice critico non pubblico non contrassegnato con SecurityTreatAsSafe.

CA2130: Le costanti SecurityCritical devono essere Transparent	L'imposizione della trasparenza non viene applicata ai valori costanti perché i compilatori rendono inline valori costanti in modo che non sia richiesta alcuna ricerca in fase di esecuzione.I campi costanti devono essere trasparenti per la sicurezza in modo che i revisori del codice non suppongano che il codice trasparente non possa accedere alla costante.
CA2131: I tipi SecurityCritical possono non partecipare all'equivalenza del tipo	Un tipo partecipa all'equivalenza del tipo e il tipo stesso o un membro o un campo del tipo è contrassegnato con l'attributo SecurityCriticalAttribute.Questa regola viene attivata su qualsiasi tipo critico o a tipi che contengono metodi o campi critici che partecipano all'equivalenza del tipo.Quando CLR rileva tale tipo, non lo carica con TypeLoadException in fase di esecuzione.In genere, questa regola funziona solo quando gli utenti implementano l'equivalenza del tipo manualmente piuttosto che basarsi su tlbimp e i compilatori per fare l'equivalenza del tipo.
CA2132: I costruttori predefiniti devono essere Critical almeno come i costruttori predefiniti del tipo base	I tipi e i membri che presentano SecurityCriticalAttribute non possono essere utilizzati dal codice dell'applicazione Silverlight.I tipi e i membri critici per la sicurezza possono essere utilizzati solo da codice attendibile nella libreria di classi .NET Framework per Silverlight.Poiché una costruzione pubblica o protetta in una classe derivata deve disporre della trasparenza uguale o superiore alla classe di base, una classe in un'applicazione non può essere derivata da una classe contrassegnata come SecurityCritical.
CA2133: Delegati devono essere associati ai metodi con trasparenza consistente	Questo avviso è generato su un metodo che associa un delegato contrassegnato con SecurityCriticalAttribute a un metodo trasparente o contrassegnato con SecuritySafeCriticalAttribute.L'avviso genera anche un metodo che associa un delegato che è trasparente o critico per la sicurezza a un metodo critico.
CA2134: I metodi devono conservare trasparenza consistente durante l'override dei metodi base	Questa regola viene attivata quando un metodo contrassegnato con SecurityCriticalAttribute esegue l'override di un metodo trasparente o contrassegnato con SecuritySafeCriticalAttribute.Questa regola viene inoltre attivata quando un metodo trasparente o contrassegnato con SecuritySafeCriticalAttribute esegue l'override di un metodo contrassegnato con SecurityCriticalAttribute.La regola è applicata in caso di esecuzione dell'override di un metodo virtuale o di implementazione di un'interfaccia.
CA2135: Gli assembly di livello 2 non devono contenere LinkDemands	I LinkDemand sono deprecati nel set di regole per la sicurezza di livello 2.Anziché utilizzare i LinkDemand per applicare la sicurezza nella compilazione just-in-time (JIT), contrassegnare i metodi, i tipi e campi con l'attributo SecurityCriticalAttribute.
CA2136: I membri non devono avere annotazioni di trasparenza in conflitto	Gli attributi di trasparenza vengono applicati da elementi di codice con un ambito più ampio a elementi con ambito più ridotto.Gli attributi di trasparenza di elementi di codice che presentano un ambito più ampio hanno la precedenza su quelli contenuti nel primo elemento.Ad esempio, una classe contrassegnata con l'attributo SecurityCriticalAttribute non può contenere un metodo contrassegnato con l'attributo SecuritySafeCriticalAttribute.
CA2137: I metodi Transparent devono contenere solo IL verificabile	Un metodo contiene codice non verificabile o restituisce un tipo tramite riferimento.Questa regola viene attivata sui tentativi tramite codice trasparente per la sicurezza per eseguire MSIL (Microsoft Intermediate Language) non verificabile.Tuttavia, la regola non contiene un verificatore di IL completo, ma utilizza invece regole euristiche per intercettare la maggior parte delle violazioni di verifica MSIL.
CA2138: I metodi Transparent non devono chiamare i metodi con l'attributo SuppressUnmanagedCodeSecurity	Un metodo trasparente per la sicurezza chiama un metodo contrassegnato con l'attributo SuppressUnmanagedCodeSecurityAttribute.
CA2139: I metodi Transparent non possono utilizzare l'attributo HandleProcessCorruptingExceptions	Questa regola viene attivata da qualsiasi metodo trasparente che tenti di gestire un'eccezione che danneggia il processo tramite l'attributo HandleProcessCorruptedStateExceptionsAttribute.Un'eccezione che danneggia il processo è una classificazione di eccezione CLR versione 4.0, ad esempio AccessViolationException.L'attributo HandleProcessCorruptedStateExceptionsAttribute può essere utilizzato solo dai metodi critici per la sicurezza e sarà ignorato se applicato a un metodo trasparente.
CA2140: Il codice Transparent non deve far riferimento a elementi SecurityCritical	Un elemento di codice contrassegnato con l'attributo SecurityCriticalAttribute è critico per la sicurezza.Un metodo trasparente non può utilizzare un elemento critico per la sicurezza.Se un tipo trasparente tenta di utilizzare un tipo critico per la sicurezza viene generata un eccezione TypeAccessException, MethodAccessException o FieldAccessException.
CA2141:I metodi Transparent non devono soddisfare i LinkDemand	Un metodo trasparente per la sicurezza chiama un metodo in un assembly che non è contrassegnato con l'attributo AllowPartiallyTrustedCallersAttribute (APTCA) oppure un metodo trasparente per la sicurezza soddisfa un LinkDemand per un tipo o un metodo.
CA2142: Il codice Transparent non deve essere protetto con LinkDemand	Questa regola funziona su metodi trasparenti di cui richiedono a LinkDemands l'accesso.Il codice SecurityTransparent non deve essere responsabile della verifica della sicurezza di un'operazione e quindi non deve richiedere autorizzazioni.
CA2143: I metodi Transparent non devono utilizzare SecurityDemand	Il codice SecurityTransparent non deve essere responsabile della verifica della sicurezza di un'operazione e quindi non deve richiedere autorizzazioni.Il codice trasparente per la sicurezza deve utilizzare richieste complete per prendere decisioni relative alla sicurezza e il codice critico per la sicurezza non deve basarsi sul codice trasparente per l'esecuzione della richiesta completa.
CA2144: Il codice Transparent non deve caricare assembly da matrici di byte	La revisione di sicurezza per il codice trasparente non è accurata come la revisione di sicurezza per il codice critico, perché il primo non può eseguire azioni sensibili per la sicurezza.Assembly caricati da una matrice di byte potrebbero non essere notati nel codice trasparente e quella matrice di byte potrebbe contenere codice critico o ancora più importante codice critico per la sicurezza, che deve essere controllato.
CA2145: I metodi Transparent non devono includere SuppressUnmanagedCodeSecurityAttribute	I metodi decorati con l'attributo SuppressUnmanagedCodeSecurityAttribute presentano un LinkDemand implicito su ogni metodo che lo chiama.Questo LinkDemand richiede che il codice chiamante sia SecurityCritical.Contrassegnare il metodo che utilizza SuppressUnmanagedCodeSecurity con l'attributo SecurityCriticalAttribute rende più ovvio questo requisito per i chiamanti del metodo.
CA2146: I tipi devono essere Critical almeno come le interfacce e i tipi base relativi	Questa regola viene attivata quando un tipo derivato dispone di un attributo di trasparenza di sicurezza che non è critico come il tipo di base o l'interfaccia implementata.Solo i tipi critici possono derivare da tipi di base critici o implementare interfacce critiche e solo tipi critici o critici per la sicurezza possono derivare da tipi di base critici per la sicurezza o implementare interfacce critiche per la sicurezza.
CA2147: Il codice Transparent non può utilizzare asserzioni di sicurezza	Al codice contrassegnato come SecurityTransparentAttribute non sono concesse autorizzazioni sufficienti per l'asserzione.
CA2149: I metodi Transparent non devono effettuare chiamate nel codice nativo	Questa regola funziona su qualsiasi metodo trasparente che chiama direttamente in codice nativo, ad esempio, tramite P/Invoke.Le violazioni di questa regola conducono a MethodAccessException nel modello di trasparenza di livello 2 e a una richiesta completa per UnmanagedCode nel modello di trasparenza di livello 1.