Falhas no Controle de Acesso em Aplicações Web

Tempest Security
Jan 18 · 6 min read

Havendo uma vulnerabilidade, um atacante poderia comprometer a aplicação por completo

Image for post
Image for post
Photo by Gerd Altmann on Pixabay

Por Gabrielle Delgado

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;

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:

Image for post
Image for post
Figura 1 — Exemplo de requisição que consulta o número de celular do cliente a partir do CPF

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:

Image for post
Image for post
Figura 2 — Exemplo de requisição com os parâmetros “cpf” e “all_data”

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:

Image for post
Image for post
Figura 3 — Exemplo da requisição da funcionalidade de Perfil

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:

Image for post
Image for post
Figura 4 — Exemplo de URLs que requerem autenticação

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;

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

SideChannel-BR

Notícias e análises sobre segurança da informação…

Tempest Security

Written by

Empresa líder no mercado brasileiro de segurança da informação e combate a fraudes digitais, atuando desde o ano 2000.

SideChannel-BR

Notícias e análises sobre segurança da informação produzidas pela equipe e por amigos da Tempest Security Intelligence

Tempest Security

Written by

Empresa líder no mercado brasileiro de segurança da informação e combate a fraudes digitais, atuando desde o ano 2000.

SideChannel-BR

Notícias e análises sobre segurança da informação produzidas pela equipe e por amigos da Tempest Security Intelligence

Medium is an open platform where 170 million readers come to find insightful and dynamic thinking. Here, expert and undiscovered voices alike dive into the heart of any topic and bring new ideas to the surface. Learn more

Follow the writers, publications, and topics that matter to you, and you’ll see them on your homepage and in your inbox. Explore

If you have a story to tell, knowledge to share, or a perspective to offer — welcome home. It’s easy and free to post your thinking on any topic. Write on Medium

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store