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.