Skip Navigation Links



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
Problema de BIOS
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!

Pesquisa personalizada
Pesquisar Dicas:

 






Entendendo a pequena falha de segurança no ASP.NET - Canonicalization

 

Agora que vários sites estão espalhando para tudo quanto é canto que o ASP.NET tem uma falha grave de segurança, o melhor é que nós, desenvolvedores de sofware, tenhamos o conhecimento adequado para saber exatamente qual a gravidade da falha, quais aplicações estão ou não sujeitas a ela e quais cuidados devemos tomar para evita-la.

Então, antes que os javistas ou outras seitas comecem a falar mal de nossa ferramenta de trabalho, vamos nos aprofundar no assunto.

A falha de segurança de que tanto se fala trata-se de um problema de canonicalization.

Seguindo ao pé da risca o termo, canonicalization é o processo de tornar algo em conformidade com uma determinada especificação. Nesse caso se refere a uma entrada feita pelo usuário. Desta forma quando dizemos problema de canonicalization, é +/- um problema de validação de uma entrada feita pelo usuário. Vou descrever aqui especificamente no que se refere a referencia a arquivos.

Com relação a arquivos em disco, o problema de canonicalization ocorre devido as múltiplas formas de nos referirmos ao mesmo arquivo. Veja um exemplo :

c:\temp\somefile.dat
somefile.dat
c:\temp\subdir\..\somefile.dat
c:\ temp\ somefile.dat
..\somefile.dat
c%3A%5Ctemp%5Csubdir%5C%2E%2E%5Csomefile.dat

Como podem observar, temos várias formas diferentes de nos referir ao mesmo arquivo.

Bem, vamos começar de forma bem genérica para depois chegarmos ao ASP.NET. O problema de canonicalization em relação a estes nomes de arquivo ocorre a partir do momento em que o usuário possa entrar com a referencia ao arquivo e, ao mesmo tempo, tenhamos algum tipo de lógica tal como "se o arquivo for tal, faça isso" É exatamente ai que mora o perigo : Como o usuário tem várias formas de se referir ao arquivo, ele pode encontrar uma forma que a lógica do nosso sistema não consiga identificar e BINGO ! Temos uma lógica que deveria ser executada e não irá rodar !

Se esta lógica estiver controlando a segurança do sistema, por exemplo, verificando se o usuário tem ou não permissão de acesso a um arquivo, o problema se agrava, temos um acesso indevido a arquivos através do nosso sistema !

E de que forma isso afeta o ASP.NET ?

Antigamente, no ASP 3, criavamos o sistema de segurança de uma forma que poderíamos chamar de "manual" : Testavamos a cada página se o usuário tinha ou não permissão de acesso a página.

Com o ASP.NET, ganhamos um sistema de autenticação e autorização muito mais simples de usar, tornando o desenvolvimento de aplicações muito mais rápido. Veja mais sobre este sistema de segurança no artigo em http://www.bufaloinfo.com.br/Artigos/artigo1510.asp

O sistema de autorização do ASP.NET é baseado nos nomes de arquivo para determinar se o usuário pode ou não ter acesso ao arquivo. Eis ai a falha de segurança : O que foi descoberto é que o sistema de autorização do ASP.NET está sujeito ao problema de canonicalization.

Reprodução do problema

1) Crie um projeto ASP.NET

2) Crie uma pasta chamada PASTA

3) Dentro da PASTA crie um novo webform, webform2.aspx

4) Altere o web.config e insira as seguintes tags, dentro de configuration e fora de system.web :

<location path="pasta"> 
<system.web>
<authorization>
<deny users="*" />
</authorization>
</system.web>
</location>
  

5) Rode a aplicação e tente acessar o webform2. Você não terá sucesso.

6) Rode novamente a aplicação. Tente novamente acessar o webform2, só que desta vez utilize o seguinte endereço :

http://localhost/WebApplication9/pasta%5cwebform2.aspx

(é claro que vc vai trocar esse webApplication9 pelo nome da sua aplicação)

Desta vez você terá sucesso no acesso, ou seja, você conseguirá ver um arquivo ao qual você não deveria ter permissão de acesso.

Fiz este exemplo com uma sub-pasta, mas os arquivos contidos na raiz da aplicação também correm perigo, veja :

 

7) Crie outro webForm, webform3.aspx, na raiz da aplicação

8) Adicione as seguintes tags ao web.config, dentro de configuration e fora do system.web :

<location path="webform3.aspx">
<system.web>
<authorization>
<deny users="*" />
</authorization>
</system.web>
</location>

 

9) Tente executar o webform3. Você observará que não terá acesso a ele.

10) Tente novamente, agora com a seguinte URL :

http://localhost/WebApplication9%5cwebform3.aspx

(é claro que vc vai trocar esse webApplication9 pelo nome da sua aplicação)

Mais uma vez você terá acesso a um arquivo que não deveria estar vendo.

 

Qual o truque ?

