Usando a Segurança do Acesso ao Código com o ASP.NET

Nesta página

	Neste módulo
	Objetivos
	Aplicação
	Como usar este módulo
	Visão geral
	Acesso a recursos
	Confiança total e confiança parcial
	Configurando a segurança de acesso ao código no ASP.NET
	Arquivos de diretivas do ASP.NET
	Diretiva do ASP.NET
	Desenvolvendo aplicativos da Web parcialmente confiáveis
	Níveis de confiança
	Abordagens de aplicativos da Web parcialmente confiáveis
	Personalizar a diretiva
	Código privilegiado no modo de segurança
	Decidindo a abordagem que será adotada
	Confiança Média
	Restrições do modo de confiança média
	Resumo
	Outros recursos

Neste módulo

A segurança de acesso ao código é um modelo de restrição de recursos que permite aos administradores determinar se e como um certo código é capaz de acessar recursos especificados e realizar outras operações privilegiadas. Este módulo concentra–se na configuração da diretiva de segurança de acesso ao código do ASP.NET e mostra como superar alguns dos principais obstáculos que podem ser encontrados no desenvolvimento de aplicativos da Web parcialmente confiáveis.

Os elementos práticos da segurança de acesso ao código serão explicados detalhadamente, e você aprenderá como desenvolver aplicativos da Web de média confiabilidade que se beneficiam da proteção de segurança proporcionada pela segurança de acesso ao código, mas que ainda são capazes de usar componentes que exigem confiabilidade total.

O módulo também apresenta informações sobre como criar diretivas confiáveis do ASP.NET e contém duas listas valiosíssimas:

Início da página

Objetivos

Use este módulo para:

Início da página

Aplicação

Este módulo aplica–se aos produtos e tecnologias a seguir:

Início da página

Como usar este módulo

Este módulo não trata dos fundamentos da segurança de acesso ao código. Pressupõe–se um certo conhecimento prévio, embora os conceitos principais sejam reiterados quando for necessário. Para obter mais informações sobre a segurança de acesso ao código do .NET Framework, consulte, "Segurança do Acesso ao Código na Prática".

Use este módulo para aprender como usar a segurança de acesso ao código para bloquear os seus aplicativos da Web e tornar o seu servidor mais resistente a ataques potenciais.

Se você gerencia ambientes de hospedagem compartilhados ou trabalha em um ISP (Provedor de Serviços de Internet) que executa vários aplicativos de diferentes empresas no mesmo servidor da Web, pode usar a segurança de acesso ao código para:

Observe também que o Windows Server 2003 e o IIS 6.0 (Internet Information Services) proporcionam ainda mais isolamento de processos para aplicativos da Web. O isolamento de processos aliado à segurança de acesso ao código é o modelo recomendado para o isolamento de aplicativos.

Para obter mais informações, consulte, "Hospedando Vários Aplicativos da Web".

Início da página

Visão geral

A segurança tradicional baseada em objetos de segurança, como a que é oferecida pelo sistema operacional, autoriza o acesso aos recursos com base na identidade do usuário.

Com o Microsoft .NET Framework versão 1.1, os administradores podem configurar diretivas para aplicativos da Web e Web Services ASP.NET, que podem consistir em vários conjuntos. Elas também podem conceder permissões de segurança de acesso ao código para permitir que o aplicativo tenha acesso a tipos específicos de recursos e possa realizar operações privilegiadas específicas.

Por exemplo:

Essas áreas estão onde a segurança de acesso ao código é importante, pois ela pode estabelecer outras restrições além da segurança com base no próprio código, e não no usuário que está executando o código.

Obervação Os aplicativos da Web e os Web Services criados com o .NET Framework versão 1.0 sempre funcionam com permissões totais de acesso ao código. Isso não pode ser configurado.

Início da página

Acesso a recursos

Todo o acesso aos recursos a partir dos aplicativos ASP.NET e de códigos gerenciados em geral está sujeito às duas camadas de segurança seguintes:

Ambas as verificações devem ser bem–sucedidas para que o recurso seja acessado com êxito. Todos os tipos de recurso expostos pelas classes do .NET Framework são protegidos por permissões de acesso ao código. A Figura 9.1 mostra uma série de tipos comuns de recursos que são acessados por aplicativos da Web, além da permissão de acesso ao código associada necessária para a tentativa de acesso ser bem–sucedida.

Figura 9.1
Tipos comuns de recurso acessados por aplicativos da Web ASP.NET e tipos associados de permissões

Início da página

Confiança total e confiança parcial

Por padrão, os aplicativos da Web funcionam com confiança total. Os aplicativos de confiança total recebem permissões irrestritas de acesso ao código da diretiva de segurança de acesso ao código. Essas permissões são as permissões internas de sistema e as permissões personalizadas. Isso significa que a segurança de acesso ao código não impedirá que o seu aplicativo acesse qualquer um dos tipos protegidos de recursos mostrados na Figura 9.1. O sucesso ou o fracasso da tentativa de acesso ao recurso é determinado simplesmente pela segurança no nível de sistema operacional. Os aplicativos da Web que funcionam com confiança total são todos os aplicativos ASP.NET criados por meio do .NET Framework versão 1.0. Por padrão, os aplicativos criados com o .NET Framework versão 1.1 funcionam com confiança total, mas o nível de confiança pode ser configurado com o elemento <trust>, descrito mais adiante neste módulo.

