Compartilhar via

Problemas de segurança no Reflection Emit

O .NET Framework fornece três maneiras de emitir CIL (common intermediate Language), cada uma com seus próprios problemas de segurança:

Independentemente da maneira como você gera código dinâmico, a execução do código gerado requer todas as permissões exigidas pelos tipos e métodos que o código gerado usa.

Observação

As permissões necessárias para refletir sobre código e emitir código foram modificadas com as versões subsequentes do .NET Framework. Consulte informações sobre a versão, mais adiante neste artigo.

Assembléias dinâmicas

Os assemblies dinâmicos são criados usando as sobrecargas do método AppDomain.DefineDynamicAssembly. A maioria das sobrecargas desse método é preterida no .NET Framework 4 devido à eliminação da política de segurança em todo o computador. As sobrecargas restantes podem ser executadas por qualquer código, independentemente do nível de confiança. Essas sobrecargas se enquadram em dois grupos: aquelas que especificam uma lista de atributos a ser aplicada ao assembly dinâmico quando ele é criado e aquelas que não. Se você não especificar o modelo de transparência do assembly, aplicando o atributo SecurityRulesAttribute quando criá-lo, o modelo de transparência será herdado do assembly emissor.

Observação

Os atributos que você aplica ao assembly dinâmico depois que ele é criado, usando o SetCustomAttribute método, não entram em vigor até que o assembly tenha sido salvo no disco e carregado na memória novamente.

O código em um assembly dinâmico pode acessar membros e tipos visíveis em outros assemblies.

Observação

Os assemblies dinâmicos não usam os sinalizadores ReflectionPermissionFlag.MemberAccess e ReflectionPermissionFlag.RestrictedMemberAccess que permitem que os métodos dinâmicos acessem tipos e membros não públicos.

Montagens dinâmicas transitórias são criadas na memória e nunca salvas em disco, portanto, elas não requerem permissões de acesso a arquivos. Salvar um assembly dinâmico em disco requer FileIOPermission com os sinalizadores adequados.

Gerando módulos dinâmicos a partir de código com confiança parcial

Considere as condições em que um assembly com permissões de Internet pode gerar um assembly dinâmico transitório e executar seu código:

  • O assembly dinâmico usa apenas tipos e membros públicos de outros assemblies.

  • As permissões exigidas por esses tipos e membros são incluídas no conjunto de concessão do assembly parcialmente confiável.

  • O assembly não é salvo no disco.

  • Os símbolos de depuração não são gerados. (Internet e LocalIntranet conjuntos de permissões não incluem as permissões necessárias.)

Métodos dinâmicos hospedados anonimamente

Métodos dinâmicos hospedados anonimamente são criados usando os dois DynamicMethod construtores que não especificam um tipo ou módulo associado e DynamicMethod(String, Type, Type[])DynamicMethod(String, Type, Type[], Boolean). Esses construtores colocam os métodos dinâmicos em um assembly transparente de segurança totalmente confiável fornecido pelo sistema. Nenhuma permissão é necessária para usar esses construtores ou emitir código para os métodos dinâmicos.

Em vez disso, quando um método dinâmico hospedado anonimamente é criado, a pilha de chamadas é capturada. Quando o método é construído, as demandas de segurança são feitas em relação à pilha de chamadas capturada.

Observação

Conceitualmente, as exigências são estabelecidas durante a construção do método. Ou seja, as demandas podem ser feitas conforme cada instrução CIL for sendo emitida. Na implementação atual, todas as demandas são feitas quando o DynamicMethod.CreateDelegate método é chamado ou quando o compilador just-in-time (JIT) é invocado, se o método é invocado sem chamar CreateDelegate.

Se o domínio do aplicativo permitir, os métodos dinâmicos hospedados anonimamente poderão ignorar as verificações de visibilidade JIT, sujeitos à seguinte restrição: os tipos e membros não públicos acessados por um método dinâmico hospedado anonimamente devem estar em assemblies cujos conjuntos de concessões são iguais ou subconjuntos do conjunto de concessões da pilha de chamadas emissoras. Essa capacidade restrita de ignorar as verificações de visibilidade JIT é habilitada se o domínio do aplicativo concede ReflectionPermission com o sinalizador ReflectionPermissionFlag.RestrictedMemberAccess.

  • Se o seu método utilizar apenas tipos públicos e membros, nenhuma permissão será necessária durante a construção.

  • Se você especificar que as verificações de visibilidade JIT devem ser ignoradas, a solicitação feita quando o método é construído incluirá ReflectionPermission com o sinalizador ReflectionPermissionFlag.RestrictedMemberAccess e o conjunto de concessões do assembly que contém o membro não público sendo acessado.

Como o conjunto de concessões do membro não público é considerado, o código parcialmente confiável que recebeu ReflectionPermissionFlag.RestrictedMemberAccess não pode elevar seus privilégios executando membros não públicos de assemblies confiáveis.

Assim como acontece com qualquer outro código emitido, a execução do método dinâmico requer todas as permissões exigidas pelos métodos que o método dinâmico usa.

O assembly do sistema que hospeda métodos dinâmicos hospedados anonimamente usa o SecurityRuleSet.Level1 modelo de transparência, que é o modelo de transparência usado no .NET Framework antes do .NET Framework 4.

Para obter mais informações, consulte a classe DynamicMethod.

Gerando métodos dinâmicos hospedados anonimamente a partir de código parcialmente confiável

