Exportar (0) Imprimir
Expandir Tudo
Este artigo foi traduzido por máquina. Coloque o ponteiro do mouse sobre as frases do artigo para ver o texto original. Mais informações.
Tradução
Original

Considerações sobre segurança relacionadas à reflexão

A reflexão fornece a capacidade de obter informações sobre tipos e membros, e acessar membros (isto é, para chamar métodos e construtores, para obter e definir valores de propriedade, para adicionar e remover manipuladores de eventos, e assim por diante). O uso de reflexão obter informações sobre tipos e membros não é restrito. Qualquer código pode usar a reflexão para executar as seguintes tarefas:

  • Enumera os tipos e membros, e examine seus metadados.

  • Enumera e examine os assemblies e os módulos.

Usar a reflexão para acessar membros, entretanto, está sujeita às limitações. A partir .NET Framework 4, somente o código confiável pode usar a reflexão para acessar membros de segurança importantes. Além disso, apenas o código confiável pode usar a reflexão para acessar os membros público que não são diretamente acessíveis ao código compilado. Finalmente, o código que usa a reflexão para acessar um membro seguro- crítico que o deve ter permissões demandas seguro- críticos do membro, como com o código compilado.

O assunto as permissões necessárias, código pode usar a reflexão para executar os seguintes tipos de acesso:

  • Membros públicos de acesso que não são críticos de segurança.

  • Membros de acesso público que seriam úteis ao código compilado, se eles não são críticos de segurança. Exemplos desses membros não público incluem:

    • Protegidos membros das classes base de código de chamada. (Na reflexão, isso é referenciado como o acesso de família- nível.)

    • membros deinternal (membros deFriend no Visual Basic) no assembly do código de chamada. (Na reflexão, isso é referenciado como o acesso de nível de assembly.)

    • Membros privados de outras instâncias da classe que contém o código de chamada.

Por exemplo, o código que é executado em um domínio de aplicativo sandboxed é limitado ao acesso descrito nessa lista, a menos que o domínio de aplicativo conceder permissões adicionais.

Iniciar com .NET Framework 2.0 Service Pack 1, tentando acessar os membros que geralmente são inacessíveis gerenciar uma procura o conjunto de concessão do objeto de destino mais ReflectionPermission com o sinalizador de ReflectionPermissionFlag.MemberAccess . O código que está executando com confiança total (por exemplo, código em um aplicativo que é iniciado na linha de comando) sempre pode atender essas permissões. (Isso está sujeito às restrições em acessar membros de segurança importantes, como descrito posteriormente neste artigo.)

Opcionalmente, um domínio de aplicativo sandboxed pode conceder ReflectionPermission com o sinalizador de ReflectionPermissionFlag.MemberAccess , como descrito na seção Acessando os membros que geralmente são inacessíveis, posteriormente neste artigo.

Um membro é crítico de segurança se tiver SecurityCriticalAttribute, se pertence a um tipo que tem SecurityCriticalAttribute, ou se estiver em um assembly de segurança crítico. A partir .NET Framework 4, as regras para acessar membros de segurança importantes são os seguintes:

  • O código transparente não pode usar a reflexão para acessar membros de segurança importantes, mesmo se o código é totalmente confiáveis. MethodAccessException , FieldAccessException, ou TypeAccessException são descartados.

  • O código que está executando com confiança parcial é tratada como transparente.

Essas regras são as mesmas se um membro de segurança crítico é acessado diretamente pelo código compilado, ou acessado usando a reflexão.

O código do aplicativo que é executado na linha de comando é executado com confiança total. Contanto que não é marcado como transparente, pode usar a reflexão para acessar membros de segurança importantes. Quando o mesmo código é executado com confiança parcial (por exemplo, em um domínio de aplicativo) sandboxed o nível de confiança do assembly determina se o pode acessar o código crítico de segurança: Se o assembly terá um nome forte e é instalado em cachê de assembly global, é um assembly de confiança e pode chamar membros de segurança importantes. Se não se baseia, será transparente mesmo que não seja marcado como transparente, e não pode acessar membros de segurança importantes.

Para obter mais informações sobre o modelo de segurança em .NET Framework 4, consulte Alterações na segurança do .NET Framework.

A partir .NET Framework 4, Common Language Runtime determina a transparência em nível de um tipo ou membro de vários fatores, inclusive o nível de confiança do assembly e o nível de confiança do domínio de aplicativo. A reflexão fornece IsSecurityCritical, IsSecuritySafeCritical, e as propriedades de IsSecurityTransparent para permite descobrir a transparência em nível de um tipo. A tabela a seguir mostra as combinações válidas dessas propriedades.