Se um aplicativo for configurado com um nível de confiança que não seja "Total", ele será denominado aplicativo parcialmente confiável. Os aplicativos parcialmente confiáveis têm permissões restritas, o que limita a sua capacidade de acessar recursos protegidos.

Importante: aplicativos da Web criados com o .NET Framework versão 1.0 sempre funcionam com confiança total, pois os tipos do System.Web exigem chamadores com confiança total.

Início da página

Configurando a segurança de acesso ao código no ASP.NET

Por padrão, os aplicativos da Web que funcionam com confiança total não têm qualquer restrição de permissões. Para modificar os níveis de confiança da segurança de acesso ao código no ASP.NET, você precisa estabelecer um parâmetro no Machine.config ou no Web.config e configurar o aplicativo como um aplicativo parcialmente confiável.

Configurando os níveis de confiança

O elemento <trust> em Machine.config controla se a segurança de acesso ao código será ativada ou não para um aplicativo da Web. Abra Machine.config, procure "<trust>", e você verá o seguinte.

  <system.web> 
     <!-- level="[Full|High|Medium|Low|Minimal]" --> 
     <trust level="Full" originUrl=""/> 
  </system.web> 

Com o nível de confiança definido como "Full", a segurança de acesso ao código é efetivamente desativada porque nenhuma exigência de permissões fica no caminho das tentativas de acesso aos recursos. Esta é a única opção para os aplicativos da Web ASP.NET criados com o .NET Framework versão 1.0. Descendo na lista de "Full" até "Minimal", cada nível retira mais permissões, restringindo ainda mais a capacidade do seu aplicativo de acessar recursos protegidos e realizar operações privilegiadas. Conforme o nível, maior será o isolamento do aplicativo. A Tabela 9.1 mostra os níveis de confiança predefinidos e indica as principais restrições em relação ao nível anterior.

Tabela 9.1 Restrições impostas pelos níveis de confiança do ASP.NET

Bloqueando o nível de confiança

Se o administrador do servidor de Web quiser usar a segurança de acesso ao código para garantir o isolamento do aplicativo e restringir o acesso aos recursos do sistema, ele pode definir a diretiva de segurança da máquina e impedir que aplicativos individuais a substituam.

Provedores de serviços de aplicativo ou qualquer outro responsável pela execução de vários aplicativos da Web no mesmo servidor devem bloquear o nível de confiança de todos os aplicativos da Web. Para isso, delimite o elemento <trust> em Machine.config com uma marca <location> e defina o atributo allowOverride como false, como mostra o exemplo a seguir.

<location allowOverride="false"> 
  <system.web> 
    <!-- level="[Full|High|Medium|Low|Minimal]" --> 
    <trust level="Medium" originUrl=""/> 
 </system.web> 
</location> 

Você também pode usar um atributo path no elemento <location> para aplicar uma configuração a um site ou aplicativo da Web específico que não possa ser substituído. Para obter mais informações sobre o elemento <location>, consulte, "Protegendo seus Aplicativos ASP.NET e Web Services".

Início da página

Arquivos de diretivas do ASP.NET

Cada nível de confiança é ligado a um arquivo de diretiva XML individual, o qual lista o conjunto de permissões concedidos por cada nível de confiança. Os arquivos de diretivas encontram–se no seguinte diretório:

%windir%\Microsoft.NET\Framework\{versão}\CONFIG 

Os níveis de confiança são direcionados aos arquivos de diretivas pelos elementos <trustLevel> em Machine.config, que se encontram logo acima do elemento <trust>, como mostra o exemplo a seguir.

<location allowOverride="true"> 
  <system.web> 
    <securityPolicy> 
      <trustLevel name="Full" policyFile="internal"/> 
      <trustLevel name="High" policyFile="web_hightrust.config"/> 
      <trustLevel name="Medium" policyFile="web_mediumtrust.config"/> 
      <trustLevel name="Low" policyFile="web_lowtrust.config"/> 
      <trustLevel name="Minimal" policyFile="web_minimaltrust.config"/> 
    </securityPolicy> 
    <!-- level="[Full|High|Medium|Low|Minimal]" --> 
    <trust level="Full" originUrl=""/> 
  </system.web> 
</location> 

Observação: não há nenhum arquivo de diretivas para o nível de confiança total. Esse é um caso especial que simplesmente indica o conjunto irrestrito de todas as permissões.

A diretiva do ASP.NET é totalmente configurável. Além dos níveis padrão de diretivas, os administradores podem criar arquivos personalizados de permissões e configurá–los por meio do elemento <trust>, que será descrito mais adiante neste módulo. O arquivo de diretivas associado ao nível personalizado também precisa ser definido por um elemento <trustLevel> no Machine.config.