Simples : %5c representa a \ de acordo com o encoding de uma URL. Como o caminho para o arquivo está escrito de forma diferente, o sistema de autorização do ASP.NET não consegue identifica-lo e permite que se tenha acesso ao arquivo.

Qual a solução ?

Já existem várias soluções disponíveis :

1) Programar o global.asax

2) Utilizar um httpModule para ASP.NET

3) Utilizar o URLScan para validar as URLs solicitadas

 

Programar o Global.asax

Os eventos dos objetos no ASP.NET foram muito ampliados em comparação com os mesmos objetos no ASP 3. O objeto application possui um evento chamado BeginRequest, que acontece no momento em que o ASP.NET recebe uma nova requisição, muito antes de ocorrer o processamento do sistema de autorização do ASP.NET.

Então se programarmos o evento BeginRequest do application para validar as URLs recebidas, evitando alguns símbolos especiais, estaremos protegendo nossa aplicação ASP.NET, evitando por completo o problema de canonicalization.

Veja como fazer :

 

Sub Application_BeginRequest(Sender as Object, E as EventArgs) 
     If (Request.Path.IndexOf(chr(92)) >= 0 OR _ 
             System.IO.Path.GetFullPath(Request.PhysicalPath) <> Request.PhysicalPath) then 
        Throw New HttpException(404, "Not Found") 
     End If 
End Sub 

 

Observem os detalhes :

- Utilizando request.Path.IndexOf é feita uma validação para verificar se existe o caracter "\" dentro da URL. Se existir então trata-se de uma URL inválida.

- É feita uma comparação entre o resultado do método GetFullPath em relação ao PhysicalPath com o próprio PhysicalPath. Se forem diferentes, certamente há algum caracter especial no path, ou algo assim, podendo gerar a falha de segurança.

Desta forma basta aplicar este código no global.asax e estaremos protegidos contra a temida falha de segurança do ASP.NET

Utilizar um httpModule para ASP.NET

Um httpModule é um componente que pode ser instalado através de simples configurações nos arquivos .config. Este componente irá analisar as requisições ao servidor web e, neste caso, irá validar as URLs requisitadas evitando o problema de canonicalization.

A vantagem sobre o código acima é a simplicidade. A MS desenvolveu um httpModule para resolver o problema e um instalador. O instalador insere o httpModule no GAC (para que seja acessível a todas as aplicações da máquina) e configura o machine.config (para que afete todos os sites na máquina).

Desta forma basta realizar a instalação deste httpModule e o problema estará resolvido.

Veja mais sobre este httpModule desenvolvido pela MS nos seguintes endereços :

http://www.microsoft.com/downloads/details.aspx?familyid=DA77B852-DFA0-4631-AAF9-8BCC6C743026&displaylang=en

http://support.microsoft.com/?kbid=887289

Utilização do URLScan

O URLScan é uma ferramenta um pouco mais antiga, criada pela Microsoft, gratuita, que faz a validação de chamadas HTTP a um servidor web. Tem diversos recursos, tal como o bloqueio de algumas extensões de arquivo.

O URLScan também resolve o problema de canonicalization no ASP.NET . Quem já utilizava o URLScan em seus servidores web pode ir dormir tranquilo, pois os servidores estão protegidos.

Veja mais detalhes sobre o URLScan em : http://www.microsoft.com/technet/security/tools/urlscan.mspx

Observações adicionais

- O atacante apenas tem acesso as funcionalidades da sua própria aplicação. Verá funcionalidades para as quais não tem permissão, mas não fará nada que a sua aplicação não esteja programada para fazer

- A falha apenas afeta aplicações que dependam do sistema de autorização do ASP.NET. Se sua aplicação não utiliza este recurso, não existe o menor perigo.

Conclusão

A falha dá ao atacante um grande acesso ao sistema, mas depende de um certo conhecimento do atacante com relação as páginas existentes no sistema. Além disso afeta um número limitado de aplicações ASP.NET e é facilmente solicionada com uma codificação bem simples ou instalações citadas acima.

Links Interessantes

http://www.microsoft.com/security/incident/aspnet.mspx

http://support.microsoft.com/?kbid=887459

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnnetsec/html/THCMCh04.asp





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 : Leandro Davi E-Mail : Leandrodavimg@gmail.com
Ótima matéria com relação a segurança do asp.net
Nome : Dennes E-Mail : dennes@bufaloinfo.com.br

Importante destacar que este problema é antigo, não afeta mais as versões atuais.

::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::
Conheça mais sobre o nosso site :

::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::



Quer saber mais?
Faça um curso na Búfalo Informática, Treinamento e Consultoria e
Prepare-se para o Mercado!
Veja o que a Búfalo tem para você.

ļæ½ BĆŗfalo InformĆ”tica, Treinamento e Consultoria - Rua Ɓlvaro Alvim, 37 Sala 920 - CinelĆ¢ndia - Rio de Janeiro / RJ
Tel.: (21)2262-1368 (21) 9240-5134 (21) 9240-7281 e-Mail:
contato@bufaloinfo.com.br