O termo “Controle de Acesso” pode ser confundido com o mecanismo de autenticação de aplicações web. Contudo, apesar de estar diretamente relacionado a esse mecanismo, o controle de acesso utiliza a identidade dos usuários para validar o que cada usuário, ou perfil, pode acessar de acordo com as regras de negócio do aplicativo. Dessa maneira, o controle de acesso é um mecanismo de defesa crítico dentro das aplicações porque, havendo uma vulnerabilidade, um atacante poderia comprometer a aplicação por completo, adquirindo o controle de funcionalidades administrativas e/ou acessando dados sensíveis pertencentes a outros usuários.
Neste blogpost serão detalhadas três grandes categorias de exploração de falhas no controle de acesso de aplicações web, são elas:
- escalação vertical de privilégios;
- escalação horizontal de privilégios; e
- acesso direto e não autenticado.
Antes de detalharmos estas categorias, vamos analisar outras terminologias usadas para explicar o conceito dos problemas de segurança relacionados.
O termo “escalação de privilégios”, de modo geral, significa obter privilégios que não foram atribuídos pelas regras de negócio do sistema. Como exemplo, um usuário malicioso poderia explorar um bug, falha de design ou erro de configuração em um sistema para elevar o próprio privilégio de forma indevida. A partir dos acessos obtidos, o usuário atacante pode usar os privilégios adquiridos, por exemplo, para roubar dados confidenciais, executar comandos administrativos, entre outras ações maliciosas.
Outro termo usado no contexto de aplicações web é “acesso direto ao objeto”, também conhecido como Insecure Direct Object References — IDOR. Esta terminologia é definida como uma vulnerabilidade no controle de acesso de aplicativos que usam entradas fornecidas pelos usuários para acessar objetos diretamente. Uma referência direta ao objeto ocorre quando um desenvolvedor expõe um arquivo, diretório, registro de banco de dados ou chave como um parâmetro da requisição HTTP. Havendo o acesso direto à objetos, um atacante poderia acessar recursos fora do seu escopo previsto e escalar seu privilégio, portanto este problema está diretamente relacionado com o tema aqui descrito.
Entendido os conceitos, a seguir abordaremos as categorias citadas anteriormente e seus respectivos exemplos, bem como possíveis estratégias de mitigação.
Escalação Vertical de Privilégios
Este tipo de exploração ocorre quando um usuário com um nível de privilégio baixo pode executar ações previstas apenas para perfis de acesso mais elevados.
Imagine o cenário de uma aplicação de CRM (Customer Relationship Management) em que um determinado funcionário pode consultar apenas o número de CPF e o telefone celular dos clientes cadastrados. A respectiva requisição seria mais ou menos assim:
Como pode ser observado, o número de CPF do cliente é utilizado como um índice de registro nas consultas que são realizadas no banco de dados, para retorno do telefone do cliente respectivo ao CPF. Supondo que não haja maior controle sobre o privilégio dos perfis existentes na aplicação em questão, o referido funcionário, com más intenções, pode simplesmente tentar adicionar o parâmetro all_data com o valor true na requisição exemplificada. Segue a mesma requisição ilustrada anteriormente, agora com o novo parâmetro:
Se a aplicação retornar todos os dados cadastrais do cliente cujo CPF é 742.493.270–51, o usuário de menor privilégio realizou uma ação na qual apenas um administrador deveria ter acesso, resultando na escalação vertical.
Escalação Horizontal de Privilégios
Este tipo de exploração acontece quando, por exemplo, um usuário consegue acessar as informações de outros usuários com o mesmo perfil de autorização.
Os ataques de escalação horizontal de privilégios podem usar métodos de exploração semelhantes aos da escalação vertical. Para facilitar a compreensão, tomaremos como exemplo um e-commerce. Tomando como base que um cliente ao acessar a funcionalidade “Perfil” do website geraria uma requisição como:
Supondo também que o valor 17992 tem o papel de identificar o usuário, sendo este um objeto que é manipulado pelo client-side e aceito no server-side sem a devida validação. Então um cliente, com más intenções, poderia simplesmente modificar o valor 17992 e, assim, acessar as informações cadastrais da conta de outros clientes da aplicação em questão.
Acesso direto e não autenticado
Acessos diretos e não autenticados podem ocorrer devido a diversas implementações errôneas, por exemplo, quando considera-se páginas ou rotas que podem ser acessadas sem uma sessão válida. Isso pode acontecer em pontos afetados que seriam acessados de forma autenticada, de acordo com as regras de negócio em vigor no aplicativo, porém mesmo com a remoção dos tokens de sessão ainda é possível acessá-los normalmente.
Outra forma de ilustrar esse problema é quando um ponto afetado está acessível publicamente e foi descoberto através motores de busca, mas deveria ser acessado apenas de forma autenticada, devido a exposição de informações críticas.
Também existe o cenário em que os administradores de um aplicativo publicam páginas “ocultas” sem qualquer necessidade de autenticação, na esperança de que um eventual atacante não as descobriria. Esta metodologia de publicação segue o princípio da “segurança por obscuridade”, que é a dependência do sigilo do projeto ou implementação para proporcionar a proteção de um sistema, o que não é uma prática recomendada. Nesse exemplo, um simples processo automatizado (fuzzing) pode resultar no acesso ao conteúdo das páginas omitidas.
A imagem a seguir exemplifica duas URLs que deveriam requerer uma sessão válida para que seu conteúdo seja acessado:
As URLs listadas na Figura 4 indicam que informações sensíveis podem ser acessadas de forma direta e não autenticada, ou seja, não há um controle de acesso bem definido na respectiva aplicação.
Impacto
Uma vez que ocorre a má implementação do controle de acesso, um eventual atacante poderá obter acesso irrestrito e privilegiado à aplicação alvo, como por exemplo: acessar áreas exclusivas, recuperar informações pessoais dos usuários e consultar funcionalidades que apenas um usuário autenticado deveria ter acesso.
Correção
A principal maneira de se resolver problemas da escalação de privilégios e do acesso direto e não autenticado é:
- implementar um mecanismo de controle de acesso que restrinja o acesso às áreas administrativas da aplicação apenas para administradores devidamente autenticados, e;
- garantir que os usuários dos demais perfis executem apenas ações que estão dentro da sua autorização, de acordo com as regras de negócio do sistema.
De modo geral, a determinação de quais atividades estão associadas a cada usuário (perfil) deve ser mantida exclusivamente no server-side, ou seja, o controle de quais funcionalidades podem ser acessadas ou quais funções podem ser executadas por determinado usuário não deve ser efetuado apenas através das páginas renderizadas no browser (client-side), sendo que a sessão dos usuários deve ser utilizada pelo back-end para efetuar esse controle.
Além disso, vale destacar mais uma vez que a implementação do princípio da “segurança por obscuridade” não é uma boa prática, visto que, existindo um atacante real sem restrição de tempo, este poderia acessar as eventuais informações “ocultas”.
Implementar um mecanismo de controle de acesso em aplicações web requer um planejamento cuidadoso, de modo a garantir um controle efetivo dos acessos e definir o que deve ser público ou privado e quem pode acessar cada uma das funções existentes.
Conclusão
Como pôde ser observado, o controle de acesso em aplicações web é um desafio, devido ao fato de haverem diversas vertentes que precisam ser analisadas. Todavia, existindo um bom planejamento e o devido conhecimento, toda preocupação proveniente da exploração dos respectivos problemas de segurança pode ser sanada ou evitada nas aplicações.
Por fim, é sempre recomendado seguir as boas práticas de segurança, visando diminuir a superfície de ataque ao máximo e unindo da melhor forma uma boa experiência ao usuário com a proteção das suas informações.
Referências
- https://owasp.org/www-pdf-archive/OWASP_TOP_10_2007_PT-BR.pdf
- https://cheatsheetseries.owasp.org/cheatsheets/Insecure_Direct_Object_Reference_Prevention_Cheat_Sheet.html
- https://portswigger.net/web-security/access-control
- https://owasp.org/www-chapter-ghana/assets/slides/IDOR.pdf
- STUDDARD, Dafydd; PINTO, Marcus. The Web Application Hacker’s Handbook: discovering and exploiting security flaws. 2. ed. Indianapolis: John Wiley & Sons, Inc., 2011. 853 p.