Início da página

Diretiva do ASP.NET

A diretiva de segurança de acesso ao código é hierárquica, sendo administrada em vários níveis. A diretiva pode ser criada para os níveis de domínio de empresa, máquina, usuário e aplicativo. A diretiva de segurança de acesso ao código do ASP.NET é um exemplo da diretiva de domínio de aplicativo.

Os parâmetros de um arquivo de configuração XML separado definem a diretiva para cada nível. As diretivas de empresa, máquina e usuário podem ser configuradas por meio da ferramenta de configuração do Microsoft .NET Framework, mas os arquivos de diretivas do ASP.NET devem ser editados manualmente por meio de um editor XML ou de texto.

Cada arquivo de diretiva de nível de confiança do ASP.NET diz quais permissões podem ser concedidas aos aplicativos configurados em um determinado nível de confiança. As permissões reais concedidas a um aplicativo ASP.NET são determinadas pela intersecção das permissões concedidas em todos os níveis de diretivas, inclusive empresa, máquina, usuário e na diretiva do (domínio do aplicativo) ASP.NET.

Como a diretiva é avaliada desde o nível superior (empresa) até o nível inferior (aplicativo ASP.NET), não é possível conceder permissões, apenas negá–las. Você não pode incluir uma permissão no ASP.NET sem que antes um nível superior conceda a permissão. Essa abordagem garante que o administrador corporativo sempre tenha a palavra final e que códigos mal–intencionados executados em um domínio de aplicativo não consigam solicitar e receber mais permissões que os configurados pelo administrador.

Para obter mais informações sobre a avaliação de diretivas, consulte o, "Segurança do Acesso ao Código na Prática."

Um arquivo de diretivas do ASP.NET por dentro

Para ver quais permissões são definidas por um determinado nível de confiança, abra o arquivo de diretivas em questão no Bloco de Notas ou (de preferência) em um editor de XML e localize o "ASP.NET" denominado conjunto de permissões. Esse conjunto de permissões lista as permissões configuradas para o aplicativo no nível de confiança atual.

Observação: você também verá os conjuntos de permissão "FullTrust" e "Nothing". Esses conjuntos não contêm nenhum elemento de permissão porque "FullTrust" implica todas as permissões e "Nothing" não contém nenhuma permissão.

O fragmento a seguir mostra os principais elementos de um arquivo de diretivas ASP.NET:

<configuration> 
    <mscorlib> 
        <security> 
            <policy> 
                <PolicyLevel version="1"> 
                    <SecurityClasses> 
                      ... list of security classes, permission types,  
                        and code group types ... 
                    </SecurityClasses> 
                    <NamedPermissionSets> 
                      <PermissionSet Name="FullTrust" ... /> 
                      <PermissionSet Name="Nothing" .../> 
                      <PermissionSet Name="ASP.NET" ... 
                        ... This is the interesting part ... 
                        ... List of individual permissions... 
                            <IPermission  
                                    class="AspNetHostingPermission" 
                                    version="1" 
                                    Level="High" /> 
                            <IPermission 
                                    class="DnsPermission" 
                                    version="1" 
                                    Unrestricted="true" /> 
                          ...Continued list of permissions... 
                      </PermissionSet> 
                </PolicyLevel version="1"> 
            </policy> 
        </security> 
    </mscorlib> 
</configuration> 

Observe que cada permissão é definida por um elemento <IPermission>, que define o nome do tipo de permissão, a versão e se ela está ou não no estado irrestrito.

Estado de permissão e permissões irrestritas

Muitas permissões possuem um estado, usado para o ajuste fino dos direitos de acesso especificados pela permissão. O estado determina exatamente o que a permissão permite que o seu aplicativo faça. Por exemplo, FileIOPermission pode especificar um diretório e um tipo de acesso (leitura, gravação, e assim por diante). A permissão a seguir exige que o código de chamada receba a permissão de leitura para acessar o diretório C:\SomeDir:

(new FileIOPermission(FileIOPermissionAccess.Read, @"C:\SomeDir")).Demand(); 

No seu estado irrestrito, FileIOPermission permite qualquer tipo de acesso a qualquer área do sistema de arquivos (naturalmente, a segurança do sistema operacional ainda é válida). A permissão a seguir exige que o código de chamada receba a FileIOPermission irrestrita:

(new FileIOPermission(PermissionState.Unrestricted)).Demand(); 

Conjunto de permissões nomeado ASP.NET

Os arquivos de diretivas ASP.NET contêm um conjunto de permissões nomeado "ASP.NET". Esse conjunto define o conjunto de permissões concedido pela diretiva do domínio do aplicativo aos aplicativos associados.

A diretiva ASP.NET também introduz uma AspNetHostingPermission personalizada, que possui um atributo Level associado correspondente a um dos níveis padrão. Todos os tipos públicos em System.Web e em System.Web.Mobile são protegidos por exigências do nível Mínimo desta permissão. Essa estratégia de redução de riscos foi criada para garantir que o código do aplicativo da Web não possa ser usado em outros ambientes parcialmente confiáveis sem uma configuração específica de diretiva feita pelo administrador.

