A OWASP (Open Web Application Security Project) é uma organização sem fins lucrativos que tem como objetivo fornecer recursos e ferramentas para ajudar os desenvolvedores a criar aplicações mais seguras. Um desses recursos é o OWASP TOP 10, que representa uma lista com as principais categorias de riscos de segurança para aplicações web.
A primeira categoria é o Broken Access Control, ou em português “Quebra de Controle de Acessos”. Vou explicar neste texto como ela funciona e porquê nós devemos estar cientes desse tipo de risco na hora de construir uma aplicação.
Antes de começar, é importante que devs tenham contato com o OWASP TOP 10 porque são eles os principais responsáveis pela construção e manutenção das aplicações. Conhecer esses riscos, suas vulnerabilidades e tipos de ataques, podem ajudá-los a identificar e corrigir problemas de segurança antes de serem explorados por atacantes.
Quer saber mais sobre a OWASP, confira este artigo.
Mas antes de pensar na quebra, o que seria o “Controle de Acessos”?
O controle de acesso em aplicações web é o processo de garantir que somente usuários autorizados tenham acesso a recursos e funcionalidades específicas do aplicativo. Ele é composto de duas partes principais: autenticação e autorização.
A autenticação é o processo de verificação da identidade do usuário. Ele garante que somente usuários legítimos possam acessar o aplicativo. Isso pode ser feito por meio de login e senha, tokens de acesso, certificados digitais, entre outros. Por outro lado, a autorização é o processo de garantir que um usuário autenticado tenha acesso somente aos recursos e funcionalidades para os quais ele foi autorizado. Isso é feito através de permissões e papéis de usuários
O controle de acesso em aplicações web é importante para garantir a segurança dos dados e sistemas, impedindo acesso não autorizado e protegendo contra ameaças como ataques de força bruta, roubo de identidade e vazamentos de informações confidenciais.
Exemplos de Controles de Acesso em Software:
- Gestão de contas;
- Mapeamento dos direitos dos usuários para requisitos de negócios e processos;
- Mecanismos que impõem políticas sobre o fluxo de informações;
- Limites no número de sessões simultâneas;
- Bloqueio de sessão após um período de inatividade;
- Encerramento da sessão após um período de inatividade, tempo total de uso ou hora do dia;
- Limitações no número de logs retornados de uma consulta (mineração de dados);
- Apresenta políticas de aplicação de segregação de funções;
- Segregação e gerenciamento de contas de usuários privilegiados;
- Implementação do princípio do menor privilégio para a concessão de acesso;
- Exigir VPN (rede privada virtual) para acesso;
- Reconfiguração dinâmica de interfaces de usuário com base em autorização;
- Restrição de acesso após uma determinada hora do dia.
A01 "Broken Access Control" - a Quebra de Controle de Acessos
Broken Access Control é o risco de segurança de aplicações web mais comum, segundo a OWASP, e foi classificado como o #1 em 2021. Isso representa um salto significativo em relação ao seu lugar anterior de #5 em 2017.
Em resumo, o "Broken Access Control" é uma categoria de risco porque é uma falha no mecanismo de controle de acesso, permitindo que usuários acessem recursos ou realizem ações fora de suas permissões. Ou seja, ocorre quando as verificações de autorização e autenticação são mal implementadas, permitindo que usuários não autorizados acessem recursos e dados confidenciais.
Isso pode incluir violação do princípio de menor privilégio ou negação por padrão, onde o acesso deve ser concedido somente para capacidades, papéis ou usuários específicos, mas está disponível para qualquer um que tenha acesso. Outras vulnerabilidades comuns incluem: burlar as verificações de controle de acesso, permitir visualização ou edição de contas de outros usuários, acessando API sem controles de acesso, manipulação de metadados e falhas na configuração do CORS.
Mas por que esse risco está em primeiro lugar? Com o Broken Access Control representando uma ameaça mais ampla,a falta de experiência em segurança de aplicações pelos devs, protocolos de segurança complexos e a diversidade de soluções de gerenciamento de acesso são alguns dos motivos pelos quais este risco é tão comum.
Quer aprender sobre esta categoria em vídeo, clique aqui e acesse o curso sobre OWASP TOP 10.
Impacto
E o que acontece quando as pessoas têm acesso a informações que não deveriam ter?
Em um ataque bem-sucedido, um agente mal-intencionado pode ser capaz de acessar conteúdo não autorizado, alterar ou excluir conteúdo, executar funções e até mesmo assumir o controle total da administração do site.
Uma vez que esse nível de comprometimento tenha sido alcançado, o dano do ataque é limitado apenas pelos privilégios concedidos ao perfil de usuário da aplicação que sofre o ataque.
Exemplo de cenário no tipo de ataque mostrado pela OWASP:
Imagina uma aplicação que tem uma funcionalidade de gerenciamento de usuários, onde os administradores podem visualizar, editar e excluir usuários. A aplicação usa o parâmetro "userId" para identificar qual usuário está sendo gerenciado. No entanto, a aplicação não verifica se o usuário atualmente conectado tem a permissão de gerenciar usuários.
Um atacante pode aproveitar isso, modificando o valor do parâmetro "userId" em uma requisição para acessar informações ou realizar ações em contas de usuários que eles não deveriam ter acesso.
Exemplo:
https://example.com/app/manageUsers?userId=999
Se a aplicação não verificar se o usuário atual tem permissão para gerenciar usuários, o atacante pode acessar informações ou realizar ações em uma conta de usuário específica, mesmo se eles não tiverem permissão para fazê-lo. Muito simples e fácil!
Para solucionar o problema descrito, desenvolvedores devem adotar as seguintes medidas:
- Adicionar verificações de permissão para garantir que somente usuários com a permissão adequada possam acessar a funcionalidade de gerenciamento de usuários. Isso pode ser feito usando o mecanismo de autenticação e autorização existente na aplicação.
- Validar o valor do parâmetro "userId" antes de processar a requisição. Isso pode ser feito verificando se o valor do parâmetro está presente na lista de usuários permitidos para serem gerenciados pelo usuário atual.
- Adicionar um mecanismo de log para registrar todas as tentativas de acesso não autorizado à funcionalidade de gerenciamento de usuários. Isso pode ser usado para identificar e rastrear os atacantes.
- Realizar testes unitários e de integração para garantir que as novas verificações de permissão e validação de parâmetros estejam funcionando corretamente.
Prevenção
Para evitar esse tipo de ataque, desenvolvedores devem implementar as seguintes medidas de segurança:
- Implementar controles de acesso no código do lado do servidor, onde o atacante não pode modificar as verificações de acesso ou metadados. Isso garante que somente usuários autorizados possam acessar recursos específicos.
- Utilizar a regra "negar por padrão", onde somente usuários com permissões específicas podem acessar os recursos necessários.
- Reutilizar os mecanismos de controle de acesso em toda a aplicação e minimizar o uso de Cross-Origin Resource Sharing.
- Modelar os controles de acesso para garantir a propriedade dos registros, em vez de permitir que todo usuário crie, leia, atualize ou exclua qualquer registro. Isso garante que somente os proprietários dos registros possam acessá-los.
- Definir regras de negócio únicas aplicadas ao domínio. Isso garante que os usuários não possam realizar ações que eles não deveriam ser capazes de fazer.
- Desabilitar a listagem de diretórios do servidor web e garantir que os metadados de arquivos e arquivos de backup não estejam presentes nos diretórios raízes da web. Isso impede que os atacantes acessem arquivos sensíveis.
- Fazer log das falhas de controle de acesso e alertar os administradores quando apropriado (por exemplo, falhas repetidas). Isso ajuda a identificar e corrigir problemas rapidamente.
- Limitar a taxa de acesso à API e controladores para minimizar danos causados por ferramentas de ataque automatizadas. Isso impede que os atacantes sobrecarreguem a aplicação com requisições.
- Invalidar identificadores de sessão stateful no servidor depois do logout e tornar os tokens JWT stateless de curta duração. Isso minimiza a janela de oportunidade para um atacante.
- Incluir testes de unidade e de integração de controle de acesso funcional para desenvolvedores e equipe de QA. Isso garante que os controles de acesso sejam testados e verificados antes do lançamento.
Tudo isso você pode encontrar aqui, na própria página da OWASP sobre esta categoria.
Não deixe o Controle de Acessos da sua aplicação quebrar!
Portanto, o Broken Access Control é uma dos riscos mais comuns no campo de Segurança de Aplicações web. E, com este artigo, você obteve uma compreensão mais clara sobre esse risco, como ele funciona, quais são os impactos potenciais e como proteger suas aplicações.
Não deixe de levar essas informações e aplicá-las na prática para garantir que suas aplicações estejam protegidas contra este risco comum. Lembre-se de implementar medidas de segurança, como o princípio de privilégios mínimos, mecanismos de controle de acesso consistentes, além de testar regularmente e manter-se atualizado sobre as tendências e ameaças. Com essas medidas, você pode ter a certeza de que suas aplicações estão protegidas e seus usuários estão seguros.
Para mais conteúdos sobre a OWASP TOP 10, acesse este artigo.
Existem algumas dicas sobre como implementar medidas de “Autorização” fornecidas pela OWASP
Veja algumas vulnerabilidades associadas a esta categoria de risco fornecida pela OWASP.
Top comments (0)