Avisos de segurança

Os avisos de segurança oferecem suporte a bibliotecas e aplicativos mais seguros.Esses avisos ajudam a evitar falhas de segurança em seu programa.Se você desabilitar um desses avisos, você deve marcar claramente a razão no código e também informar o agente de segurança designado para seu projeto de desenvolvimento.

Nesta seção

Regra	Descrição
CA2100: revisar consultas SQL para vulnerabilidades de segurança	Um método define a propriedade System.Data.IDbCommand.CommandText usando uma cadeia de caracteres criada com base em um argumento da cadeia de caracteres para o método.Esta regra pressupõe que o argumento da cadeia de caracteres contenha a entrada do usuário.Uma cadeia de caracteres de comando SQL criada com base na entrada do usuário é vulnerável a ataques de injeção SQL.
CA2102: capturar exceções que não sejam CLSCompliant em manipuladores gerais	Um membro em um assembly que não é marcado com o RuntimeCompatibilityAttribute ou que é marcado como RuntimeCompatibility (WrapNonExceptionThrows = false) contém um bloco de captura que trata System.Exception e não contém um bloco de captura geral imediatamente posterior.
CA2103: revisar segurança obrigatória	Um método usa segurança obrigatória e pode construir a permissão usando as informações de estado ou os valores de retorno que podem ser alterados enquanto a demanda estiver ativa.Use a segurança declarativa sempre que possível.
CA2104: não declarar tipos de referência mutáveis somente leitura	Um tipo visível externamente contém um campo somente leitura visível externamente que é um tipo de referência mutável.Um tipo mutável é um tipo cujos dados da instância podem ser modificados.
CA2105: os campos da matriz não devem ser somente leitura	Quando você aplica o modificador somente leitura (ReadOnly no Visual Basic) a um campo que contém uma matriz, o campo não pode ser alterado para fazer referência a uma matriz diferente.No entanto, os elementos da matriz armazenados em um campo somente leitura podem ser alterados.
CA2106: declarações seguras	Um método declara uma permissão e nenhuma verificação de segurança é realizada no chamador.A declaração de uma permissão de segurança sem realizar verificações de segurança pode deixar uma fraqueza de segurança explorável no código.
CA2107: revisar uso de deny e permit only	Usando o método PermitOnly e as ações de segurança CodeAccessPermission.Deny só devem ser usados por pessoas com conhecimento avançado de segurança do .NET Framework.O código que usa essas ações de segurança deve passar por uma revisão de segurança.
CA2108: revisar segurança declarativa em tipos de valor	Um tipo de valor público ou protegido é resguardado por acesso a dados ou exigências de vínculo.
CA2109: revisar manipuladores de eventos visíveis	Um método público ou protegido de tratamento de eventos foi detectado.Os métodos de tratamento de eventos não devem ser expostos, a menos que seja absolutamente necessário.
CA2111: os ponteiros não devem estar visíveis	Um ponteiro não é privado, interno ou somente leitura.Um código mal-intencionado pode alterar o valor do ponteiro, permitindo o acesso a locais arbitrários na memória ou causando falhas no aplicativo ou no sistema.
CA2112: os tipos seguros não devem expor campos	Um tipo público ou protegido contém campos públicos e é protegido por exigências de vínculo.Se tiver acesso a uma instância de um tipo protegido por uma exigência de vínculo, o código não precisará atender à exigência de vínculo para acessar os campos do tipo.
CA2114: a segurança de método deve ser um superconjunto de tipo	Um método não deve ter segurança declarativa no nível do método e no nível do tipo para a mesma ação.
CA2115: chamar GC.KeepAlive durante o uso de recursos nativos	Esta regra detecta erros que podem ocorrer porque um recurso não gerenciado está sendo finalizado, enquanto ainda está sendo usado em código não gerenciado.
CA2116: os métodos APTCA só devem chamar métodos APTCA	Quando o atributo APTCA (AllowPartiallyTrustedCallers) estiver presente em um assembly totalmente confiável e o assembly executar código em outro assembly que não permita chamadores parcialmente confiáveis, será possível uma exploração de segurança.
CA2117: os tipos APTCA só devem estender tipos base APTCA	Quando o atributo APTCA (AllowPartiallyTrustedCallers) estiver presente em um assembly totalmente confiável e um tipo no assembly for herdado de um tipo que não permita chamadores parcialmente confiáveis, será possível uma exploração de segurança.
CA2118: revisar uso de SuppressUnmanagedCodeSecurityAttribute	SuppressUnmanagedCodeSecurityAttribute altera o comportamento do sistema de segurança padrão para membros que executem código não gerenciado que usa interoperabilidade COM ou invocação da plataforma.Esse atributo é usado principalmente para aumentar o desempenho; no entanto, os ganhos de desempenho acompanham riscos de segurança significativos.
CA2119: os métodos para lacrar que atendam a interfaces privadas	Um tipo público herdável fornece uma implementação de método substituível de uma interface (Friend no Visual Basic) interna.Para corrigir uma violação dessa regra, evite que o método seja substituído fora do assembly.
CA2120: proteger construtores de serialização	Esse tipo tem um construtor que utiliza um objeto System.Runtime.Serialization.SerializationInfo e um objeto System.Runtime.Serialization.StreamingContext (a assinatura do construtor de serialização).Esse construtor não é protegido por uma verificação de segurança, mas um ou mais dos construtores regulares no tipo são protegidos.
CA2121: os construtores estáticos devem ser privados	O sistema chama o construtor estático antes que a primeira instância do tipo seja criada ou que outros membros estáticos sejam referenciados.Se não for privado, um construtor estático poderá ser chamado por um código diferente do sistema.Dependendo das operações realizadas no construtor, isso pode causar um comportamento inesperado.
CA2122: não expor indiretamente métodos com demandas de link	Um membro público ou protegido tem exigências de vínculo e é chamado por um membro que não realiza nenhuma verificação de segurança.Uma exigência de vínculo verifica as permissões apenas do chamador imediato.
CA2123: as demandas de link de substituição devem ser idênticas à base	Esta regra compara um método ao método de base, que é uma interface ou um método virtual em outro tipo e, em seguida, compara as exigências de vínculo em cada um.Se essa regra for violada, um chamador mal-intencionado poderá ignorar a exigência de vínculo apenas chamando o método não seguro.
CA2124: encapsular cláusulas finalmente vulneráveis em tentativa externa	Um método público ou protegido contém um bloco try/finally.O bloco finally aparentemente redefine o estado de segurança não está incluído em um bloco finally.
CA2126: demandas do link de tipo exigem demandas de herança	Um tipo sem lacre público é protegido com uma exigência de link e tem um método substituível.Nem o tipo nem o método é protegido com uma exigência de herança.
CA2136: os membros não devem ter anotações de transparência conflitantes	O código crítico não pode ocorrer em um assembly 100% transparente.Esta regra analisa assemblies 100% transparentes em busca de todas as anotações de SecurityCritical nos níveis de tipo, campo e método.
CA2147: os métodos transparentes talvez não usem declarações de segurança	Esta regra analisa todos os métodos e tipos em um assembly que seja 100% transparente ou transparente/crítico misto e sinaliza o uso declarativo ou obrigatório de Assert.
CA2140: o código transparente não deve fazer referência a itens críticos de segurança	Métodos que são marcados com SecurityTransparentAttribute chamam membros não públicos marcados como SecurityCritical.Esta regra analisa todos os métodos e tipos em um assembly que seja transparente/crítico misto, e sinaliza todas as chamadas de código transparente para o código crítico não público que não estejam marcadas como SecurityTreatAsSafe.