Considere as condições em que um assembly com permissões de Internet pode gerar um método dinâmico hospedado anonimamente e executá-lo:

  • O método dinâmico usa apenas tipos e membros públicos. Se o seu conjunto de concessões inclui ReflectionPermissionFlag.RestrictedMemberAccess, ele pode usar membros e tipos não públicos de qualquer assembly cujo conjunto de concessões seja igual ao, ou um subconjunto do, conjunto de concessões do assembly emissor.

  • As permissões exigidas por todos os tipos e membros usados pelo método dinâmico são incluídas no conjunto de concessões do assembly parcialmente confiável.

Observação

Os métodos dinâmicos não têm suporte para símbolos de depuração.

Métodos dinâmicos associados a assemblies existentes

Para associar um método dinâmico a um tipo ou módulo em um assembly existente, use qualquer um dos DynamicMethod construtores que especificam o tipo ou módulo associado. As permissões necessárias para chamar esses construtores variam, pois associar um método dinâmico a um tipo ou módulo existente fornece ao método dinâmico acesso a tipos e membros não públicos:

  • Um método dinâmico, quando associado a um tipo, tem acesso a todos os membros desse tipo, incluindo membros privados, bem como a todos os tipos internos e membros no conjunto de componentes que contém o tipo associado.

  • Um método dinâmico associado a um módulo tem acesso a todos os internal tipos e membros (Friend no Visual Basic, assembly em metadados do Common Language Runtime) no módulo.

Além disso, você pode usar um construtor que especifica a capacidade de ignorar as verificações de visibilidade do compilador JIT. Fazer isso concede ao seu método dinâmico o acesso a todos os tipos e membros em todos os assemblies, independentemente do nível de acesso.

As permissões exigidas pelo construtor dependem de quanto acesso você decide fornecer ao seu método dinâmico:

Embora os itens nessa lista estejam descritos em termos do conjunto de concessões do assembly emissor, lembre-se de que as exigências são feitas em relação à pilha de chamadas completa, incluindo o limite de domínio do aplicativo.

Para obter mais informações, consulte a classe DynamicMethod.

Gerando métodos dinâmicos de código parcialmente confiável

Observação

A maneira recomendada de gerar métodos dinâmicos de código parcialmente confiável é usar métodos dinâmicos hospedados anonimamente.

Considere as condições em que um assembly com permissões de Internet pode gerar um método dinâmico e executá-lo:

  • O método dinâmico está associado ao módulo ou tipo que o emite ou seu conjunto de concessões inclui ReflectionPermissionFlag.RestrictedMemberAccess e está associado a um módulo em um assembly cujo conjunto de concessões é igual ou a um subconjunto do conjunto de concessões do assembly emissor.

  • O método dinâmico usa apenas tipos e membros públicos. Se o conjunto de concessões inclui ReflectionPermissionFlag.RestrictedMemberAccess e está associado a um módulo em um assembly cujo conjunto de concessões é igual ou um subconjunto do conjunto de concessões do assembly emissor, ele pode usar tipos e membros marcados internal (Friend no Visual Basic, assembly em metadados de common language runtime) no módulo associado.

  • As permissões exigidas por todos os tipos e membros usados pelo método dinâmico são incluídas no conjunto de concessões do assembly parcialmente confiável.

  • O método dinâmico não ignora as verificações de visibilidade JIT.

Observação

Os métodos dinâmicos não têm suporte para símbolos de depuração.

Informações de versão

A partir do .NET Framework 4, a política de segurança em todo o sistema é eliminada e a transparência de segurança torna-se o mecanismo de imposição padrão.

A partir do .NET Framework 2.0 Service Pack 1, ReflectionPermission com o sinalizador ReflectionPermissionFlag.ReflectionEmit não é mais necessário ao emitir assemblies dinâmicos e métodos dinâmicos. Esse sinalizador é necessário em todas as versões anteriores do .NET Framework.

Observação

ReflectionPermission com o sinalizador ReflectionPermissionFlag.ReflectionEmit é incluído por padrão nos conjuntos de permissões denominados FullTrust e LocalIntranet, mas não no conjunto de permissões Internet. Portanto, em versões anteriores do .NET Framework, uma biblioteca só poderá ser usada com permissões de Internet se executar um Assert for ReflectionEmit. Essas bibliotecas exigem uma revisão de segurança cuidadosa porque erros de codificação podem resultar em falhas de segurança. O .NET Framework 2.0 SP1 permite que o código seja emitido em cenários parciais de confiança sem emitir nenhuma demanda de segurança, pois gerar código não é inerentemente uma operação privilegiada. Ou seja, o código gerado não tem mais permissões do que o assembly que o emite. Isso permite que as bibliotecas que emitem código sejam transparentes de segurança e removam a necessidade de afirmar ReflectionEmit, o que simplifica a tarefa de escrever uma biblioteca segura.

Além disso, o .NET Framework 2.0 SP1 apresenta o ReflectionPermissionFlag.RestrictedMemberAccess sinalizador para acessar tipos não públicos e membros de métodos dinâmicos parcialmente confiáveis. Versões anteriores do .NET Framework exigem o ReflectionPermissionFlag.MemberAccess sinalizador para métodos dinâmicos que acessam tipos e membros não públicos; essa é uma permissão que nunca deve ser concedida a um código parcialmente confiável.

Por fim, o .NET Framework 2.0 SP1 apresenta métodos hospedados anonimamente.

Obtendo informações sobre tipos e membros

A partir do .NET Framework 2.0, nenhuma permissão é necessária para obter informações sobre tipos e membros não públicos. A reflexão é usada para obter informações necessárias para emitir métodos dinâmicos. Por exemplo, MethodInfo os objetos são usados para emitir chamadas de método. Versões anteriores do .NET Framework exigem ReflectionPermission com o sinalizador ReflectionPermissionFlag.TypeInformation. Para obter mais informações, consulte Considerações de segurança para reflexão.

Consulte também

  • Last updated on