Parâmetros de substituição

Se você editar um dos arquivos de diretivas ASP.NET, perceberá que alguns dos elementos de permissão contêm parâmetros de substituição ($AppDirUrl$, $CodeGen$ e $Gac$). Esses parâmetros permitem que você configure as permissões a conjuntos que fazem parte do seu aplicativo da Web, mas que são carregados de lugares diferentes. Cada parâmetro de substituição é substituído por um valor real no momento da avaliação da diretiva de segurança. Isso ocorre quando o seu conjunto de aplicativos da Web é carregado pela primeira vez. O seu aplicativo da Web pode consistir nos três tipos de conjunto a seguir:

Cada um desses tipos de conjuntos possui um parâmetro de substituição associado, conforme resume a Tabela 9.2.

Tabela 9.2 Parâmetros de substituição da diretiva de segurança de acesso ao código ASP.NET

Início da página

Desenvolvendo aplicativos da Web parcialmente confiáveis

Os aplicativos da Web parcialmente confiáveis são aplicativos que não têm confiança total e contam com um conjunto restrito de permissões de acesso ao código, determinado pela diretiva de segurança de acesso ao código. O resultado disso é que os aplicativos parcialmente confiáveis são limitados na sua capacidade de acessar recursos protegidos e executar outras operações privilegiadas. Certas permissões são negadas aos aplicativos parcialmente confiáveis, portanto os recursos que exigem essas permissões não poderão ser acessados diretamente. Outras permissões são concedidas com restrições, de forma que os recursos que exigem essas permissões podem estar acessíveis, mas com limitações. Por exemplo, uma FileIOPermission restrita pode especificar que o aplicativo pode ter acesso ao sistema de arquivos, mas somente aos diretórios abaixo da raiz do diretório virtual do aplicativo.

Por que a confiança parcial?

Configurando um aplicativo ou um Web Service como parcialmente confiável, você pode restringir capacidade do aplicativo de acessar recursos essenciais do sistema ou recursos pertencentes a outros aplicativos da Web. Concedendo apenas as permissões de que o aplicativo precisa e nada mais, você pode criar aplicativos da Web menos privilegiados e limitar o potencial de danos caso o aplicativo da Web seja comprometido por um ataque de injeção de código.

Problemas que podem ser encontrados

Se você tomar um aplicativo da Web existente e reconfigurá–lo para funcionar com um nível de confiança parcial, poderá encontrar os seguintes problemas a menos que o aplicativo seja extremamente limitado nos recursos a que pode ter acesso:

Início da página

Níveis de confiança

Se você planeja transferir um aplicativo existente para um nível de confiança parcial, uma boa solução é reduzir as permissões de forma incremental para que você possa ver quais partes do seu aplicativo falham. Por exemplo, comece definindo o atributo de confiança level como Alto, em seguida como Médio, e assim por diante. Finalmente, o nível de confiança a que você deve visar depende do nível de restrição que você deseja estabelecer para o aplicativo. Use as seguintes orientações:

A Tabela 9.3 identifica as permissões concedidas por cada um dos níveis de confiança ASP.NET O nível full (total) foi omitido da tabela, pois ele garante todas as permissões em seus estados irrestritos

Tabela 9.3 Permissões de diretiva e níveis de confiança padrão do ASP.NET

Início da página

Abordagens de aplicativos da Web parcialmente confiáveis

Se você desenvolver um aplicativo parcialmente confiável ou permitir que um aplicativo existente seja executado em um nível de confiança parcial e encontrar problemas pelo fato de o seu aplicativo tentar acessar recursos para os quais não tenham sido concedidas as respectivas permissões, você pode adotar duas abordagens básicas:

A abordagem certa depende do problema. Se o problema estiver relacionado ao fato de você estar tentando chamar um conjunto de sistema que não contém o AllowPartiallyTrustedCallersAttribute o problema passa a ser como conceder confiança total a um código. Nesta situação, você deve usar a abordagem da colocação no modo seguro e conceder confiança total ao conjunto wrapper colocado no modo seguro.

Observação: a personalização de diretivas é a mais fácil das duas abordagens porque não exige nenhum esforço de desenvolvimento.

Início da página

Personalizar a diretiva

Se o seu aplicativo da Web contém código que exige permissões além das concedidas por um determinado nível de confiança do ASP.NET, a opção mais fácil é personalizar um arquivo de diretivas para conceder a permissão adicional de segurança de acesso ao código ao seu aplicativo da Web. Você pode modificar um arquivo de diretivas existente e conceder mais permissões ou criar um novo arquivo com base em um arquivo de diretivas existente.

Observação: se você modificar um dos arquivos de diretivas internos, por exemplo, o arquivo de diretivas Web_mediumtrust.config de confiança média, isso afetará todos os aplicativos configurados para funcionar com um nível médio de confiança.

