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«
intcontpiada : 118
Listagem de Bug's
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

Provedores Erram e sites ASP.NET ficam vulneráveis

Pesquisa personalizada
Pesquisar Dicas:






Muito já foi publicado sobre esta característica do .NET a qual citarei, então é interessante vermos os trechos mais importantes do que já foi publicado para enfim chegarmos a uma conclusão.

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




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 : 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
Nome : OOxmNO1Q2 E-Mail : heutztntb@yahoo.com
Servus,Danke ffcr die super Anleitung.Habe jedoch ein kleiens Problem.Mein eigentliches Ziel ist es dem Stream als mp4(acc) anzubieten dar dieser per HTML 5 auch auf ipad etc. funktionierern wfcrde.Da ich aber schritt ffcr schritt vorgehen wollte habe ich zuerst ogg probiert was ohne probleme funktioniert. Jedoch bei mp3 und mp4 gibt es ein komisches problem zb. wenn ich eine Datei per VLC streame le4uft diese im Player viel schnellerAnhf6ren kann ich mir den Stream sowieso nicht da wenn ich die URL(Zum Anhf6ren) in einen anderen Player einffcge nie eine Verbindung aufgebaut wird ..(Play le4sst sich nicht drfccke)In der Weboberfle4che jedoch sehe ich das der Wert(total_bytes_read) steigt.Also eig. mfcsste es ja funktioniert Habe plublic auf 1 und Port, IP etc. stimmen auch alle.Nutze eine Debian Root-ServerMFG