Este artigo foi traduzido por máquina. Para visualizar o arquivo em inglês, marque a caixa de seleção Inglês. Você também pode exibir o texto Em inglês em uma janela pop-up, movendo o ponteiro do mouse sobre o texto.
Tradução
Inglês

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

 

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

  • Enumerar tipos e membros e examinar seus metadados.

  • Enumerar e examine os módulos e assemblies.

Por outro lado, usando a reflexão para acessar membros, estão sujeitos a restrições. Começando com o .NET Framework 4, somente o código confiável pode usar reflexão para acessar membros de segurança crítica. Além disso, somente o código confiável pode usar reflexão para acessar membros não públicos não estariam acessíveis diretamente em código compilado. Finalmente, o código que usa reflexão para acessar um membro crítico de segurança deve ter as permissões as demandas de segurança crítica membro, apenas como com código compilado.

Sujeito a permissões necessárias, o código pode usar reflexão para realizar os seguintes tipos de acesso:

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

  • Acessar membros não públicos que estariam acessíveis ao código compilado, se esses membros não são críticas de segurança. Exemplos de tais membros não públicos:

    • Membros protegidos de classes base do código de chamada. (Na reflexão, isso é chamado como acesso no nível de família.)

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

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

Por exemplo, código que é executado em um domínio de aplicativo na área restrita é limitado ao acesso descrito nesta lista, a menos que o domínio de aplicativo concede permissões adicionais.

Começando com o .NET Framework 2.0 Service Pack 1, tentando acessar membros não podem ser acessados normalmente gera uma demanda para o conjunto de concessões do objeto de destino mais ReflectionPermission com o ReflectionPermissionFlag.MemberAccess sinalizador. Código que está sendo executado com confiança total (por exemplo, o código em um aplicativo que é iniciado a partir da linha de comando) sempre pode atender a essas permissões. (Isso é sujeitas às limitações no acesso a membros de segurança crítica, conforme descrito posteriormente neste artigo.)

Opcionalmente, um domínio de aplicativo na área restrita pode conceder ReflectionPermission com o ReflectionPermissionFlag.MemberAccess sinalizador, conforme descrito na seção acessar membros que são normalmente inacessível, mais adiante neste artigo.

Um membro é crítico de segurança se ele tem o SecurityCriticalAttribute, se ele pertence a um tipo que tem o SecurityCriticalAttribute, ou se ele está em um assembly de segurança crítica. Começando com o .NET Framework 4, as regras para acessar membros crítico de segurança são os seguintes: 

Essas regras são os mesmos se um membro de segurança crítica é acessado diretamente pelo código compilado ou acessado por meio de reflexão.

Código do aplicativo que é executado a partir da linha de comando é executado com confiança total. Desde que ele não está marcado como transparente, ele pode usar reflexão para acessar membros de segurança crítica. Quando o mesmo código é executado com confiança parcial (por exemplo, em um domínio de aplicativo em área restrita) nível determina se ele pode acessar o código crítico de segurança de confiança do assembly: se o assembly tiver um nome forte e instalado no cache de assembly global, ele é um assembly confiável e pode chamar membros crítico de segurança. Se não for confiável, ele se tornará transparente mesmo que ele não foi marcado como transparente e não pode acessar membros de segurança crítica.

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

Começando com o .NET Framework 4, o common language runtime determina o nível de transparência de um tipo ou membro de vários fatores, incluindo o nível de confiança do assembly e o nível de confiança do domínio do aplicativo. Reflexão fornece o IsSecurityCritical, IsSecuritySafeCritical, e IsSecurityTransparent Propriedades para que você possa descobrir o nível de transparência 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

Crítico de segurança

true

true

false

Transparente

false

false

true

Usando essas propriedades é muito mais simples que examinando as anotações de um assembly e seus tipos de segurança, verificando o nível de confiança atual e a tentativa de duplicar as regras do runtime. Por exemplo, o mesmo tipo pode ser crítico de segurança quando ele é executado a partir da linha de comando ou transparente de segurança quando ele é executado em um domínio de aplicativo na área restrita.

Não existem propriedades semelhantes a MethodBase, FieldInfo, TypeBuilder, MethodBuilder, e DynamicMethod classes. (Para outras reflexão e reflexão abstrações de emissão, atributos de segurança são aplicados para os métodos associados; por exemplo, no caso de propriedades que são aplicadas para os acessadores de propriedade).

Para usar a reflexão para invocar os membros que podem ser acessados de acordo com as regras de acessibilidade do common language runtime, o código deve receber uma das duas permissões:

  • Para permitir que o código invocar qualquer membro confidenciais: seu código deve ser concedido ReflectionPermission com o ReflectionPermissionFlag.MemberAccess sinalizador.

    System_CAPS_noteObservação

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

  • Para permitir que o código para invocar qualquer membro confidenciais, como o conjunto de concessões do assembly que contém o membro chamado é igual ou um subconjunto de, o conjunto de concessões do assembly que contém a invocação de código: seu código deve ser concedido ReflectionPermission com o ReflectionPermissionFlag.RestrictedMemberAccess sinalizador.

Por exemplo, suponha que você conceder a um domínio de aplicativo mais de permissões de Internet ReflectionPermission com o ReflectionPermissionFlag.RestrictedMemberAccess sinalizador e, em seguida, executar um aplicativo da Internet com dois assemblies, A e B.

  • Um assembly pode usar reflexão para acessar membros privados de assembly B, porque o conjunto de concessões do assembly B não inclui quaisquer permissões que um não foi concedido.

  • Um assembly não é possível usar a reflexão para acessar membros privados de .NET Framework assemblies como mscorlib. dll, como mscorlib. dll é totalmente confiável e, portanto, tem as permissões que não foi concedidas ao assembly A. A MemberAccessException é lançada quando a segurança de acesso ao código examina a pilha em tempo de execução.

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

Evite escrever membros públicos que utilizam MethodInfo parâmetros, especialmente para código confiável. Esses membros podem ser mais vulneráveis a códigos mal-intencionados. Por exemplo, considere um membro público no código altamente confiável que leva um MethodInfo parâmetro. Suponha que o membro público indiretamente chama o Invoke método no parâmetro fornecido. Se o membro público não executa as verificações de permissão necessária, a chamada para o Invoke método sempre terá êxito porque o sistema de segurança que determina se o chamador é altamente confiável. Mesmo que o código mal-intencionado não tem permissão para chamar diretamente o método, ele ainda pode fazer então indiretamente chamando o membro público.

  • Começando com o .NET Framework 4, o código transparent não pode usar reflexão para acessar membros de segurança crítica.

  • O ReflectionPermissionFlag.RestrictedMemberAccess sinalizador foi introduzido no .NET Framework 2.0 Service Pack 1. Versões anteriores do .NET Framework exigem o ReflectionPermissionFlag.MemberAccess Sinalizador para o código que usa a reflexão para acessar membros não públicos. Esta é uma permissão que nunca deve ser concedida ao código parcialmente confiável. 

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

Mostrar: