# Gray Box #### **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: ``` https://alvo.com/api/v3/login ``` Devemos validar se o fluxo acontece normalmente caso seja passado outra versão, como exemplo: ``` https://alvo.com/api/v1/login ``` *** #### **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: ``` { "email":"pentest@pentest.com", "email":"pentest2@pentest.com" } ``` Requisição modificada: ``` { "email":["pentest@pentest.com","pentest2@pentest.com"] } ``` *** #### **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: ``` { "email":["pentest@pentest.com","pentest2@pentest.com"] } ``` Requisição modificada: ``` { "email":"pentest@pentest.com", "email":"pentest2@pentest.com" } ``` *** #### **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. --- # Agent Instructions: Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter: ``` GET https://handbook.vantico.com.br/metodologias/api/low-hanging-fruits/gray-box.md?ask= ``` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.