Gerenciado regras recomendado conjunto de regras para código gerenciado
Você pode usar a regra de Microsoft Managed recomendado regras definida para enfocar os problemas mais críticos no seu código gerenciado, incluindo possíveis brechas de segurança, travamentos de aplicativos e outros erros de lógica e de design importantes.Você deve incluir essa regra definida em qualquer conjunto de regras personalizadas que você cria para seus projetos.
Regra |
Descrição |
---|---|
Os tipos que possuem campos descartáveis devem ser descartáveis |
|
Declarar os manipuladores de eventos corretamente |
|
Assemblies de marca com AssemblyVersionAttribute |
|
Métodos de interface devem ser chamados por tipos de filho |
|
Os tipos que possuem recursos nativos devem ser descartáveis |
|
Mover P/Invokes à classe NativeMethods |
|
Não ocultar métodos da classe base |
|
Implementar IDisposable corretamente |
|
Não aumente exceções em locais inesperados |
|
Evite aceleradores duplicados |
|
Os pontos de entrada de P/Invoke devem existir. |
|
P/Invokes não deverá ser visível |
|
Tipos de layout automático não devem ser visível em COM |
|
Chamar GetLastError imediatamente após P/Invoke. |
|
Tipos base do tipo visível COM devem estar visível em COM |
|
Métodos de registro COM devem ser correspondidos. |
|
Declarar P/Invokes corretamente |
|
Remover os finalizadores vazios |
|
Campos do tipo de valor devem ser portátil |
|
Declarações P/Invoke devem ser portátil |
|
Não bloquear em objetos com identidade fraco |
|
Analisar consultas SQL para vulnerabilidades de segurança |
|
Especificar o empacotamento para argumentos de seqüência de caracteres de P/Invoke. |
|
Revisão de segurança declarativos sobre tipos de valor |
|
Ponteiros não deverá ser visíveis |
|
Tipos protegidos não devem expor campos |
|
A segurança do método deve ser um superconjunto do tipo |
|
Métodos APTCA só deverá chamar métodos APTCA |
|
Tipos APTCA só devem estender tipos básicos de APTCA |
|
Não exponha indiretamente métodos com as demandas de link |
|
As demandas de link de substituição devem ser idênticas para basear |
|
Quebra automática de linha vulnerável finalmente tente cláusulas no exterior |
|
As demandas de link do tipo exigem demandas de herança |
|
Tipos de críticos de segurança não podem participar de equivalência de tipo |
|
Construtores padrão devem ser pelo menos tão importantes como construtores do tipo base padrão |
|
Delegados devem ligar para métodos com transparência consistente |
|
Métodos devem manter a transparência consistente quando os métodos base |
|
Métodos transparentes devem conter apenas IL verificável |
|
Métodos transparentes não devem chamar métodos com o atributo SuppressUnmanagedCodeSecurity |
|
Código Transparent não deve fazer referência a itens essenciais de segurança |
|
Métodos transparentes não devem atender a LinkDemands |
|
Os tipos devem ser pelo menos, tão importantes quanto seus tipos base e interfaces |
|
Métodos transparentes não podem usar a segurança asserts |
|
Métodos transparentes não devem chamar código nativo |
|
Relançar para preservar os detalhes de pilha |
|
Não dispor objetos várias vezes |
|
Inicializar o tipo de valor campos estáticos in-line |
|
Não marque os componentes de serviço com WebMethod |
|
Campos descartáveis devem ser descartados. |
|
Não chamar métodos substituíveis em construtores |
|
Tipos descartáveis devem declarar o finalizador |
|
Os finalizadores devem chamar o finalizador da classe base |
|
Implementar os construtores de serialização |
|
Sobrecarga de operador é igual a sobre a anulação de ValueType.Equals |
|
Pontos de entrada da marca Windows Forms com STAThread |
|
Marcar todos os campos não serializáveis |
|
Chamar métodos da classe base em tipos ISerializable |
|
Tipos de ISerializable de marca com o SerializableAttribute |
|
Implementar métodos de serialização corretamente |
|
Implementa ISerializable corretamente |
|
Fornecer argumentos corretos para métodos de formatação. |
|
Testar NaN corretamente |