Considerações de segurança para reflexão
Reflexão fornece a capacidade de obter informações sobre tipos e membros e membros de acesso (ou seja, para chamar os métodos e construtores, para obter e definir a propriedade valores, 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 está restrito. Todo o código pode usar a reflexão para realizar as seguintes tarefas:
Enumerar tipos e membros e examinar seus metadados.
Enumerar e examinar os módulos e assemblies.
Por outro lado, usando a reflexão para membros de acesso, está sujeito às restrições. Começando com o .NET Framework versão 4, somente o código confiável pode usar a reflexão para acessar membros de segurança críticos. Além disso, somente o código confiável pode usar a reflexão para acessar membros confidenciais que não sejam acessíveis diretamente para o código compilado. Finalmente, código que usa a reflexão para acessar um membro safe crítico deve ter quaisquer permissões as demandas de membro safe crítica, assim como código compilado.
Sujeito a permissões necessárias, o código pode usar reflexão para realizar os seguintes tipos de acesso:
Acesso membros públicos que não são críticos de segurança.
Membros de confidenciais de acesso que estariam acessíveis para compilado código, se esses membros não são críticos para a segurança. Exemplos de tais membros confidenciais incluem:
Membros protegidos de classes de base do código de chamada. (Na reflexão, isso é chamado como acesso no nível da família.)
internalmembros (Friend membros em Visual Basic) o código de chamada assembly. (Na reflexão, isso é chamado como acesso de nível de assembly.)
Membros de particulares 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 no modo seguro é limitado ao acesso descrito nesta lista, a menos que o domínio do aplicativo concede permissões adicionais.
Começando com o .NET Framework versão 2.0 Service Pack 1, tentando acessar os membros que estão inacessíveis normalmente gera uma demanda para o conjunto de concessão de 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 satisfazer essas permissões. (Isso está sujeito às limitações no acesso a membros de segurança críticos, como descrito mais adiante neste artigo.)
Opcionalmente, pode conceder a um domínio de aplicativo no modo seguro ReflectionPermission com o ReflectionPermissionFlag.MemberAccess Sinalizar, conforme descrito na seção Acessar membros que são normalmente inacessível, posteriormente neste artigo.
Acesso a membros de segurança crítica
Um membro é de segurança crítico se ela tiver o SecurityCriticalAttribute, se ele pertence a um tipo que tem o SecurityCriticalAttribute, ou se ele estiver em um assembly de segurança crítica. Começando com o .NET Framework versão 4, as regras para acessar membros de segurança críticos são da seguinte maneira:
Código Transparent não pode usar a reflexão para acessar membros de segurança críticos, mesmo se o código é totalmente confiável. A MethodAccessException, FieldAccessException, or TypeAccessException is thrown.
Código que está sendo executado com confiança parcial é tratado como transparente.
Essas regras são os mesmos, se um membro de segurança crítico é acessado diretamente pelo código compilado ou acessado por meio de reflexão.
O código do aplicativo é executado a partir da linha de comando é executado com confiança total. Desde que ele não está marcado como transparente, ele pode usar a reflexão para acessar membros de segurança críticos. Quando o mesmo código é executado com confiança parcial (por exemplo, em um domínio de aplicativo no modo seguro) o nível de confiança do assembly determina se ele pode acessar o código de segurança crítico: Se o assembly tem um nome forte e é instalado no cache global de assemblies, é um assembly confiável e pode chamar membros essenciais de segurança. Se não for confiável, ele se torna transparente, mesmo que ele não foi marcado como transparente e não pode acessar membros de segurança críticos.
Para obter mais informações sobre o modelo de segurança no .NET Framework 4, consulte Alterações de segurança na.NET Framework 4.
Reflexão e transparência
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, inclusive o nível de confiança do assembly e o nível de confiança do domínio de aplicativo. Reflexão fornece a IsSecurityCritical, IsSecuritySafeCritical, e IsSecurityTransparent Propriedades para permitir que você 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ítica |
true |
false |
false |
Safe crítica |
true |
true |
false |
Transparente |
false |
false |
true |
Usando essas propriedades é muito mais simples que examinando as anotações de segurança de um assembly e seus tipos, 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íticas para a 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 no modo seguro.
Existem propriedades semelhantes sobre o MethodBase, FieldInfo, TypeBuilder, MethodBuilder, e DynamicMethod classes. (Para outros reflexão e reflexão, emitir abstrações, atributos de segurança são aplicados para os métodos associados; Por exemplo, no caso de propriedades são aplicadas a acessadores de propriedade.)
Acessando os membros que são normalmente inacessíveis
Usar a reflexão para invocar os membros que estão inacessíveis de acordo com a regras de acessibilidade do common language runtime, seu código deve receber uma das duas permissões:
Para permitir que o código para invocar qualquer membro confidenciais: Seu código deve ser concedido ReflectionPermission com o ReflectionPermissionFlag.MemberAccess sinalizador.
Observação
Por padrão, a diretiva de segurança nega esta permissão ao código que se origina da Internet.Esta permissão nunca deve ser concedido ao código que se origina da Internet.
Para permitir que o código para invocar qualquer membro confidenciais, como o conjunto de concessão do assembly que contém o membro invocado é igual ou um subconjunto do conjunto de concessão do assembly que contém o código de chamada: Seu código deve ser concedido ReflectionPermission com o ReflectionPermissionFlag.RestrictedMemberAccess sinalizador.
Por exemplo, suponha que você conceder permissões de Internet mais de um domínio de aplicativo ReflectionPermission com o ReflectionPermissionFlag.RestrictedMemberAccess Sinalizar, e então executa um aplicativo de Internet com dois assemblies, A e b.
Assembly a pode usar a reflexão para acessar membros de particulares de assembly B, porque o conjunto de concessão de assembly b não inclui quaisquer permissões que não tenha sido concedido a um.
Assembly a não é possível usar a reflexão para acessar membros de particulares de .NET Framework assemblies como mscorlib. dll, porque mscorlib. dll é totalmente confiável e, portanto, tem as permissões que não tenham sido concedidas ao assembly r. A MemberAccessException é lançada quando a segurança de acesso ao código percorre a pilha em tempo de execução.
Série
Para a 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 para descobrir e alterar o estado particular de uma instância. (Além dos que estão sendo concedidas as permissões apropriadas, o tipo deve ser marcado como serializável nos metadados.)
Parâmetros de tipo MethodInfo
Evite escrever membros públicos que o levam MethodInfo parâmetros, especialmente para código confiável. Esses membros talvez 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 realiza as verificações de permissão necessária, a chamada para o Invoke método sempre terá êxito porque o sistema de segurança determina se o chamador é altamente confiável. Mesmo se o código mal-intencionado não tem permissão para invocar diretamente o método, ele pode ainda fazer então indiretamente chamando o membro público.
Informações sobre versão
Começando com o .NET Framework versão 4, o código transparent não pode usar a reflexão para acessar membros de segurança crítica.
O ReflectionPermissionFlag.RestrictedMemberAccess sinalizador é apresentado na .NET Framework versão 2.0 Service Pack 1. Versões anteriores da .NET Framework exigem o ReflectionPermissionFlag.MemberAccess sinalizador de código que usa a reflexão para acessar membros confidenciais. 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 membros e tipos confidenciais não requer permissões. Em versões anteriores, ReflectionPermission com o ReflectionPermissionFlag.TypeInformation sinalizador é necessária.
Consulte também
Referência
Conceitos
Alterações de segurança na.NET Framework 4