Partilhar via


CA2147: Métodos transparentes não podem usar a segurança asserts

TypeName

SecurityTransparentCodeShouldNotAssert

CheckId

CA2147

<strong>Categoria</strong>

Microsoft.Security

Alteração significativa

Quebrando

Causa

Código que está marcado como SecurityTransparentAttribute não é concedido permissões suficientes para declarar.

Descrição da regra

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.

At executados o tempo, todas as chamadas para Assert no código transparent fará com que uma InvalidOperationException ser acionada. Isso pode ocorrer em ambos os assemblies transparente de 100% e em assemblies de crítica transparente mistos onde um método ou o tipo é declarado transparente, mas inclui um Assert declarativa ou imperativa.

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

Código Transparent não é permitido para elevar os privilégios de segurança. Portanto, todas as permissões concedidas ou exigidos dela são passadas automaticamente através do código para o domínio de aplicativo do chamador ou host. As elevações exemplos Asserts, LinkDemands, SuppressUnmanagedCode, e unsafe código.

Como corrigir violações

Para resolver o problema, ou marcar o código que chama o Assert com o SecurityCriticalAttribute, ou remover o Assert.

Quando suprimir avisos

Não suprimir a mensagem de que essa regra.

Exemplo

Esse código falhará se SecurityTestClass é transparente, quando o Assert método lança um InvalidOperationException.

using System;
using System.Security;
using System.Security.Permissions;

namespace TransparencyWarningsDemo
{

    public class TransparentMethodsUseSecurityAssertsClass
    {
        // CA2147 violation - transparent code using a security assert declaratively.  This can be fixed by
        // any of:
        //   1. Make DeclarativeAssert critical
        //   2. Make DeclarativeAssert safe critical
        //   3. Remove the assert attribute
        [PermissionSet(SecurityAction.Assert, Unrestricted = true)]
        public void DeclarativeAssert()
        {
        }

        public void ImperativeAssert()
        {
            // CA2147 violation - transparent code using a security assert imperatively.  This can be fixed by
            // any of:
            //   1. Make ImperativeAssert critical
            //   2. Make ImperativeAssert safe critical
            //   3. Remove the assert call
            new PermissionSet(PermissionState.Unrestricted).Assert();
        }
    }
}

Uma opção é o método SecurityTransparentMethod no exemplo abaixo de revisão de código e se o método é considerado seguro para elevação, marcar SecurityTransparentMethod com secure crítico isso requer que uma auditoria de segurança detalhada, completa e livre de erros deve ser executada no método juntamente com quaisquer transferências de chamada que ocorrem dentro do método em Assert:

using System;
using System.Security.Permissions;

namespace SecurityTestClassLibrary
{
    public class SecurityTestClass
    {
        [System.Security.SecurityCritical]
        void SecurityCriticalMethod()
        {
            new FileIOPermission(PermissionState.Unrestricted).Assert();

            // perform I/O operations under Assert
        }
    }
}

Outra opção é remover o Assert do código e permitir que qualquer arquivo subseqüente de fluxo de demandas de permissão do e/S além SecurityTransparentMethod ao chamador. Isso permite que as verificações de segurança. Nesse caso, nenhuma auditoria de segurança geralmente é necessária, pois as demandas de permissão fluirá para o chamador e/ou o domínio do aplicativo. Perto, demandas de permissão são controladas por meio da diretiva de segurança, que hospeda o ambiente e concessões de permissão do código-fonte.

Consulte também

Outros recursos

Avisos de segurança