%windir%\Microsoft.NET\Framework\{versão}\CONFIG\web_yourtrust.config 

<securityPolicy> 
  <trustLevel name="Custom" policyFile="web_yourtrust.config"/> 
  . . . 
</securityPolicy> 

<system.web> 
  <trust level="Custom" originUrl=""/> 
</system.web>

Início da página

Código privilegiado no modo de segurança

Outra abordagem que não exige a atualização para a diretiva de segurança de acesso ao código do ASP.NET é empacotar o seu código de acesso ao recurso no seu próprio conjunto wrapper e configurar a diretiva de segurança de acesso ao código do computador para conceder ao conjunto específico a permissão adequada. Então, você pode colocar no modo seguro o código mais privilegiado, usando o método CodeAccessPermission.Assert para que você não precise mudar a concessão geral de permissão do aplicativo da Web. O método Assert impede que a solicitação de segurança emitida pelo código de acesso ao recurso se propague na pilha de chamadas além dos limites do conjunto wrapper.

Um padrão de colocação no modo seguro

Você pode aplicar o seguinte padrão a qualquer código privilegiado que precise acessar um recurso restrito ou realizar outra operação privilegiada para a qual o aplicativo da Web pai não tenha permissões suficientes:

<CodeGroup 
   class="UnionCodeGroup" 
   version="1" 
   PermissionSetName="FullTrust> 
   <IMembershipCondition 
       class="UrlMembershipCondition" 
       Url="$Gac$/*" 
       version="1" 
   /> 
</CodeGroup> 

A Figura 9.2 mostra a abordagem de colocação no modo seguro.

Figura 9.2
Colocação de um código privilegiado no modo seguro no seu próprio conjunto, o que declara a respectiva permissão

É uma prática recomendável usar conjuntos separados para encapsular o acesso aos recursos, além de evitar a colocação do código de acesso ao recurso em arquivos .aspx ou códigos por trás de arquivos. Por exemplo, crie um conjunto separado de acesso a dados para encapsular o acesso a bancos de dados. Isso facilita a transferência de aplicativos para ambientes parcialmente confiáveis.

Início da página

Decidindo a abordagem que será adotada

A abordagem certa depende do problema que você está tentando resolver, dependendo também do fato de você ter ou não a opção de modificar a diretiva de segurança no servidor de Web.

Personalizando diretivas

Esta abordagem é a mais fácil das duas e não exige nenhum esforço de desenvolvimento. Entretanto, você pode não ter a permissão para modificar diretivas no servidor de Web e, em determinadas situações, o seu código que chama a biblioteca de classes do .NET Framework pode exigir confiança total. nesses casos, você deve usar o modo seguro. Nessas situações deve ser usado o modo seguro. Por exemplo, os recursos a seguir exigem confiança total, e você deve colocar o seu código de acesso ao recurso no modo seguro ao acessá–los:

Observação: esta lista não pretende esgotar as possibilidades, mas apresenta os tipos de recursos usados mais freqüentemente e que em condições normais exigem confiança total.

Modo seguro

Se você colocar no modo seguro o código do seu aplicativo privilegiado em um conjunto separado, poderá conceder mais permissões ao conjunto. Como alternativa, você pode conceder a ele confiança total sem exigir que todo o seu aplicativo funcione com permissões estendidas.

Por exemplo,considere o código que usa o provedor de dados ADO.NET OLE DB e interage com a classe System.Data.OleDb.OleDbCommand Esse código requer confiança total. Embora o conjunto System.Data.dll esteja marcado com AllowPartiallyTrustedCallersAttribute, a classe System.Data.OleDb.OleDbCommand entre outras, não pode ser chamada por chamadores parcialmente confiáveis porque está protegida por uma solicitação associada de confiança total. Para ver isso, execute o comando a seguir por meio do utilitário permview no diretório %windir%\Microsoft.NET\Framework\{versão}:

permview /DECL /OUTPUT System.Data.Perms.txt System.Data.dll 

A saída no System.Data.Perms.txt conterá o seguinte:

Conjunto de permissões class System.Data.OleDb.OleDbCommand LinktimeDemand: 
<PermissionSet class="System.Security.PermissionSet" 
               version="1" Unrestricted="true"/> 

Isso ilustra um conjunto de permissão irrestrita (confiança total) que é usado em uma demanda de link protetor da classe System.Data.OleDb.OleDbCommand. Em cenários como esses, configurar a diretiva não é suficiente para garantir permissões irrestritas específicas, tais como OleDbPermission a seu código parcialmente confiável. Em vez disso, você deve colocar o seu código de acesso ao recurso no modo seguro e conceder ele confiança total, e a forma mais fácil de fazer isso é instalá–lo no GAC. Use o Permview.exe para descobrir sobre as permissões necessárias de outras classes, embora esse procedimento exiba apenas atributos de segurança declarativos. Se uma classe exigir obrigatoriamente confiança total, você não poderá vê–la por meio do Permview.exe. Nesse caso, teste os requisitos de segurança da classe, chamando–a pelo código parcialmente confiável e diagnosticando todas as exceções de segurança.