CA2130: as constantes críticas de segurança devem ser transparentes	A imposição de transparência não é imposta para valores constantes porque compiladores têm valores constantes internos de modo que nenhuma pesquisa seja necessária no tempo de execução.Os campos constantes devem ter segurança transparente de forma que os revisores de código não pressuponham que o código transparente não pode acessar a constante.
CA2131: os tipos críticos de segurança podem não participar da equivalência de tipo	Um tipo participa da equivalência do tipo e o próprio tipo, ou um membro ou campo do tipo, é marcado com o atributo SecurityCriticalAttribute.Esta regra é acionada em qualquer tipo crítico ou em tipos que contenham métodos críticos ou campos que estejam participando da equivalência do tipo.Ao detectar um tipo assim, o CLR não o carrega com um TypeLoadException em tempo de execução.Normalmente, essa regra só é acionada quando usuários implementam equivalência de tipo manualmente, em vez de depender de tlbimp e dos compiladores para fazer a equivalência do tipo.
CA2132: os construtores padrão devem ser pelo menos críticos como construtores padrão do tipo base	Os tipos e os membros que têm o SecurityCriticalAttribute não podem ser usados pelo código de aplicativo do Silverlight.Os tipos de segurança crítica e os membros só podem ser usados por código confiável no .NET Framework para a biblioteca de classes do Silverlight.Como uma construção pública ou protegida em uma classe derivada deve ter a mesma transparência maior que sua classe base, uma classe em um aplicativo não pode ser derivada de uma classe marcada como SecurityCritical.
CA2133: os representantes devem ser associados a métodos com transparência consistente	Esse aviso é acionado em um método que associa um representante que foi marcado com o SecurityCriticalAttribute para um método transparente ou marcado com o SecuritySafeCriticalAttribute.O aviso também é acionado em um método que associa um representante transparente ou de segurança crítica a um método crítico.
CA2134: os métodos devem manter uma transparência consistente durante a substituição dos métodos base	Essa regra é acionada quando um método marcado com o SecurityCriticalAttribute substitui um método transparente ou marcado com o SecuritySafeCriticalAttribute.A regra também é acionada quando um método transparente ou marcado com o SecuritySafeCriticalAttribute substitui um método marcado com um SecurityCriticalAttribute.A regra é aplicada durante a substituição de um método virtual ou a implementação de uma interface.
CA2135: os assemblies de nível 2 não devem conter LinkDemands	LinkDemands são preteridos no conjunto de regras de segurança nível 2.Em vez de usar LinkDemands para impor a segurança em tempo de compilação JIT (just-in-time), marque os métodos, os tipos e os campos com o atributo SecurityCriticalAttribute.
CA2136: os membros não devem ter anotações de transparência conflitantes	Os atributos de transparência são aplicados com base nos elementos de código de escopo maior a elementos de escopo menor.Os atributos de transparência dos elementos de código com escopo maior têm precedência sobre atributos de transparência dos elementos de código contidos no primeiro elemento.Por exemplo, uma classe marcada com o atributo SecurityCriticalAttribute não pode conter um método marcado com o atributo SecuritySafeCriticalAttribute.
CA2137: os métodos transparentes só devem conter IL verificável	Um método contém código não verificável ou retorna um tipo por referência.Esta regra é acionada em tentativas por código transparente de segurança para executar MSIL (Microsoft Intermediate Language) não verificável.Entretanto, a regra não contém um verificador de IL completo e, em vez disso, usa heurística para capturar a maioria das violações de verificação de MSIL.
CA2138: os métodos transparentes não devem chamar métodos com o atributo SuppressUnmanagedCodeSecurity	Um método de segurança transparente chama um método marcado com o atributo SuppressUnmanagedCodeSecurityAttribute.
CA2139: os métodos transparentes talvez não usem o atributo HandleProcessCorruptingExceptions	Esta regra é acionada por qualquer método que seja transparente e tenta tratar uma exceção de corrompimento de processo usando o atributo HandleProcessCorruptedStateExceptionsAttribute.Uma exceção de corrompimento de processo é uma classificação de exceção do CLR versão 4.0 de exceções, como AccessViolationException.O atributo HandleProcessCorruptedStateExceptionsAttribute só pode ser usado por métodos de segurança crítica e será ignorado se for aplicado a um método transparente.
CA2140: o código transparente não deve fazer referência a itens críticos de segurança	Um elemento de código marcado com o atributo SecurityCriticalAttribute é crítico para segurança.Um método transparente não pode usar um elemento crítico para segurança.Se um tipo transparente tentar usar um tipo crítico de segurança, um TypeAccessException, um MethodAccessException ou um FieldAccessException será acionado.
CA2141:Transparent métodos não devem atender a LinkDemands	Um método transparente de segurança chama um método em um assembly que não foi marcado com o atributo APTCA (AllowPartiallyTrustedCallersAttribute) ou um método transparente de segurança atende a um LinkDemand para um tipo ou um método.
CA2142: o código transparente não deve ser protegido com LinkDemands	Esta regra é acionada em métodos transparentes que exigem LinkDemands para serem acessados.O código transparente de segurança não deve ser responsável por verificar a segurança de uma operação e, assim, não deve exigir permissões.
CA2143: os métodos transparentes não devem usar demandas de segurança	O código transparente de segurança não deve ser responsável por verificar a segurança de uma operação e, assim, não deve exigir permissões.O código transparente de segurança deve usar demandas completas para tomar decisões de segurança e o código crítico de segurança não deve confiar no código transparente para fazer a demanda completa.
CA2144: o código transparente não deve carregar assemblies a partir de matrizes de bytes	A revisão de segurança para o código transparente não é tão completo quanto a revisão de segurança para o código crítico porque o código transparente não pode realizar ações confidenciais de segurança.Os assemblies carregados a partir de uma matriz de bytes podem não ser observados no código transparente e essa matriz de bytes pode conter código crítico ou código crítico de segurança mais importante, que precisa ser auditado.
CA2145: os métodos transparentes não devem ser decorados com o SuppressUnmanagedCodeSecurityAttribute	Os métodos decorados com o atributo SuppressUnmanagedCodeSecurityAttribute têm um LinkDemand implícito colocado em qualquer método que o chame.Este LinkDemand requer que o código de chamada seja crítico de segurança.A marcação do método que usa SuppressUnmanagedCodeSecurity com o atributo SecurityCriticalAttribute torna esse requisito mais óbvio para chamadores do método.
CA2146: tipos devem ser pelo menos críticos como tipos base e interfaces	Esta regra é acionada quando um tipo derivado tem um atributo de transparência de segurança que não é tão crítico quanto seu tipo de base ou interface implementada.Apenas os tipos críticos podem derivar os tipos de base críticos ou implementar interfaces críticos, e apenas os tipos críticos ou de segurança crítica podem derivar dos tipos de base críticos de segurança ou implementar interfaces críticas de segurança.
CA2147: os métodos transparentes talvez não usem declarações de segurança	O código que é marcado como SecurityTransparentAttribute não recebe permissões suficientes para declarar.
CA2149: os métodos transparentes não devem chamar código nativo	Esta regra é acionada em qualquer método transparente chamado diretamente no código nativo, por exemplo, por meio de um P/Invoke.As violações dessa regra resultam em um MethodAccessException no modelo de transparência de nível 2 e uma demanda completa para UnmanagedCode no modelo de transparência de nível 1.
CA2151: campos com tipos críticos devem ser críticos para segurança	Para usar tipos de segurança crítica, o código que faz referência ao tipo deve ser de segurança crítica ou de segurança crítica segura.Isso será verdadeiro mesmo que a referência seja indireta.Por isso, ter um campo de segurança transparente ou de segurança crítica é enganoso porque o código transparente continuará incapaz de acessar o campo.
CA5122: declarações P/Invoke não devem ser críticas para segurança	Os métodos são marcados como SecuritySafeCritical quando executam uma operação confidencial de segurança, mas também são seguros para serem usados pelo código transparente.O código transparente jamais pode chamar diretamente o código nativo por meio de um P/Invoke.Por isso, a marcação de um P/Invoke como crítico de segurança não permitirá que o código transparente o chame, e é enganosa na análise de segurança.