Conhecendo o Unrestricted Resource Consumption
A vulnerabilidade Unrestricted Resource Consumption foi adicionada no OWASP API TOP 10 2023 RC. Essa vulnerabilidade substitui a Lack of Resources & Rate Limiting do OWASP API TOP 10 2019.
O que é Unrestricted Resource Consumption?
Essa vulnerabilidade engloba qualquer consumo de recursos irrestrito que tenha em sua API, como exemplo: upload de arquivo sem restrição de tamanho. Um cenário comum é, APIs sem rate limiting, permitindo o usuário enviar requisições infinitas, assim obtendo recursos infinitos dentro de uma aplicação, ou até mesmo enumerando credenciais de autenticação.
Uma API é vulnerável se pelo menos um dos seguintes limites estiver ausente ou definido de forma inadequada:
- Tempo limite de execução
- Memória máxima alocável
- Número máximo de descritores de arquivo
- Número máximo de processos
- Tamanho máximo do arquivo de upload
- Número de operações a serem executadas em uma única solicitação de cliente de API (por exemplo, lote GraphQL)
- Número de registros por página a serem retornados em uma única solicitação-resposta
- Limite de gastos de provedores de serviços terceirizados
Cenários em que Unrestricted Resource Consumption pode prejudicar uma API
Cenário 1
Imagine que em uma API tenha o seguinte endpoint:
POST /api/v1/images/upload
data...Esse endpoint recebe uma imagem para upload. O que aconteceria se a API não tivesse um limite de upload definido? Um atacante poderia fazer um DoS enviando uma imagem extremamente grande, assim ocupando grande parte do espaço de armazenamento do servidor. Outro possível vetor de ataque é a falta do rate limit na API, pois se ela controlar o tamanho da imagem mas não controlar o limite de requisições feitas durante certo tempo, um atacante pode enviar milhares de imagens para o servidor, assim ocupando muito espaço no armazenamento do servidor.
Cenário 2
Um outro cenário vulnerável a Unrestricted Resource Consumption é aquele que define o limite de operações em uma única requisição, como exemplo o GraphQL aceitar diversas querys utilizando a mesma mutation em uma única requisição:
POST /graphql
[
"query": "mutation {
activateEmail(
email: \"[email protected]\",
code: \"0000\"
)
}"
},
"query": "mutation {
activateEmail(
email: \"[email protected]\",
code: \"0001\"
)
}"
},
...
"query": "mutation {
activateEmail(
email: \"[email protected]\",
code: \"9999\"
)
}"
}
]Veja que podemos especificar diversas querys utilizando a mesma mutation em uma única requisição, assim possibilitando um brute force. No exemplo acima, enviamos diversas querys contendo o mesmo email para ativação e especificando códigos diferentes (de 0000 até 9999), assim um dos códigos estará correto e nossa conta será ativada. Isso é uma ótima forma de bypass em uma API que tenha rate limiting, pois estamos fazendo o brute force em apenas uma requisição.
Como prevenir nossas APIs contra Unrestricted Resource Consumption?
Para nos prevenirmos contra esse ataque, devemos utilizar soluções para permitir uma quantidade de requisições por determinado período, devemos definir limites para que nossa API não sofra DoS, e se possível utilizar containers para balanceamento de carga, assim protegendo contra ataques que sobrecarreguem os processos do servidor.
Referências
OWASP
Guest Author
Onde praticar Hacking ?
O Hacking Club é uma plataforma de treinamento em cybersecurity, que permite você aprender hacking de forma totalmente prática.
Temos mais de 50 ambientes com vulnerabilidades reais com write-ups para você treinar e aprender hacking. Semanalmente lançamos máquinas gratuitas para você praticar e se desafiar no hacking!