Código transparente de segurança não deve referenciar membros da crítica de segurança não-públicos

Artigo
08/25/2010

TypeName	SecurityTransparentCodeShouldNotReferenceNonpublicSecurityCriticalCode
CheckId	CA2129
Category (Categoria)	Microsoft.segurança
Quebrando alterar	Quebrando

Causa

Métodos marcados com SecurityTransparentAttribute chamam membros não públicos que são marcados sistema autônomo SecurityCritical. SecurityTransparent é a designação padrão para métodos.

Descrição da regra

The .NET Framework 2.0 introduziu um recurso chamado transparência.Métodos individuais, campos, interfaces, classes e tipos podem ser transparente ou crítico.

Código transparente não é permitido para elevar privilégios de segurança.Portanto, quaisquer permissões concedidas ou exigidos dele são passados por meio do código automaticamente para o chamador ou AppDomain do host.Exemplos de elevações incluem Asserts, LinkDemands, SuppressUnmanagedCode e código não seguro.

A finalidade de separar código transparente e crítico é simplificar o processo de auditoria de segurança.Auditorias são normalmente executar nos pontos de entrada pública devido a possibilidade de uso público mal-intencionados e não confiável.Marcando seções menores de um assembly sistema autônomo crítica, a auditoria de segurança pode ser reduzida para pontos de entrada públicos e sistema autônomo seções de crítica segurança do código que elevem privilégios.No entanto, para certificar-se de que a auditoria é precisas e completas, a fronteira entre código transparente e crítico deve ser reforçada sistema autônomo altamente possível.A alternativa seria permitir código transparente chamar código crítico internas de segurança, que requer o código a serem auditados muito mais transparente.

Em tempo de execução, o compilador de just-in-time de tempo de execução de linguagem comuns verifica se código transparente está fazendo referência ou chamar código crítico de segurança não-públicos.Se for feita uma telefonar do código transparente para o código critical não-públicos, uma exceção, sistema autônomo um MethodAccessException poderia ser lançada.Isso é tratado da mesma forma para uma classe tentando acessar os membros privados de outra classe.

Esta regra de análise de código analisa todos os métodos e tipos em um assembly que é misturado transparente/crítica.Esta regra também sinaliza qualquer chamadas de código transparente para o código critical não públicos que não estejam marcadas SecurityTreatAsSafe.

Como corrigir violações

Para resolver o problema, ou marcar o código que chama o código de SecurityCritical não-públicos sistema autônomo SecurityCritical ou marcar o método/tipo de destino sistema autônomo SecurityTreatAsSafe.Isso efetivamente trata o código sistema autônomo pública segura e auditada para proteção contra objetivos mal-intencionados.

Quando suprimir avisos

Elimina uma mensagem a partir dessa regra.

Exemplo

O código a seguir irá falhar porque SecondSecurityMethod é particular e SecurityCritical.Exemplo de um problema de segurança, Assert em SecondSecurityMethod impedirá que completa sistema autônomo demandas em ações privilegiadas e transferências de telefonar para fluir para FirstSecurityMethod, limitado a segurança verifica que são executadas ao chamador.

using System;
using System.Security.Permissions;

namespace SecurityTestClassLibrary
{
    public class SecurityTestClass
    {
        // SecurityTransparent
        public void FirstSecurityMethod()
        {
            SecondSecurityMethod();
        }

        [System.Security.SecurityCritical]
        private void SecondSecurityMethod()
        {
            // Assert permissions

            // do privileged actions, such as method call-outs
        }
    }
}

Se o limite transparente/crítica não foi aplicado, FirstSecurityMethod poderão executar ações do SecondSecurityMethod todos os sem as verificações de segurança.

Uma opção é o método de análise do código e se o método é considerado seguro para elevação e contra ataques mal-intencionados, marque o com SecurityTreatAsSafe:

using System;
using System.Security.Permissions;

namespace SecurityTestClassLibrary
{
    public class SecurityTestClass
    {
        // SecurityTransparent
        public void FirstSecurityMethod()
        {
            SecondSecurityMethod();
        }

        [System.Security.SecurityTreatAsSafe]
        [System.Security.SecurityCritical]
        private void SecondSecurityMethod()
        {
            // Assert permissions

            // do privileged actions, such as method call-outs
        }
    }
}

Outra opção é fazer Method1 também crítica.Isso expande o kernel crítico do assembly e aumenta o dimensionar da auditoria de segurança.Ele também garante que a ameaça apropriado modelagem e fluxo de análise de código seja executada.

using System;
using System.Security.Permissions;

namespace SecurityTestClassLibrary
{
    public class SecurityTestClass
    {
        [System.Security.SecurityCritical]
        public void FirstSecurityMethod()
        {
            SecondSecurityMethod();
        }

        [System.Security.SecurityCritical]
        private void SecondSecurityMethod()
        {
            // Assert permissions

            // do privileged actions, such as method call-outs
        }
    }
}