Observação: só porque um conjunto está marcado com APTCA, isso não significa que todas as classes contidas admitem chamadores parcialmente confiáveis. Algumas classes podem conter solicitações explícitas de confiança total.

Início da página

Confiança Média

Se você hospeda aplicativos da Web, pode optar por implementar uma diretiva de segurança de confiança média para restringir operações privilegiadas. Esta seção concentra–se na execução de aplicativos de confiança média, e mostra como superar os problemas que provavelmente aparecerão.

As duas principais vantagens de executar um aplicativo no modo de confiança média são as seguintes:

Menor área exposta a ataques

Uma vez que confiança média não concede ao aplicativo acesso irrestrito a todas as permissões, a sua área exposta a ataques é reduzida por meio da concessão de um subconjunto do conjunto completo de permissões ao aplicativo. Muitas das permissões concedidas pela diretiva de confiança média também estão em um estado restrito. Se um atacante conseguir, de alguma forma, assumir o controle do seu aplicativo, seu espaço de atuação será limitado.

Isolamento do aplicativo

O isolamento do aplicativo por meio da segurança de acesso ao código restringe o acesso a recursos do sistema e a recursos de propriedade de outros aplicativos. Por exemplo, embora a identidade do processo tenha permissão de ler e gravar arquivos fora do diretório do aplicativo da Web, a FileIOPermission nos aplicativos de confiança média é restrita. Ela permite apenas que o aplicativo leia ou grave na sua própria hierarquia de diretório.

Início da página

Restrições do modo de confiança média

Se o seu aplicativo for executado em confiança média, ele enfrentará uma série de restrições, sendo as mais significativas:

Esta seção mostra como acessar os seguintes tipos de recursos a partir de um aplicativo da Web ou Web Service de confiança média:

OLE DB

Os aplicativos da Web de confiança média não recebem a OleDbPermission. Além disso, o provedor de dados .NET OLE DB exige, atualmente, chamadores de confiança total. Se você tiver um aplicativo que precise acessar fontes de dados OLE DB no modo de confiança média, use a abordagem da colocação no modo seguro. Coloque o seu código de acesso a dados em um conjunto separado, atribua a ele um nome de alta segurança e instale–o no GAC, o que concederá a ele confiança total.

Observação: a modificação da diretiva não funcionará a menos que você defina o nível de confiança como "Full", pois o provedor gerenciado OLE DB exige confiança total.

A Figura 9.3 mostra a disposição.

Figura 9.3
Acesso ao recurso OLE DB no modo seguro

Modo seguro

Nesta abordagem, você cria um conjunto wrapper para encapsular o acesso à fonte de dados do banco de dados OLE. Esse conjunto recebe permissões de confiança total, necessárias para usar o provedor gerenciado OLE DB ADO.NET.

[assembly: AssemblyVersion("1.0.0.0")] 
[assembly: AssemblyKeyFile(@"..\..\oledbwrapper.snk")] 
[assembly:AllowPartiallyTrustedCallersAttribute()] 

[assembly: PermissionSet(SecurityAction.RequestMinimum, Unrestricted=true)] 

public OleDbDataReader GetProductList() 
{ 
  try 
  { 
    // Assert full trust (the unrestricted permission set) 
    new PermissionSet(PermissionState.Unrestricted).Assert(); 
    OleDbConnection conn = new OleDbConnection( 
       "Provider=SQLOLEDB; Data Source=(local);" + 
       "Integrated Security=SSPI; Initial Catalog=Northwind"); 
    OleDbCommand cmd = new OleDbCommand("spRetrieveProducts", conn); 
    cmd.CommandType = CommandType.StoredProcedure; 
    conn.Open(); 
    OleDbDataReader reader = 
          cmd.ExecuteReader(CommandBehavior.CloseConnection); 
    return reader; 
  } 
  catch(OleDbException dbex) 
  { 
    // Log and handle exception 
  } 
  catch(Exception ex) 
  { 
    //  Log and handle exception 
  } 
  finally 
  { 
    CodeAccessPermission.RevertAssert(); 
  } 
  return null; 
}

gacutil -i oledbwrapper.dll 

"C:\Arquivos de programas\Microsoft Visual Studio .NET 2003\SDK\v1.1\Bin\gacutil.exe" 
/i $(TargetPath) 

<trust level="Medium" originUrl=""/> 

sn -Tp oledbwrapper.dll 

<compilation debug="false" > 
  <assemblies> 
    <add assembly="oledbwrapper, Version=1.0.0.0, Culture=neutral, 
         PublicKeyToken=4b...06"/> 
  </assemblies> 
</compilation> 

Log de eventos

A classe EventLogPermission é projetada para encapsular os direitos do código de acessar o log de eventos. Atualmente, entretanto, o código deve receber confiança total para poder acessar o log de eventos. Isso significa que um aplicativo da Web de confiança média não poderá acessar diretamente o log de eventos. Para isso, você deve colocar no modo seguro o seu código de registro de eventos.

