A8 Failure to Restrict URL Access

Artigo sobre a vulnerabilidade Falha na restrição de acesso a URL, oitavo item da lista TOP 10 da WOASP

Quando a aplicação web permite que páginas privadas sejam acessadas sem a devida autenticação tanto para usuários anônimos como para usuário autenticados, então ela é vulnerável à falhas na restrições de acesso a URL's. Aplicações que validam privilégios apenas no lado cliente também estão, igualmente, vulneráveis. Normalmente, o desenvolvedor, por inexperiência, acredita que a única proteção para uma URL é não mostrar o link para usuários não autorizados. No entanto um usuário hábil, motivado ou apenas um atacante com sorte pode ser capaz de descobrir essas páginas, executar funções e visualizar dados. Tal falha permite aos atacantes acessarem funcionalidades não autorizadas. Funções de administração são o alvo chave neste tipo de ataque.

A proteção da URL é gerida tanto pelo código fonte como pela configuração do servidor web na qual a aplicação esta instalada (no caso do PHP o servidor é o Apache). A vulnerabilidade pelo código fonte ocorre quando os desenvolvedores não efetuam validações apropriadas e a vulnerabilidade pela configuração ocorre quando o servidor encontra-se mal configurado e/ou os componentes estão desatualizados. A tabela abaixo sintetiza a classificação do risco.

Mapeamento de risco Falha na restrição de acesso a URL

A melhor forma de saber se uma aplicação falha na restrição de acesso a uma URL consiste em verificar todas as páginas. É preciso observar a existência de autenticação e autorização. Scanners de vulnerabilidades encontram dificuldade em identificar quais são as páginas (URL's) vulneráveis, por tanto a detecção é classificada como nível médio.

A abordagem mais eficiente e precisa está em utilizar a combinação da revisão do código fonte e dos teste de segurança para verificar os mecanismos de controles de acesso. A verificação se torna mais eficiente se o mecanismo for desenvolvido de forma centralizada. Quando o mecanismo é implementado de forma distribuída a verificação pode se tornar dispendiosa.

Exemplo de sistema aplicação vulnerável

O principal método de ataque é chamado de "navegação forçada" (forced browsing), na qual envolve técnicas de adivinhação de links ("guessing") e força bruta (brute force) para achar páginas desprotegidas. O atacante pode forçar a navegação das URL ́s alvo. As URL's listadas no código abaixo exemplificam áreas do sistema que requerem autenticação.

http://sistemavulneravil.com/app/getAppInfo
http://sistemavulneravil.com/app/admin_getAppifo

As áreas (pastas) listas abaixo são exemplos de pastas do Sistema Operacional Linux. São muito conhecidas e por essa razão podem ser alvos fáceis.

/system/
/password
/logs/
/admin/
/test/

Este tipo de ataque também é conhecido como "path transversal", ele ataca as pastas do sistema operacional através do sistema web vulnerável. O código seguinte exemplifica um sistema vulnerável. A linha 02 armazena na variável $template o valor referente ao templete padrão blue.php. A linha 03 e 04 recebe os dados do cookie template, parâmetro este, acessível ao usuário e que pode ser manipulado pelo atacante. A linha 05 expressa a vulnerabilidade, ela concatena o valor do parâmetro (malicioso) e busca o arquivo no disco rígido.

 1  
 2 <?php
 3 
 4 $template = 'blue.php';
 5 
 6 if (  isset($_COOKIE['template'])  ){
 7 
 8     $template = $_COOKIE['template'];
 9     include ( "/home/users/phpguru/templates/" . $template );
10 
11 }
12 
13 ?>

O atacante poderia forjar a requisição conforme ilustrado abaixo.

GET /vulnerable.php HTTP/1.0
Cookie: TEMPLATE=../../../../../../../../../etc/passwd

Neste caso, o servidor da aplicação geraria a seguinte informação:

HTTP/1.0 200 OK
Content-Type: text/html
Server: Apache

root:fi3sED95ibqR6:0:1:System Operator:/:/bin/ksh 
daemon:*:1:1::/tmp: 
phpguru:f8fk3j1OIf31.:182:100:Developer:/home/users/phpguru/:/bin/csh

As seguintes funções do PHP merecem atenção especial, quando for realizada a revisão do código: include(), include_once(), require(), require_once(), fopen() e readfile().

Ouro exemplo de aplicação vulnerável é quando URLS "escondidos" e "especiais" são mostrados na camada de aplicação apenas para administradores e usuários privilegiados, porém acessível a todos os usuários que tenham conhecimento da URL.

Mais um exemplo é quando a aplicação permite acesso a arquivos "escondidos" como, por exemplo arquivos de configuração (.ini ou .inc) confiando toda segurança na obscuridade.

Prevenção

A prevenção contra esta vulnerabilidade requer a seleção de uma abordagem que permita solicitar a autenticação adequada em cada página do sistema. O OWASP Top 10 (2010) sugere as seguintes recomendações:

 1  
 2 <?php
 3 try{
 4     $ESAPI->accessController()->assertAuthorized("businessFunction", runtimeData);
 5     //a aplicação segue se curso normalmente
 6     if ( $ESAPI->accessController()->isAuthorized("businessFunction", runtimeData) )
 7         echo "<a href=\"/doAdminFunction\">ADMIN</a>";
 8     else
 9         echo "<a href=\"/doNormalFunction\">NORMAL</a>";
10 
11 } catch ($ESAPI->AccessControlException) {
12       // um ataque pode estar acontecendo
13 }
14 ?>
# www/.htaccess
ReswriteEngine On
# RewriteBase/
RewriteRule !\,(js|ico|txt|gif|jpg|png|css)$index.php

Comentários

comments powered by Disqus