| com exemplos em VB |
| Componente para deixar forms em Vb semelhantes às telas do winnamp |
| Componente para colocar sua aplicação VB no Systray |
| Componente para transformar sua aplicação VB em serviço |
| Ferramentas úteis para quem usa Olap Server |
 |
 |
||||||||
|
|
||||||||
|
||||||||
 |
 |
 |
 |
 |
 |
 |
||
 |
Por Dennes
Torres  dennes@bufaloinfo.com.brDennes 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 e http://br.thespoke.net/blogs/dennes/default.aspx |
|
|
|
| Provedores Erram e sites ASP.NET ficam vulneráveis | |
|
|
|
Há algum tempo atrás postei uma dica sobre compilação em batch no asp.net. Como compilar os arquivos .ASPX em bloco. O resultado da compilação fica em um diretório temporário do ASP.NET. A dica pode ser encontrada em http://www.bufaloinfo.com.br/dicas.asp?cod=699 . A compilação em batch gera uma otimização de performance, mas o interessante desta dica é que os arquivos .ASPX são compilados em sua chamada e gravados em disco em uma pasta temporária.
Logo no dia seguinte postei outra dica complementando a primeira e explicando como é possível trocar a localização do diretório temporário do ASP.NET, garantindo a melhor organização do servidor. Esta dica encontra-se em http://www.bufaloinfo.com.br/dicas.asp?cod=700
Alguns dias depois (ou antes, não lembro bem) Gilberto Uchoa (http://br.thespoke.net/myblog/ninguem/myblog.aspx ) relatou em seu blog um problema que havia tido com arquivos temporários no ASP.NET e o relato dele nos levava a uma conclusão : O ASP.NET copia o assembly do code-behind para o diretório temporário para que seja feita a execução.
Um dia ou dois atrás Gilberto postou em seu blog um artigo (http://br.thespoke.net/BlogReader/SingleEntry.aspx?ID=12060 ), que não foi escrito por ele, meio exagerado falando sobre problemas com ASP.NET. Eu já conhecia o artigo, mas o tema é bem complexo, sempre prometia que iria testar e deixava para depois.
Até que nesta 6a a noite resolvi que de hoje não passava e fiz os testes indicados no artigo (só o ponto que achei mais crítico e fiquei na dúvida, como disse, o artigo é exagerado).
E não é que funciona ?
Devido ao uso do diretório temporário pelo ASP.NET todos os usuários de site (usuários AD configurados no IIS) precisam ter permissão de full control sobre esse diretório temporário. Isso significa que todos os sites web em um mesmo servidor tem full control sobre todos os arquivos que estão neste diretório temporário.
Assim sendo, criando uma aplicação simples para listar e baixar arquivos e publicando esta aplicação em meu provedor foi possível baixar os assemblys de inúmeros sites que estavam fazendo uso de ASP.NET. Isso as 4 da manhã, horário pouco movimentado o que justifica, no meu entender, um pequeno número de sites em cache. Durante o dia provavelmente o estrago seria maior.
Utilizando o ilDasm (nem cheguei usar um disassembler, já imaginou o estrago se utilizasse um ?) pude analisar o código dos sites, ver sua divisão em classes, webControls personalizados, arquitetura em camadas, até que enfim fiquei satisfeito quando cheguei nas primeiras strings de conexão, completas, gravadas dentro da IL.
É, isto é um problema sério e certamente os provedores não notaram ainda. Então é uma boa se protegerem e avisarem aos provedores.
O que fica no diretório temporário é a IL. Assim sendo qualquer informação inserida na IL pode ser roubada. Por outro lado informações inseridas no web.config *a principio* não podem ser pegas.
Uma possível solução para o problema seria que cada site especificasse um diretório de compilação temporária diferente, utilizando a tag <compilation> citada em uma dica acima. Ainda assim é necessário que :
- Os provedores disponibilizem um espaço fora do compartilhamento
http para que cada site faça isso
- Os provedores instruam os webmasters a fazerem esta configuração
- Os webmasters façam esta configuração
Matutando um pouco : Se temos fullcontrol sobre o diretório temporário, também poderia escrever, correto ? Então se conseguir baixar um dos assemblys e trocar um select por delete (seria possível ?) dá para fazer um estrago, não é ?
Vejamos então como fica a solução com a tag compilation. De fato já há uma tag compilation no web.Config, mas sem o atributo tempDirectory. Então a única coisa a fazer é inserir o tempDirectory, veja como fica :
<compilation defaultLanguage="vb" debug="true" tempDirectory="c:\inetpub\wwwroot\webApplication2\teste"
/>
É claro que isso é só um exemplo bem bobinho. Isso porque inseri o diretório temporário dentro do compartilhamento web, o que não deveria ser feito. Porém para fazer o exemplo corretamente em um provedor você dependerá do provedor disponibilizar um diretório para isso fora do compartilhamento web, o que raramente é feito até por desconhecimento desta necessidade no ASP.NET.
Se este exemplo for feito dentro de um compartilhamento web em um provedor a única proteção que seus assemblies terão é o fato do usuário do seu site desconhecer o nome do diretório que você criou. Isso é pouco em termos de segurança, mas pode quebrar o galho.
Uma pergunta que podem estar fazendo é : Mas se o provedor simplesmente tirar o diretório de compilações temporárias do seu caminho default isso não resolve o problema ?
Não, não resolve. Veja porque :
Dim a As [Assembly]
a = [Assembly].GetExecutingAssembly
Label1.Text = a.Location
Basta esse código para que o caminho seja descoberto, qualquer que seja ele. Isso permite que qualquer cliente do provedor tenha acesso aos assemblies de todos os outros. A única solução fica sendo isolar os diretórios temporário por cliente, com a tag compilation em cada web.Config
Creio já ter visto algumas equipes de provedores aqui pelo TheSpoke. Gostaria muito de saber o que planejam para resolver o problema.
Curiosidade : Não considero isso uma falha do ASP.NET. Conforme vimos, é resolvido com uma simples configuração. Considero isso apenas uma desinformação quanto as configurações necessárias para hospedar sites que utilizem ASP.NET
Veja abaixo os comentários já enviados :
| Nome : Gustavo Nalin | E-Mail : gustavo@nalin.cc |
| Muito bom. | |
| Nome : Charles | E-Mail : charles@onwaytecnologia.com |
| Interessante | |
| Nome : Paulo Guedes | E-Mail : pguedes@amazon.com.br |
| Considero, sim, uma falha de segurança do ASP.NET. Embora possa ser resolvido com uma simples configuração, trata-se de uma falha deixar a brecha aberta por default. | |
| Nome : Flavio Oliveira | E-Mail : flaviomarc@hotmail.com |
| Gostei, muito interessante e útil. | |
| Nome : Luiz Claudio | E-Mail : luizc1@globo.com |
| E porque não é divulgado mais abertamente este problema para os provedores? Isso deveria ser motivo de alerta no mundo dos provedores, não vi este artigo em revistas mas eles devem saber disso, concorda? |
|
| Nome : Emerson | E-Mail : emerson@netcreator.com.br |
| Bom, gostaria de saber então se em meu projeto eu estiver utilizando Codebehind nas páginas, não terei esse problema? |
|
| Nome : Dennes Torres | E-Mail : dennes@bufaloinfo.com.br |
O ASP.NET também copia a DLL do codebehind para o diretório temporário, para evitar bloquea-la em seu local original. Então o problema fica sendo o mesmo... |
|
| Nome : KARINE | E-Mail : DRKARINE@YAHOO.COM.BR |
| MUITO ÚTIL, INTERESSANTE.SEGURANÇA NA NET, FUNDAMENTAL | |