Acessando o log de eventos

Primeiramente, verifique se a conta do processo usada para executar o seu aplicativo da Web (ou a identidade do segmento, se o seu aplicativo for representante) é capaz de criar fontes de eventos. Para isso, o processo ou a identidade do segmento deve ser capaz de criar chaves de registro abaixo da seguinte chave:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Eventlog 

No mínimo, a identidade do processo ASP.NET de qualquer identidade representada deve ter as seguintes permissões nesta chave de registro:

Esses parâmetros devem ser aplicados à chave acima e às subchaves. Como alternativa, você pode criar fontes de eventos no momento da instalação quando estiverem disponíveis direitos administrativos. Para obter mais informações sobre esta abordagem, consulte "Auditoria e registro", "Criando Páginas e Controles ASP.NET Seguros".

Modo seguro

Para colocar no modo seguro o seu código de registro de eventos, crie um conjunto wrapper para encapsular o acesso ao log de eventos. Em seguida, instale o conjunto wrapper no GAC (Cache de Conjunto Global) para que a diretiva segurança de acesso ao código conceda a ele confiança total.

[assembly: AssemblyVersion("1.0.0.0")] 
[assembly: AssemblyKeyFile(@"..\..\eventlogwrapper.snk")] 
[assembly:AllowPartiallyTrustedCallersAttribute()] 

[assembly:EventLogPermissionAttribute(SecurityAction.RequestMinimum, 
MachineName="<machine name>", 
PermissionAccess=EventLogPermissionAccess.Instrument)] 

[assembly: PermissionSet(SecurityAction.RequestMinimum, Unrestricted=true)] 

try 
{ 
  string source = "Event Source"; 
  string log = "Application"; 
  string eventText = "Writing to the event log"; 
  EventLogEntryType eventType = EventLogEntryType.Information; 
  //Assert permission 
  EventLogPermission eventPerm; 
  eventPerm = new EventLogPermission (EventLogPermissionAccess.Instrument, 
"<machinename>"); 
  eventPerm.Assert(); 
  //Check to see if the source exists. 
  if(!EventLog.SourceExists(source)) 
  {//The keys do not exist, so register your application as a source 
     EventLog.CreateEventSource(source, log); 
  } 
  //Write to the log. 
  EventLog.WriteEntry(source, eventText, eventType); 
  } 
  catch(Exception ex) 
  {/*Handle exception*/} 
  finally 
  { 
    CodeAccessPermission.RevertAssert(); 
  } 

gacutil -i eventlogwrapper.dll 

"C:\Arquivos de programas\Microsoft Visual Studio .NET 2003\SDK\v1.1\Bin\gacutil.exe" 
/i $(TargetPath) 

<trust level="Medium" originUrl=""/> 

sn -Tp eventlogwapper.dll 

<compilation debug="false" > 
  <assemblies> 
    <add assembly="eventlogwrapper, Version=1.0.0.0, Culture=neutral, 
         PublicKeyToken=4b...06"/> 
  </assemblies> 
</compilation> 

Web Services

Por padrão, a diretiva de confiança média concede aos aplicativos da Web ASP.NET uma WebPermission restrita. Para poder chamar Web Services a partir do seu aplicativo da Web, você deve configurar o atributo originUrl no elemento <trust> do seu aplicativo.

<trust level="Medium" originUrl="http://servername/.*"/> 

O valor de originUrl é usado no construtor para uma classe de expressão regular System.Text.RegEx de forma que ele possa realizar uma correspondência com as URLs que podem ser acessadas pelo Web Service. Esta classe RegEx é usada junto com a classe WebPermission. O ".*" corresponde a qualquer URL que comece por "http://servername/".

O atributo originUrl é usado quando a diretiva ASP.NET é avaliada. Ela atribui um valor ao parâmetro de substituição $OriginHost$. Aqui está a definição de WebPermission a partir do Web_mediumtrust.config:

<IPermission 
   class="WebPermission" 
   version="1"> 
   <ConnectAccess> 
     <URI uri="$OriginHost$"/> 
   </ConnectAccess> 
</Ipermission> 

Se você não especificar os servidores de Web acessados pelo seu aplicativo, qualquer solicitação de Web Services falhará com uma SecurityException. Para chamar um Web Service no servidor de Web local, use a seguinte configuração:

<trust level="Medium" originUrl="http://localhost/.*" /> 

Se o seu aplicativo precisar acessar vários Web Services em diferentes servidores, você precisará personalizar a diretiva ASP.NET porque é possível especificar apenas um originUrl no elemento <trust> de Web.config ou Machine.config.

%windir%\Microsoft.NET\Framework\{versão}\CONFIG 

<IPermission class="WebPermission" version="1"> 
  <ConnectAccess> 
    <URI uri="$OriginHost$"/> 
    <URI uri="http://server1/.*"/> 
    <URI uri="http://server2/.*"/> 
    <URI uri="http://server3/.*"/> 
  </ConnectAccess> 
