A categoria de Autorização de Nível de Propriedade de Objeto Quebrada combina ataques que ocorrem ao obter acesso não autorizado a informações sensíveis por meio de Exposição Excessiva de Dados (anteriormente listada como número 3 no OWASP API Security Top 10 de 2019) ou Atribuição em Massa (anteriormente em sexto lugar).
Ambas as técnicas baseiam-se na manipulação de endpoints de API para obter acesso a dados sensíveis.
Esta nova categoria trata da autorização em nível de propriedades de objeto, em oposição à autorização em nível de objeto (número 1 na lista desde 2019).
O principal motivo para a introdução desta nova ameaça na lista é que, mesmo que uma API consiga aplicar medidas de segurança de autorização em nível de objeto suficientes, isso pode ainda não ser o bastante para protegê-la. Frequentemente, é necessária uma autorização mais específica que cubra os objetos e suas características. Os diferentes níveis de acesso dentro de um objeto de API também devem ser levados em consideração, já que um objeto de API geralmente possui propriedades públicas e privadas.
Impacto Potencial da Autorização de Nível de Propriedade de Objeto Quebrada
As APIs frequentemente enviam mais informações do que o necessário em uma resposta de API e deixam a cargo da aplicação cliente filtrar os dados e renderizar uma visualização para o usuário. Um invasor pode interceptar o tráfego enviado ao cliente para obter acesso a dados potencialmente sensíveis, que podem incluir informações como números de conta, endereços de e-mail, números de telefone e tokens de acesso.
Além disso, um invasor que explora esse tipo de vulnerabilidade pode atualizar propriedades de objeto às quais não deveria ter acesso, permitindo-lhe escalar privilégios, adulterar dados e contornar mecanismos de segurança.
Como é um ataque de Autorização de Nível de Propriedade de Objeto Quebrada?
No exemplo acima, o código do lado do cliente em execução no navegador da web do usuário está enviando uma solicitação POST para uma API de backend para recuperar informações de pagamento armazenadas. Neste caso, a API está recuperando informações de cartão de crédito armazenadas, especificamente o número principal da conta (PAN) e o código de valor de verificação do cartão (CVV). No mundo do manuseio de cartões de crédito e processamento de pagamentos, esse tipo de dado é considerado sensível como parte do PCI-DSS e deve ser protegido adequadamente. O escopo do que é necessário para a proteção varia dependendo da exposição do ambiente de dados do titular do cartão, ou de onde os dados são armazenados, processados ou transmitidos.
Esse compartilhamento de dados sensíveis pode ser intencional como parte do design ou necessário para a funcionalidade. Como resultado, as organizações aumentam a segurança com controles adicionais, como autenticação mais forte ou transporte criptografado, para garantir que os dados estejam suficientemente protegidos. No exemplo, você pode ver cabeçalhos de segurança HTTP adicionais para ajudar a proteger os dados, como x-frame-options para mitigar ataques de cross-frame scripting e x-xss-protection para mitigar ataques de cross-site scripting. Algumas organizações também podem mascarar os dados retornados a um cliente para evitar casos em que alguém intercepte o tráfego ou visualize dados fora da aplicação cliente pretendida. Confiar no código do lado do cliente para filtrar ou ocultar tais dados sensíveis geralmente não é apropriado, uma vez que os invasores contornam regularmente o código de aplicações web e móveis do lado do cliente e chamam as APIs diretamente.
No segundo exemplo acima, o invasor alterou a chamada da API para atualizar sua conta, escalar sua função e privilégios para uma função de "administrador" e contornar o single sign-on (SSO). Se bem-sucedido, o invasor pode então realizar ações dentro da aplicação como um administrador.
Exemplo do mundo real: usuários do Twitter têm seus dados comprometidos
De acordo com um comunicado divulgado pelo Twitter em agosto de 2022, uma vulnerabilidade de autorização de nível de propriedade de objeto quebrada foi inicialmente detectada pelo programa de recompensa por bugs da empresa em janeiro de 2022. Como resultado da falha, se alguém enviasse um endereço de e-mail ou número de telefone para os sistemas do Twitter, a pessoa seria informada sobre qual conta do Twitter estava associada aos dados enviados, caso houvesse alguma. O problema foi investigado e corrigido pelo Twitter na época, sem evidências de que tivesse sido explorado em ambiente real. No entanto, em julho de 2022, veio à tona que um agente mal-intencionado havia aproveitado a falha antes de ela ser corrigida pela empresa e estava oferecendo os dados compilados para venda.
Este incidente de grande repercussão pública evidenciou o risco que esse tipo de vulnerabilidade de segurança pode representar, mesmo para uma marca consolidada com vastos recursos e programas de segurança supostamente robustos.
Por que as ferramentas existentes não protegem você contra vulnerabilidades de autorização de nível de propriedade de objeto
Controles de segurança tradicionais, como WAFs e gateways de API não possuem contexto sobre a atividade da API e a lógica de negócios e, portanto, não conseguem identificar dados confidenciais sendo enviados por meio de uma API ou compreender o risco de exposição desses dados. Eles também não conseguem saber se o chamador da API no exemplo acima deveria ter permissão para enviar uma solicitação usando o método PUT com parâmetros adicionais, falhando em diferenciar uma chamada legítima de uma atividade maliciosa. Para esses controles tradicionais, essa chamada de API parece normal. Na melhor das hipóteses, um WAF ou gateway de API pode oferecer mecanismos básicos de filtragem de mensagens para bloquear esse tipo de solicitação por completo. No entanto, parâmetros adicionais podem ser necessários para outros usuários e outros casos de uso. Isso também exigiria conhecimento detalhado e prévio das equipes de desenvolvimento sobre o design e o uso pretendido da API para que as equipes operacionais pudessem implementar até mesmo filtros de mensagens básicos.
Normalmente, gateways de API e WAFs empregam correspondência de padrões básica e filtragem de mensagens para identificar tipos de dados confidenciais, também conhecidos como padrões de expressão regular (regex). Embora esses tipos de filtros possam detectar tipos de dados confidenciais bem definidos, como números de cartão de crédito (PANs) ou números de previdência social (SSNs), eles não compreendem o contexto da API e os fluxos de lógica de negócios. Eles sinalizarão qualquer dado que corresponda ao padrão, independentemente de ser necessário bloquear a solicitação, criptografar cargas úteis ou ocultar dados. Gateways de API são frequentemente usados para mediar chamadas de API que contêm dados confidenciais, e isso pode ser necessário como parte de uma arquitetura corporativa, design de aplicação ou integração de sistemas abrangente. Bloquear ou mascarar dados confidenciais por completo frequentemente interrompe a funcionalidade, deixando as equipes de segurança relutantes em usar esses recursos de forma agressiva em proxies, preferindo confiar na camada de API/aplicação para controlar a exposição.
Como proteger suas APIs contra a vulnerabilidade de autorização de nível de propriedade de objeto
Uma solução de segurança de API deve ser capaz de identificar e relatar a grande variedade de tipos de dados confidenciais que podem ser enviados em solicitações e respostas de API, bem como qualquer atividade anômala em que invasores enviem solicitações de API manipuladas com parâmetros não autorizados.
Essas soluções também devem ser capazes de estabelecer uma linha de base e rastrear o acesso à API por endpoint e por usuário, a fim de identificar o consumo excessivo de dados confidenciais e detectar instâncias em que parâmetros adicionais são passados em chamadas de API que fogem do comportamento típico. As soluções de segurança de API também devem ser capazes de identificar invasores enquanto eles sondam a API durante a fase de reconhecimento para obter uma compreensão da estrutura e da lógica de negócios da API.
Para saber mais sobre como a Salt pode ajudar a defender sua organização contra riscos de API, você pode entrar em contato com um representante ou agendar uma demonstração personalizada.