Translate this page now :



»Programação
»Programação.NET
»Banco de Dados
»Webdesign
»Office
» Certificações Microsoft 4
»Treinamentos4
»Programação 4
»Webdesign«
»Office & User Tips«
»Grupos de Usuários
»Células Acadêmicas«

Et - Bill
Você já está cadastrado e participa do grupo de usuários de sua cidade ? Se não, comente o porque.
 
 
Faça um pequeno teste com 10 questões de VB
.:.
Teste seus conhecimentos em Visual Basic, SQL Server e ASP 3.0 com nossas provas on-line
.:.
Aprimore seus conhecimentos em programação com nosso treinamento on-line de lógica de programação
.:.
Veja nosso calendário de treinamentos
Gostou da Página?
Então

para um amigo!
 





Por Dennes Torres
dennes@bufaloinfo.com.br
Dennes Torres possui as certificações MCAD, MCSD,MCSE, MCDBA e MCT. Atualmente atua Como diretor da Búfalo Informática, líder do grupo de usuários DevASPNet no Rio de Janeiro e membro da liderança dos grupos getWindows e devSQL, também do Rio de Janeiro, podendo sempre ser encontrado na lista de discussão do grupo DevASPNet (devaspnet-subscribe@yahoogrupos.com.br) bem como nas reuniões do grupo. Mantém dois blogs em http://cidadaocarioca.blogspot.com

Protegendo nossos assemblys

Pesquisa personalizada
Pesquisar Dicas:







Se antes já era comum produzirmos aplicações com o uso de componentes e classes, agora que temos a orientação a objetos 100% acessível através do .NET a utilização de componentes, classes e biblioteca de classes se tornará cada vez maior.

Assim sendo ao invés de termos um único executável poderemos estar dividindo a aplicação em várias dlls, podendo desta forma reutilizar parte dos componentes criados para a aplicação. Outra vantagem da divisão em múltiplas DLLs é a criação de smart clients. Os smart clients aproveitam quando uma aplicação encontra-se dividida desta forma para fazer um download sobre demanda da aplicação, ou seja, as dlls só são downloadeadas quando o usuário realmente vai utilizar seu conteúdo (quando clica em um botão que as chama, por exemplo).

Mas o objetivo deste texto não é falar sobre a divisão em si, mas um problema que é gerado. Quando nossa aplicação possui várias dlls, nada impede que um desenvolvedor .NET faça uma cópia de uma (ou várias) destas dlls e as reutilize.

Essa reutilização inesperada gera 2 problemas :

1- Nossa produção está sendo utilizada sem nossa permissão

2- A dll em questão pode estar chamando webServices, e o acesso direto a ela pode estar sendo utilizado para burlar alguma regra imposta pela aplicação (a regra devia estar no serviço, não na aplicação, mas isso é outra história...)

Então como fazer para impedir esse uso indesejado da nossa aplicação ?

Para isso podemos utilizar a CAS - Code Access Security. É claro que a CAS faz muito mais que isso, esse é apenas um dos truques que a CAS possibilita.

E como utilizar a CAS para proteger nossa aplicação ? Podemos assinar nossa aplicação utilizando um conjunto de chaves (publica/privada) e utilizar essas chaves para garantir a segurança da nossa aplicação. Ao compilarmos a dll podemos dizer que as classes apenas poderão ser acessadas se o chamador estiver assinado com a nossa assinatura. Assim sendo apenas as aplicacoes criadas e assinadas por nós poderão acessar a DLL

Primeiramente precisamos criar o conjunto de chaves. Para isso podemos utilizar uma aplicação de prompt que é fornecida junto com o framework, só teremos o trabalho de guardar cuidadosamente o arquivo, já que deverá ser usado para assinar todas as nossas aplicações.

Veja como gerar a chave :

SN -k chave.snk

Gerado o par de chaves, precisamos assinar a dll e a aplicação. Basta adicionar um item a mais no arquivo assemblyInfo.vb de cada projeto e recompilar. Veja como fica :

<assembly:Assemblykeyfile("c:\chave\chave.snk")>

Feito isso, precisamos impor a regra que desejamos : Apenas aplicações assinadas com a nossa chave poderão executar as classes que encontram-se dentro da dll.

Para isso precisaremos descobrir qual a nossa chave pública. Mais uma vez vamos recorrer ao prompt, o próprio SN nos dará a resposta :

sn -tp chave.snk

Sim, a chave pública é um código muito grande, em hexadecimal. Ninguém conseguirá reutilizar a chave pública, pois apenas com o par (publica/privada) pode-se assinar um assembly e o par está contido no arquivo chave.snk que só você possui.

Por fim, vamos inserir nas classes que encontram-se na dll um atributo que cause a restrição. Veja como fica :

<System.Security.Permissions.Strongnameidentitypermission _
 (Security.Permissions.PermissionState.LinkDemand,PublicKey:="09393....")> _
public class umaClasse
End Class
 

Para quem já leu um pouco mais sobre CAS uma dúvida surgirá : Por que LinkDemand ao invés de Demand ?

Simples : Sobre a dll, no momento da execução, existe todo um call stack que inclui até mesmo as classes do framework. Então se utilizarmos demand, a execução sempre irá falhar, pois as classes do framework, claro, não tem nossa assinatura, nem poderiam. Ao utilizar linkDemand estamos pedindo que apenas o chamador imediato seja verificado.

Com esses passos ninguém poderá reutilizar nossa dll, pois não terá como gerar nossa assinatura.

 



Envie seus comentários sobre este artigo

Nome :

E-mail :

Comentários :


Avise-me quando houverem novos comentários nesta página

Veja abaixo os comentários já enviados :

Nome : welington E-Mail : welington.zanelato@gmail.com
Estava lendo seu artigo e estou com um erro no meu aplicativo. Quando estou conectando ele a um banco de dados, na chamada do banco ocorre este erro..


Additional information: Request for the permission of type System.Security.Permissions.StrongNameIdentityPermission, mscorlib, Version=1.0.3300.0, Culture=neutral, PublicKeyToken=b77a5c561934e089 failed.

Não sei qual esse erro... o que devo fazer para resolver..
Nome : Dennes Torres E-Mail : dennes@bufaloinfo.com.br

Você acertou quando imaginou que esteja ligado a CAS ... Certamente sua aplicação não está assinada e está tentando disparar um componente contido em uma .dll que está assinada... Isso só é permitido se a aplicação estiver rodando com FullControl, caso contrário não funcionará... Assine a aplicação e o problema será resolvido...

Nome : Marcelo E-Mail : mpdea@hotmail.com
Achei muito interessante o artigo e estou implementando em um projeto meu. Mas parei em um problema: como faço a assinatura no aplicativo? Preenchi o item AssemblyKeyFile, mas fiquei em dúvida em qual local é inserido o atributo de permissão de execução da dll. E se é o mesmo que foi inserido na dll (por exemplo: <System.Security.Permissions.Strongnameidentitypermission _
(Security.Permissions.PermissionState.LinkDemand,PublicKey:="09393....")>)

Obrigado!
Nome : Dennes Torres E-Mail : dennes@bufaloinfo.com.br

Falta um detalhe no artigo. O sn -tp não deve ser aplicado sobre o arquivo .snk com as duas chaves, mas apenas com a chave pública. Então antes de fazer o sn -tp é necessário fazer o sn -p para extrair a chave pública para outro arquivo.