Low Hanging Fruits
Uso de mesma chave de API em ambientes de produção e homologação
O uso da mesma chave de API em ambientes de produção e homologação é uma prática de segurança inadequada e pode levar a sérios riscos. Esse erro pode expor dados sensíveis, permitir acesso não autorizado e comprometer a integridade dos sistemas.
Se a chave de API usada em homologação for comprometida, o atacante pode obter acesso ao ambiente de produção, onde dados sensíveis estão armazenados.
Força bruta na assinatura JWT
Caso a aplicação possua tokens JWT, o mesmo deve ser copiado e enviado para tentar quebrá-lo, a fim de obter o valor do secret e assim poder forjar tokens.
Para quebrar podemos utilizar o hashcat, seguindo o formato a seguir.
hashcat -a 0 -m 16500 token.txt wordlist.txt
JWT contendo informações PII
Deve ser decodificado o JWT e inspecionado ele, caso haja informações como nome, dados pessoais, e-mail ou qualquer outro dado PII, é validado a vulnerabilidade.
Verificações no JWT
Verificar o que há dentro do token JWT, deve ser reportado caso o token apresente: Criptografia fraca ou dados pessoais e informações sensíveis.
Ausência de cabeçalho
Toda vulnerabilidade que envolve a ausência de cabeçalhos ("header") deve ser adicionada separadamente para cada cabeçalho ausente presente no escopo.
Por padrão, APIs devem conter o cabeçalho, HTTP Strict Transport Security e Content-Security-Policy implementados.
Uso de cabeçalho depreciado
Verificar se a aplicação apresenta cabeçalhos depreciados, como X-Frame-Options, X-XSS-Protection ou Feature-Policy.
Essa validação pode ser feita em conjunto com a identificação da ausência de cabeçalhos.
Ausência de mecanismo contra força bruta
Essa vulnerabilidade deve ser testada em diferentes campos, como login, redefinição de senha e MFA.
Login: Deve ser testado se há algum controle anti automação ao inserir o mesmo e-mail porém com diversas senhas em um curto período de tempo.
Redefinição de senha: Verificar se possui algum mecanismo ao inserir diversos e-mails no campo.
MFA: Validar se pode ser realizado ataques de força bruta no campo de código do MFA a fim de descobrir a combinação certa para realizar o bypass do mecanismo.
Enumeração de usuários
Ocorre geralmente na área de login, cadastro ou esqueci a senha, em que quando digitamos algum usuário e senha, a aplicação nos retorna que o usuário já existe, ou que o email não está cadastrado, fazendo com que o atacante consiga enumerar quais usuários/emails são válidos ou não.
Porém o mesmo pode ser encontrado em outras partes da aplicação, como por exemplo alguma aba de alterar o e-mail do usuário dentro da plataforma, pode haver de constar que o e-mail já está cadastrado.
A mensagem correta que a aplicação deve retornar é de "Usuário ou Senha Incorretos" ou "Caso o email já estiver cadastrado você receberá um link na sua caixa de email"
A enumeração também pode ser identificada via time-based, ou seja, por tempo de resposta, ocorre quando o tempo de resposta quando inserido um usuário válido e inválido são muito diferentes.
Flood de email no campo de redefinição de senha
Para realizar o teste dessa vulnerabilidade, devemos: entrar na aba esqueci minha senha, depois inserir o e-mail e interceptar o request quando apertado o botão de enviar, assim com este request, jogamos no repeater e ficamos enviando a mesma requisição diversas vezes, caso todas foram aceitas, irá gerar um flood de e-mails na caixa de entrada do usuário.
Ausência de WAF
Identificar se a aplicação possui algum mecanismo de WAF presente.
Acesso via IP diretamente
Ao identificar o endereço IP da aplicação, realize uma requisição com o endereço IP, caso a aplicação não faça o redirecionamento para o endereço DNS a mesma se encontra vulnerável a alguns ataques como bypass de WAF.
Alterar tokens
Validar se o token com privilégios menores pode executar ações administrativas.
Mensagem de erros
Quando a aplicação retorna um erro inesperado assim que um evento acontece, conforme o retorno que a aplicação der em relação ao erro, o atacante pode entender melhor como funciona a estrutura da aplicação, podendo aproveitar-se de alguma vulnerabilidade que pode ser exposta com o erro.
Trocar versões
Em alguns endpoints da API, vai ser passado da seguinte forma como exemplo:
Devemos validar se o fluxo acontece normalmente caso seja passado outra versão, como exemplo:
Requisições com métodos alterados
Neste caso, devemos verificar o retorno da aplicação ao passar outros métodos, como em um endpoint que originalmente aceita GET, enviar DELETE.
Falta de e-mail de verificação no processo de registro
Validar se durante o processo de registro, é enviado algum e-mail de verificação ao e-mail cadastrado.
Passar IDs numéricos em campos no formato UUID
Ao identificar alguma rota que é enviado um UUID, validar o retorno ao ser enviado um ID.
Passar wildcard no lugar de ID
Em rotas que é enviado um ID, fazer o envio de wildcards (*, %, _, .) no lugar para validar a resposta.
Passar array em campos
Em campos que são enviados JSON ou outro formato, validar o retorno ao enviar no formato de array, como no exemplo a seguir.
Requisição original:
Requisição modificada:
Passar JSON em campos
Neste caso vamos passar em formato de JSON em algum campo com o formato diferente, como demonstrado a seguir.
Requisição original:
Requisição modificada:
Uso de Basic Auth
Validar se o método de autenticação / autorização são feitos via Basic Auth (depreciado).
CORS Misconfiguration
Fazer verificações no CORS para validar se o mesmo está muito permissivo e se encontra vulnerável a ataques.
Token de sessão passado via GET
Verificar se em alguma requisição o token de sessão é enviado via GET, ou seja, junto com a URL.
Cookie de sessão sem a flag Secure habilitada
Verificar se o cookie de sessão possui a flag Secure.
Cookie de sessão sem a flag HttpOnly habilitada
Verificar se o cookie de sessão possui a flag HttpOnly.
Atualizado
Isto foi útil?