Nível de segurança

IsSecurityCritical

IsSecuritySafeCritical

IsSecurityTransparent

Crítico

true

false

false

Seguro-crítico

true

true

false

Transparente

false

false

true

O uso dessas propriedades é muito mais simples que revisando as anotações de segurança de um assembly e seus tipos, verificando o nível de confiança atual, e tentando duplicar as regras de tempo de execução. Por exemplo, o mesmo tipo pode ser segurança crítica quando é executado na linha de comando, ou segurança transparente quando o é executado em um domínio de aplicativo sandboxed.

Há propriedades semelhantes em MethodBase, em FieldInfo, em TypeBuilder, em MethodBuilder, e em classes de DynamicMethod . (Para a outra reflexão e a reflexão emite abstrações, os atributos de segurança são aplicados aos métodos associados; por exemplo, no caso das propriedades são aplicados aos acessadores da propriedade.)

Para usar a reflexão para invocar os membros que são inacessíveis de acordo com as regras de acessibilidade do Common Language Runtime, o código deve ter uma das duas permissões:

  • Para permitir que o código invocar qualquer membro público: O código deve ser concedido ReflectionPermission com o sinalizador de ReflectionPermissionFlag.MemberAccess .

    Observação Observação

    Por padrão, a política de segurança nega essa permissão código que se origina da Internet. Essa permissão nunca deve ser concedida para codificar que origina da Internet.

  • Para permitir que o código invocar qualquer membro público, contanto que o conjunto de concessão do assembly que contém o membro invocado é o mesmo que, ou um subconjunto do, o conjunto de concessão do assembly que contém o código invocando: O código deve ser concedido ReflectionPermission com o sinalizador de ReflectionPermissionFlag.RestrictedMemberAccess .

Por exemplo, suponha que o conceder permissões da Internet de um domínio do aplicativo mais ReflectionPermission com o sinalizador de ReflectionPermissionFlag.RestrictedMemberAccess , e então executar um aplicativo de Internet com dois assemblies, A e B.

  • O assembly pode usar à reflexão para acessar membros privados do assembly B, porque o conjunto de concessão do assembly B não inclui nenhuma permissão que A não recebeu.

  • O assembly A não pode usar a reflexão para acessar membros private assemblies de .NET Framework como mscorlib.dll, porque mscorlib.dll é totalmente confiáveis e em virtude disso tem as permissões que não foram concedidas ao assembly Para. MemberAccessException gerada quando a segurança de acesso do código mostra a pilha em tempo de execução.

Para serialização, SecurityPermission com o sinalizador de SecurityPermissionAttribute.SerializationFormatter fornece a capacidade de obter e definir membros de tipos serializáveis, independentemente de acessibilidade. Essa permissão permite que o código para descobrir e alterar o estado de uma instância particular. (Além da concessão de permissões apropriadas, o tipo deve ser marcado como serializável nos metadados.)

Evite escrever os membros públicos que obtêm parâmetros de MethodInfo , especialmente para o código de confiança. Esses membros podem ser mais vulneráveis ao código mal-intencionado. Por exemplo, considere um membro público no código altamente confiáveis que assume um parâmetro de MethodInfo . Suponha que o membro público indiretamente chama o método de Invoke no parâmetro fornecido. Se o membro utilitário não executa verificações de permissão necessárias, a chamada ao método de Invoke sempre terá êxito, porque o sistema de segurança determina quais o chamador está altamente confiável. Se o código mal-intencionado não tem permissão para invocar diretamente o método, ainda poderá fazer isso indiretamente chamando o membro público.

  • A partir .NET Framework 4, o código transparente não pode usar a reflexão para acessar membros de segurança importantes.

  • O sinalizador de ReflectionPermissionFlag.RestrictedMemberAccess é introduzido em .NET Framework 2.0 Service Pack 1. As versões anteriores de .NET Framework exigem o sinalizador de ReflectionPermissionFlag.MemberAccesspara o código que usa a reflexão para acessar membros público. Esta é uma permissão que nunca deve ser concedida ao código parcialmente confiável.

  • Iniciar com .NET Framework 2.0, usando a reflexão para obter informações sobre tipos e membros público não requer permissões. Em versões anteriores, ReflectionPermission com o sinalizador de ReflectionPermissionFlag.TypeInformationé necessário.

Contribuições da comunidade

ADICIONAR
Mostrar:
© 2015 Microsoft