</Ipermission> 

<IPermission class="WebPermission" version="1"> 
  <ConnectAccess> 
    <URI uri="$OriginHost$"/> 
    <URI uri="http://servername.yourDomain.com/.*"/> 
    <URI uri="http:// servername/.*"/> 
    <URI uri="http://127.0.0.1/.*"/> 
  </ConnectAccess> 
</Ipermission> 

<system.web> 
  <securityPolicy> 
    <trustLevel name="MediumPlusWebPermission" 
                policyFile="web_mediumtrust_WebService.config"/> 
  </securityPolicy> 
  <trust level=" MediumPlusWebPermission" originUrl=""/> 
</system.web>

Utilizando credenciais padrão

Talvez você precise chamar um Web Service que utiliza a autenticação do Windows e especifique credenciais de autenticação por meio da cache de credenciais de proxy. Por exemplo:

proxy.Credentials = System.Net.CredentialCache.DefaultCredentials; 

Neste caso, o aplicativo ASP.NET exige o EnvironmentPermission com acesso de leitura à variável de ambiente USERNAME. A diretiva–padrão de confiança média concede essa permissão aos aplicativos da Web.

Em uma situação de ASP.NET no lado do servidor, as credenciais são obtidas no segmento do aplicativo ASP.NET ou no identificador do processo. Se DefaultCredentials for usado a partir de um aplicativo de desktop, será usado o identificador interativo atual do usuário. A solicitação da EnvironmentPermission é uma estratégia de redução de riscos criada para garantir que o código não possa usar as credenciais do usuário local à vontade e expô–las à rede.

Registro

Por padrão, aplicativos da Web de confiança média não recebem a RegistryPermission. Para configurar o seu aplicativo para acessar o registro, você deve modificar a diretiva ASP.NET para conceder essa permissão ao seu aplicativo ou desenvolver um conjunto wrapper no modo seguro que tenha a permissão necessária.

A abordagem de colocação no modo seguro é a mesma descrita anteriormente para as fontes de dados do banco de dados OLE e para o log de eventos.

Personalizando diretivas

A maneira mais fácil de personalizar uma diretiva é criar um arquivo de diretiva personalizada com base no arquivo de diretivas de confiança média e configurar o seu aplicativo para o uso da diretiva personalizada. A diretiva personalizada concede a RegistryPermission ao aplicativo.

%windir%\Microsoft.NET\Framework\{versão}\CONFIG 

<SecurityClass Name="RegistryPermission" 
               Description="System.Security.Permissions.RegistryPermission, 
               mscorlib, Version=1.0.5000.0, Culture=neutral, 
               PublicKeyToken=b77a5c561934e089"/> 

<IPermission class="RegistryPermission" version="1" Unrestricted="true" /> 

<system.web> 
  <securityPolicy> 
    <trustLevel name="MediumPlusRegistry" 
                policyFile="web_mediumtrust_Registry.config "/> 
  </securityPolicy> 

<system.web> 
  <trust level="MediumPlusRegistry" originUrl=""/> 
</system.web>

Início da página

Resumo

A segurança de acesso ao código é um modelo de segurança de restrição a recursos que pode ser usado para ajudar a isolar aplicativos. Os aplicativos podem ser configurados para funcionar em vários níveis de confiança parciais. O nível de confiança determina as permissões que são concedidas ao aplicativo ASP.NET Web ou ao Web Service. Isso determina os tipos de fontes que podem ser acessadas e outros tipos de operações privilegiadas que podem ser executadas. Observe que todo acesso a recursos está, em última análise, sujeito à segurança do sistema operacional.

O modelo recomendado de isolamento utiliza os pools de aplicativos do Windows Server 2003 e oferece isolamento de processo, além de segurança de acesso ao código. No Windows 2000, o isolamento pode ser conseguido apenas por meio da segurança de acesso ao código e de identidades de segmento separadas.

Fazer a migração de um aplicativo para que ele seja executado com confiança total geralmente requer uma certa reengenharia. Talvez seja preciso fazer uma reengenharia no caso das fontes de acesso de aplicativos não serem permitidas por um nível de confiança parcial ou no caso de conjuntos com nomes de alta segurança que não contenham APTCA. Nesses casos, você pode colocar no modo seguro o acesso privilegiado a recursos em conjuntos wrapper separados. Em alguns casos, você pode criar e usar arquivos personalizados de diretivas, embora isso dependa da diretiva de segurança do seu servidor de Web.

Recomenda–se que, no projeto, o código de acesso ao recurso seja colocado em conjuntos separados e que se evite a colocação desse código em arquivos .aspx, bem como a colocação código por trás de arquivos. O uso de conjuntos separados permite que a diretiva de segurança de acesso ao código seja aplicada ao conjunto independentemente do aplicativo da Web, além de permitir que você desenvolva códigos confiáveis no modo seguro para ter acesso aos recursos.

Início da página

Outros recursos

Para obter mais informações, consulte os seguintes recursos:

Início da página