Avisos de segurança
Avisos de segurança oferecem suporte a aplicativos e bibliotecas mais seguro. Esses avisos ajudam a evitar falhas de segurança no seu programa. Se você desabilitar qualquer um desses avisos, você deve claramente marcam o motivo no código e também informar o responsável por segurança designado para o seu projeto de desenvolvimento.
Nesta seção
Regra |
Descrição |
---|---|
CA2100: Analisar consultas SQL vulnerabilidades de segurança |
Um método define a propriedade de System.Data.IDbCommand.CommandText usando uma seqüência de caracteres que é criada a partir de um argumento de seqüência de caracteres para o método. Esta regra pressupõe que o argumento de seqüência de caracteres contém a entrada do usuário. Uma seqüência de caracteres de comando SQL criada a partir da entrada do usuário é vulnerável a ataques de injeção de SQL. |
CA2102: Catch não CLSCompliant exceções nos manipuladores gerais |
Um membro em um assembly que não está marcado com o RuntimeCompatibilityAttribute ou está marcado como RuntimeCompatibility(WrapNonExceptionThrows = false) contém um bloco catch que manipula Exception e não contém um bloco catch geral de imediatamente a seguir. |
Um método usa segurança imperativa e pode construir a permissão usando valores de retorno ou de informações de estado que podem ser alterado enquanto a demanda está ativa. Use a segurança declarativa, sempre que possível. |
|
CA2104: Não declarar os tipos de referência mutáveis somente leitura |
Um tipo visível externamente contém um campo visível externamente de somente leitura que é um tipo de referência mutáveis. Um tipo de mutável é um tipo de dados cujos instância podem ser modificados. |
Quando você aplica o modificador de read-only (somente leitura em 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 armazenada em um campo somente leitura podem ser alterados. |
|
Um método declara que uma permissão e verificações de segurança não são executadas no chamador. Declarar uma permissão de segurança sem executar qualquer verificações de segurança podem deixar uma fraqueza de segurança pode ser explorada em seu código. |
|
Usando o PermitOnly método e ações de segurança de CodeAccessPermission.Deny devem ser usadas somente por aqueles com conhecimento avançado dos.NET Framework security. Código que usa essas ações de segurança deve passar por uma revisão de segurança. |
|
CA2108: Revisão de segurança declarativos sobre tipos de valor |
Um tipo de valor público ou protegido é protegido pelas demandas de Link ou de acesso a dados. |
Um método de manipulação de eventos do público ou protegido foi detectado. Métodos de manipulação de eventos não devem ser expostos a menos que absolutamente necessário. |
|
Um ponteiro não é particular, interno ou somente leitura. Código mal-intencionado pode alterar o valor do ponteiro, potencialmente permitindo o acesso a locais arbitrários na memória ou causando falhas de aplicativo ou sistema. |
|
Um tipo de público ou protegido contém campos públicos e é protegido pelas demandas de Link. Se o código possui acesso a uma instância de um tipo que é protegido por uma demanda de link, não tem o código atender à demanda de link para acessar os campos do tipo. |
|
CA2114: A segurança do método deve ser um superconjunto do tipo |
Um método não deve ter o nível de método e o tipo de nível de segurança declarativa para a mesma ação. |
Essa regra detecta erros que podem ocorrer devido um recurso não gerenciado está sendo finalizado enquanto ainda estiver sendo usado no código não gerenciado. |
|
Quando o atributo APTCA (AllowPartiallyTrustedCallers) está presente em um assembly totalmente confiável e o assembly executa o código em outro conjunto que não permite chamadores parcialmente confiáveis, é possível a uma exploração de segurança. |
|
CA2117: Tipos APTCA só devem estender tipos básicos de APTCA |
Quando o atributo APTCA (AllowPartiallyTrustedCallers) está presente em um assembly totalmente confiável e um tipo no assembly herda a partir de um tipo que não permite chamadores parcialmente confiáveis, é possível a uma exploração de segurança. |
CA2118: Revise o uso de SuppressUnmanagedCodeSecurityAttribute |
SuppressUnmanagedCodeSecurityAttribute altera o comportamento do sistema de segurança padrão para membros que executar o código não gerenciado que usa invocação de plataforma ou de interoperabilidade COM. Esse atributo é usado principalmente para aumentar o desempenho; No entanto, o desempenho ganha vêm com consideráveis riscos à segurança. |
CA2119: Lacrar métodos que satisfaçam às interfaces privadas |
Um tipo de público herdável fornece uma implementação do método substituível de uma interface interna do (amigo em Visual Basic). Para corrigir uma violação desta regra, impedir que o método seja substituído fora do assembly. |
Esse tipo tem um construtor que leva a um objeto de System.Runtime.Serialization.SerializationInfo e um objeto de System.Runtime.Serialization.StreamingContext (a assinatura do construtor de serialização). Este construtor não é protegido por uma verificação de segurança, mas um ou mais dos construtores regulares no tipo estão protegidos. |
|
O sistema chama o construtor estático antes da primeira instância do tipo é criada ou quaisquer membros estáticos são referenciados. Se um construtor estático não é particular, pode ser chamado pelo código diferente do sistema. Dependendo das operações são executadas no construtor, isso pode causar um comportamento inesperado. |
|
CA2122: Não exponha indiretamente métodos com demandas de link |
Um membro público ou protegido com demandas de Link e é chamado por um membro que não executa quaisquer verificações de segurança. Uma demanda de link verifica as permissões do chamador imediato. |
CA2123: Demandas de link de substituição devem ser idênticas a base |
Esta regra corresponde a um método para o método base, que é uma interface ou um método virtual em outro tipo e então compara as demandas de link em cada um. Se esta regra for violada, um chamador mal intencionado pode ignorar a demanda de link simplesmente chamando o método não seguro. |
CA2124: Quebrar vulnerável finalmente tente cláusulas no exterior |
Um método público ou protegido contém um bloco try/finally. O finalmente bloco é exibido redefinir o estado de segurança e não o próprio está contido em um bloco finally. |
CA2126: As demandas de link do tipo exigem demandas de herança |
Um tipo de público sem lacre é protegido com uma demanda de link e tem um método substituível. O tipo nem o método é protegido com uma demanda de herança. |
CA2136: Os membros não devem ter anotações conflitantes de transparência |
O código Critical não pode ocorrer em um assembly transparente para 100%. Esta regra analisa os assemblies de 100% transparentes para quaisquer anotações SecurityCritical no tipo, no campo e no método. |
CA2147: Métodos transparentes não podem usar a segurança asserts |
Esta regra analisa todos os métodos e tipos em um assembly que é um dos 100% transparente ou misto transparente/crítica e sinaliza qualquer uso declarativo ou imperativo de Assert. |
CA2140: Código Transparent não deve fazer referência a itens essenciais de segurança |
Métodos marcados com SecurityTransparentAttribute chamam membros não públicos que são marcados como SecurityCritical. Esta regra analisa todos os métodos e tipos em um assembly que é misto crítica transparente e sinaliza qualquer chamadas de código transparente para o código critical não públicos não marcados como SecurityTreatAsSafe. |
CA2130: Constantes críticas de segurança devem ser transparentes |
Aplicação de transparência não é imposta para valores constantes porque valores de constante embutido de compiladores para que nenhuma pesquisa é necessária em tempo de execução. Campos constantes devem ser transparente de segurança para que os revisores de código não assumem que o código transparent não pode acessar a constante. |
---|---|
CA2131: Tipos importantes de segurança não podem participar de equivalência de tipo |
Participa de um tipo de equivalência de tipo e um tanto o próprio tipo ou um membro ou um campo do tipo, é marcado com o atributo SecurityCriticalAttribute. Essa regra é acionado em qualquer críticos tipos ou tipos que contêm métodos críticos ou campos que estão participando da equivalência de tipo. Quando o CLR detecta desse tipo, ele falhará para carregá-lo com um TypeLoadException em tempo de execução. Normalmente, essa regra é acionado somente quando os usuários a implementar a equivalência de tipo manualmente em vez de por contar com tlbimp e os compiladores para fazer a equivalência do tipo. |
Tipos e membros que possuem o SecurityCriticalAttribute não podem ser usados pelo código de aplicativo do Silverlight. Membros e tipos de segurança crítica podem ser usados somente pelo código confiável na.NET Framework para a biblioteca de classes do Silverlight. Porque uma construção pública ou protegida em uma classe derivada deve ter a transparência igual ou maior que sua classe base, uma classe em um aplicativo não pode ser derivada uma classe marcada SecurityCritical. |
|
CA2133: Delegados devem ligar para métodos com transparência consistente |
Esse aviso é acionado em um método que vincula a um delegado que é marcado com o SecurityCriticalAttribute para um método que é transparente ou que está marcado com o SecuritySafeCriticalAttribute. O aviso também é acionado um método que vincula a um delegado que é transparente ou crítico de seguro para um método critical. |
CA2134: Métodos devem manter a transparência consistente quando os métodos base |
Essa regra é acionado quando um método marcado com o SecurityCriticalAttribute substitui um método que é transparente ou marcados com o SecuritySafeCriticalAttribute. A regra também é acionado quando um método que é transparente ou marcados com o SecuritySafeCriticalAttribute substitui um método marcado com um SecurityCriticalAttribute. A regra é aplicada ao substituir uma virtual método ou a implementação de uma interface. |
CA2135: Assemblies de nível 2 não devem conter a LinkDemands |
LinkDemands estão obsoletas no conjunto de regras de segurança de nível 2. Em vez de usar LinkDemands para reforçar a segurança em tempo de compilação just-in-time (JIT), marca campos com o atributo SecurityCriticalAttribute, métodos e tipos. |
CA2136: Os membros não devem ter anotações conflitantes de transparência |
Atributos de transparência são aplicados a partir de elementos de código de maior escopo para elementos de escopo menor. Os atributos de transparência dos elementos de código com escopo de maior prevalecem sobre atributos de transparência dos elementos de código que estão 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: Métodos transparentes devem conter apenas o IL verificável |
Um método contém código ou retorna um tipo por referência. Essa regra é acionado tentativas pelo código transparent de segurança para executar a MSIL não verificável (Microsoft Intermediate Language). No entanto, a regra não contém um verificador de IL completo e em vez disso, usa heurística para detectar a maioria das violações de verificação de MSIL. |
CA2138: 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: Métodos transparentes não podem usar o atributo HandleProcessCorruptingExceptions |
Essa regra é acionado a qualquer método que é transparente e tenta lidar com um processo corrompendo exceção usando o atributo HandleProcessCorruptedStateExceptionsAttribute. Um processo corrompendo a exceção é uma classificação de exceção de versão 4.0 do CLR de exceções de tal AccessViolationException. O atributo HandleProcessCorruptedStateExceptionsAttribute pode ser usado somente por métodos de segurança crítica e será ignorado se for aplicado a um método transparente. |
CA2140: Código Transparent não deve fazer referência a itens essenciais de segurança |
Um elemento de código que está marcado com o atributo SecurityCriticalAttribute é crítica de segurança. Um método transparente não é possível usar um elemento crítico da segurança. Se um tipo transparente tenta usar um tipo de segurança crítica é gerado um TypeAccessException, MethodAccessException ou FieldAccessException. |
CA2141: métodos transparentes não devem atender a LinkDemands |
Um método de segurança transparente chama um método em um assembly que não está marcado com o atributo AllowPartiallyTrustedCallersAttribute (APTCA) ou um método de segurança transparente satisfaz um LinkDemand para um tipo ou um método. |
CA2142: Código Transparent não deve ser protegido por LinkDemands |
Essa regra é acionado em métodos transparentes que requerem a LinkDemands para acessá-los. Código de segurança transparente não deve ser responsável por verificar a segurança de uma operação e, portanto, não deve exigir permissões. |
CA2143: Métodos transparentes não devem usar demandas de segurança |
Código de segurança transparente não deve ser responsável por verificar a segurança de uma operação e, portanto, não deve exigir permissões. Código de segurança transparente deve usar as demandas completas para tomar decisões de segurança e código crítico de segurança não deve confiar no código transparent ter feito a demanda completa. |
CA2144: Código Transparent não deve carregar assemblies de matrizes de bytes |
A revisão de segurança para o código transparent não é o mais completa, como a revisão de segurança para o código critical, porque o código transparent não pode executar ações de segurança confidenciais. Assemblies carregados a partir de uma matriz de bytes não podem ser observados no código transparente e a matriz de bytes que pode conter código crítico ou seguro mais importante crítico que precisam ser auditadas. |
CA2145: Métodos transparentes não devem ser decorados com o SuppressUnmanagedCodeSecurityAttribute. |
Métodos decorados com o atributo SuppressUnmanagedCodeSecurityAttribute tem um LinkDemand implícito colocada em qualquer método que o chama. Este LinkDemand requer que o código de chamada crítica de segurança. Marcar o método que usa SuppressUnmanagedCodeSecurity com o atributo SecurityCriticalAttribute faz essa exigência mais óbvio para chamadores do método. |
CA2146: Os tipos devem ser pelo menos, tão importantes quanto seus tipos base e interfaces |
Essa regra é acionado quando um tipo derivado tem um atributo de transparência de segurança que não é tão importante quanto o seu tipo base ou implementada a interface. Somente os tipos de críticos podem derivar tipos importantes de base ou implementar interfaces críticos e somente os tipos de críticos ou safe críticos podem derivar de tipos de base seguros críticos ou implementar interfaces safe críticas. |
CA2147: Métodos transparentes não podem usar a segurança asserts |
Código que está marcado como SecurityTransparentAttribute não é concedido permissões suficientes para declarar. |
CA2149: Métodos transparentes não devem chamar código nativo |
Essa regra é acionado em qualquer método transparente que chama diretamente no código nativo, por exemplo, por meio de um P/Invoke. Violações desta regra causar 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. |