A2 Falha de Controle de Acesso
Origem: OWASP Chapter Brasil, a enciclopédia livre.
Conteúdo |
A2.1 Descrição
O controle de acesso, chamado às vezes autorização, é como uma aplicação web concede o acesso ao conteúdo e as funções para uns usuários e para outros não. Estas verificações são executadas após a autenticação e controlam o que os usuários estão autorizados a fazer. O controle de acesso parece simples de implementar, mas é difícil implementar corretamente. O modelo de controle de acesso de uma aplicação web tem uma relação estreita com o conteúdo e funções que o site provê. E os usuários podem estar em diversos grupos ou perfis com capacidades e privilégios diferentes.
Os desenvolvedores freqüentemente desprezam a dificuldade de criar um mecanismo de controle de acesso confiável. Muitos destes esquemas não foram projetados deliberadamente, mas evoluíram junto com o web site. Nestes casos as regras do controle de acesso são introduzidas em vários locais em todo o código. Quando as regras são criadas sobre demanda e o controle de acesso está espalhado pelo código, é quase impossível compreender seu funcionamento.
Muitas das falhas do controle de acesso não são difíceis de descobrir e explorar. Tudo que deve ser feito é um levantamento de todas as funções e o conteúdo que não deve ser acessado. Uma vez que uma falha é descoberta, as conseqüências de uma falha no esquema de controle de acesso podem ser devastadoras. Além da visualização de conteúdo não autorizado, um invasor pode mudar, apagar o conteúdo, executar funções desautorizadas ou tomar o controle sobre da administração do site.
Um tipo específico de problema de controle de acesso são as interfaces administrativas criadas pelos desenvolvedores para que possam administrar o site através da Internet. Tais características são usadas freqüentemente, permitindo que os administradores do local controlem usuários, dados e o conteúdo do site. Em muitos exemplos, os sites suportam uma variedade de perfis administrativos para permitir uma granularidade mais apurada da sua administração. Devido a seu poder, estas relações são freqüentemente os alvos principais de ataque por invasores externos (outsiders) e internos (insiders).
A2.2 Ambientes Afetados
Todos os servidores Web, servidores de Aplicação, usuários da aplicação e os ambientes da aplicação web são suscetíveis ao menos a algumas destas falhas. Mesmo se um site é completamente estático, se não estivesse configurarado corretamente, os hackers poderiam ganhar acesso aos arquivos sensíveis e desfigurar o site, ou causar algum outro dano.
A2.3 Exemplos e referências
• Guia OWASP de Construção de Aplicações Web Seguras, capítulo 8: Controle De Acesso: http://www.owasp.org/guide/
• Controle de acesso (autorização) em sua aplicação J2EE http://www.owasp.org/columns/jwilliams/jwilliams3.html
• http://www.infosecuritymag.com/2002/jun/insecurity.shtml
A2.4 Como identificar se você está vulnerável
Virtualmente todos os sites têm algumas exigências de controle de acesso. Conseqüentemente, uma política do controle de acesso deve ser claramente documentada. Também, a documentação do projeto deve ser relacionada para reforçar esta política. Se esta documentação não existir, é muito provável que o site seja vulnerável.
O código que executa a política do controle de acesso deve ser verificado. Tal código deve ser bem estruturado, modular, e preferencialmente centralizado. Uma revisão de código detalhada deve ser executada para validar a exatidão da execução do controle de acesso. Um teste de invasão ("penetretion test") é muito útil para determinar falhas no controle de acesso.
Investigue como é administrado seu site web. Descubra como são feitas as mudanças nas suas páginas web, onde são testadas e como são enviadas para o servidor de produção. Se os administradores podem fazer mudanças remotamente, saiba como os canais de comunição são protegidos. Reveja com cuidado cada interface para certificar-se de que somente o acesso permitido aos administradores está autorizado. Também, se houver tipos ou agrupamentos diferentes dos dados que podem ser acessados através da interface, certifique-se de que somente os dados autorizados podem ser alcançados também. Se tais interfaces empregarem comandos externos, certifique-se que o uso de comandos não são sujeitos a algumas das falhas da injeção do comando descritas neste paper.
A2.5 Como se proteger
A etapa mais importante é captar as exigências do controle de acesso de uma aplicação e descrevê-las em uma política de segurança de aplicaçôes web. Nós recomendamos fortemente o uso de uma matriz de controle de acesso para definir as regras do controle de acesso. Sem documentar a política de segurança, não há nenhuma definição do que significa estar seguro para este site. A política deve documentar que tipos de usuários podem acessar o sistema, quais funções e qual conteúdo esses usuários podem acessar. O mecanismo do controle de acesso deve ser testado exaustivamente para estar certo de que não há nenhuma maneira de contorná-lo. Estes testes exigem uma variedade de contas de acesso e tentativas exaustivas de acesso s conteúdos e funções não autorizadas.
Alguns assuntos específicos do controle de acesso incluem:
• Id's inseguros - A maioria dos sites web usam algum formulário de identificação, chave ou índice como uma maneira de referenciar os usuários, papéis, conteúdo, objetos ou funções. Se um atacante puder adivinhar estes id's e os valores fornecidos não estiverem validados para assegurar que estão autorizados para o usuário atual, o atacante pode se aproveitar livremente do esquema do controle de acesso para ver o que pode acessar. As aplicações web não devem confiar no segredo de nenhum id's para a proteção.
• Navegação forçada saltando a verificação do controle de acesso - muitos sites requerem que os usuários passem determinadas verificações antes de ser concedido o acesso a determinadas URLs que são tipicamente "mais internas" em um site. Estas verificações não devem ser bypassadas caso um usuário simplesmente pule a página de controle de acesso.
• Path Traversal - este ataque envolve fornecer a informação relativa ao path (por exemplo, "../../target_dir/target_file") como a parte de um pedido para a informação. Tais ataques tentam alcançar os arquivos que não são diretamente acessíveis por qualquer um, ou seriam negados se fossem pedidos diretamente. Tais ataques podem ser submetidos em URLs, assim como qualquer outra entrada que acesse um arquivo (isto é, chamadas do sistema e comandos no shell).
• Permissões de arquivo - muitos usuários da web e da aplicação confiam nas listas do controle de acesso fornecidas pelo sistema de arquivo da plataforma subjacente. Mesmo que quase todos os dados sejam armazenados em usuários back-end, há sempre arquivos armazenados localmente na web e no usuário da aplicação que não devem ser publicamente acessíveis, particularmente os arquivos de configuração, arquivos de erro e scripts que são instalados na maioria dos usuários da web e da aplicação. Somente os arquivos desenhados especificamente para serem apresentados aos usuários da web devem ser marcados como legíveis, usando o mecanismo de permissões do Sistema Operacional. A maioria dos diretórios não devem ser legíveis e pouquíssimos arquivos, quando existirem, devem ter permissão de execução habilitada.
• Caching do lado do cliente - muitas aplicações web acessadas de computadores compartilhados situados nas bibliotecas, nas escolas, nos aeroportos e em outros pontos de acesso público mantém cache dos sites visitados. Isso pode ser utilizado por atacantes para obter acesso às partes inacessíveis dos sites. Os colaboradores devem usar mecanismos múltiplos, incluindo cabeçalho do HTTP e meta Tag, para se certificarem que as páginas que contenham informação sensível não estão sendo armazenadas em cache pelo browser dos usuários.
Há alguns componentes de segurança da camada de aplicação que podem ajudar no fortalecimento apropriado de alguns aspectos de seu esquema de controle de acesso. Novamente, assim como os parâmetros de validação, para que o componente seja eficaz, ele deve ser configurarado com uma definição estrita de que pedidos de acesso são válidos para seu site. Ao usar tal componente, você deve ter cuidado para compreender exatamente que ajuda ao controle de acesso, o componente pode fornecer para você dado a política da segurança do seu site, e que parte de sua política de controle de acesso que o componente não pode tratar e deve conseqüentemente ser tratado corretamente em seu próprio código customizado.
Para as funções administrativas, a recomendação preliminar deve permitir que nunca o acesso do administrador seja feito através do front-end do seu site, se possível. Dado o poder destas interfaces, a maioria das organizações não devem aceitar o risco de tê-las disponíveis para ataques externos. Se o acesso remoto do administrador for absolutamente necessário, este pode ser realizado sem disponibilizar uma interface no front-end do site. O uso da tecnologia VPN poderia ser usado para fornecer um acesso externo ao administrador à rede interna da companhia (ou um site) de onde ele pode então acessar o site através de uma conexão interna protegida.
© 2005 The OWASP Foundation | Contact the site admin with comments/questions concerning this site.