Todo mundo sabe que existem falhas em um sistema, mas você já passou por uma situação em que, por uma sequência de acontecimentos, foi possível explorar certa vulnerabilidade?
Pois é, isso é mais conhecido como: “Business Logic Vulnerability” ou, traduzido ao pé da letra, vulnerabilidade na lógica de negócios.
Neste artigo, faremos uma breve introdução ao assunto. Acho bastante relevante falar sobre, devido a várias das falhas em grandes empresas resultarem da falha em manejar a lógica de negócios ou “Business Logic” delas.
O que é Business Logic?
Para ser direto ao ponto, é, basicamente, a lógica sobre qual determinada aplicação é construída.
A vulnerabilidade dela parte, a princípio, de resultados inesperados obtidos através de manipulações de recursos da aplicação vindas de um atacante.
Pra ficar mais simples de entender, um exemplo:
Supondo que uma aplicação tem um sistema de compras, mas, ao comprar um item, você consegue modificar o parâmetro de preço que o produto possui. Como ela está confiando demais no usuário que utiliza a mesma, ele (no caso, o atacante) consegue modificar e alterar esse valor através de uma exploração na confiança da aplicação.
No exemplo citado acima, podemos ver que não há nenhum tipo de vulnerabilidade técnica, em si, apenas uma modificação de parâmetros fornecidos pela aplicação que são mutáveis.
Prática
Beleza, agora que já entendemos a teoria, que tal levarmos a um pouco pra prática?
Pra começar, faremos um laboratório que está disponível na PortSwigger, fala sobre o exemplo citado anteriormente: “Excessive trust in client-side controls” / “Confiança excessiva nos controles do lado do cliente”.
O objetivo deste laboratório é comprar um item, seja de forma gratuita ou com desconto suficiente para conseguir comprar a menos de $100.
Primeiramente, faremos o login com as credenciais fornecidas (wiener:peter).
Quando autenticarmos, aparecerá que está disponível $100 para gastar na plataforma, porém, como o produto que temos que comprar custa $1337, teremos de achar alguma forma de obter ele a menos de $100.
Prosseguindo para adicionar o item para o carrinho, se interceptar a conexão, verá que o parâmetro “price” é mutável, é possível alterar o preço do produto para $1.00.
Após mudado, o parâmetro “price”, temos o produto por $1.00 ao invés de $1337.00!
Só comprar para resolver o lab.
Agora iremos para um segundo laboratório, com um pouco mais de trabalho, mas tranquilo da mesma forma que o primeiro.
Autenticaremos, como fizemos no primeiro. Neste segundo lab, temos a mesma quantidade ($100), porém a aplicação não utiliza o parâmetro price para modificar o preço, ou seja, nada de modificações diretas de preço por aqui :/
Quando adicionamos o item ao carrinho e tentamos removê-lo, é notado o seguinte comportamento estranho:
Ele está passando a quantidade de produtos a serem removidos através da lógica de: “-quantidade_em_numero_a ser_removido”. Se tentar alterar para -2, o preço também muda para “-$1337.00”.
Seguindo essa lógica, basta adicionarmos algum produto e alterar a quantidade negativa dele até chegar a um preço menor que $100.00, como é mostrado abaixo:
Desta forma, conseguimos comprar o item acima de $1000.00 com apenas $100.00 e finalizar outro laboratório!
Foi isso! Não teve tanta explicação, pelo fato de essa não ser uma vulnerabilidade tão estática, mas sim dinâmica, a qual diferencia de aplicação para aplicação. Então deixei mais laboratórios para demonstrar, que, ao meu ver, fica melhor para explicar tal tema.
Enfim, espero que tenha gostado e desejo um ótimo dia, uma ótima tarde e uma ótima noite!
Lembre-se, como Einstein dizia: “A imaginação é mais importante do que o conhecimento.”
Vlw, rapaziada, TMJJJ!!!
Referências
https://portswigger.net/web-security/logic-flaws
https://owasp.org/www-community/vulnerabilities/Business_logic_vulnerability
