CatSuite
JWT e evidências no CatSuite: análise de API com contexto
Leia claims sem confundir decodificação e verificação. Relacione tokens às requests, classifique resultados e compartilhe evidências com cuidado.
Decodificar um JWT no CatSuite permite ler header e claims; isso não verifica a assinatura nem comprova uma falha de autenticação. Para uma análise útil, conecte o token ao contexto da request, à política esperada da API e à response observada. Guarde credenciais com cuidado e separe observação, hipótese e confirmação no relatório.
Guia publicado em 6 de outubro de 2026. A capa é uma ilustração conceitual original, não uma captura do aplicativo nem evidência de teste.
Este guia explica como usar Decodificar, Repetir e os achados das extensões para investigar identidade e organizar evidências no Android. Consulte a visão geral do CatSuite e o guia do módulo Decodificar para as operações disponíveis.
O que você está lendo em um token
Um JWT assinado no formato compacto JWS costuma apresentar três segmentos separados por ponto: header, payload e assinatura. Header e payload são codificados em Base64URL. Essa codificação permite representar bytes como texto e não mantém os dados secretos por si só. Um JWE tem outro formato e contém conteúdo criptografado, que não pode ser tratado como um payload JWS legível.
A RFC 7519 define o JWT e suas claims. O objetivo da inspeção inicial é entender o que foi declarado, sem assumir que o servidor confia nesses valores ou que a ferramenta já validou a assinatura.
Claims que ajudam a orientar a investigação
| Campo | Pergunta útil | Cuidado na interpretação |
|---|---|---|
| alg | Qual algoritmo está declarado no header? | Declaração não prova o algoritmo efetivamente aceito pelo servidor |
| iss | Quem declara ter emitido o token? | Precisa ser validado na política do destinatário |
| aud | Para qual destinatário ele foi emitido? | APIs diferentes podem ter audiências diferentes |
| sub | Qual identidade é representada? | Pode não ser um ID público de usuário |
| exp | Qual validade foi declarada? | Precisa ser aplicada pelo servidor |
| nbf | A partir de quando ele deve ser aceito? | Verificar relógio e tolerância definida |
| jti | Existe identidade própria do token? | Sua presença não comprova revogação |
Claims específicas, como papel ou organização, dependem do contrato da aplicação. Um campo role legível não demonstra que a API autoriza ações diretamente a partir dele. Pode haver uma política independente no servidor.
Use dados fictícios para aprender o formato
Este header e payload são apenas um exemplo didático. Não acompanham uma assinatura válida, não representam uma sessão real e não devem ser usados como credencial. O valor de exp é ilustrativo e pode estar expirado quando o guia for consultado.
{"alg":"RS256","typ":"JWT"}{
"iss": "https://auth.aurora.test",
"aud": "aurora-lab",
"sub": "cliente-ficticio-001",
"exp": 1791324000,
"role": "cliente"
}No CatSuite, abra Decodificar ou encaminhe um valor a partir da mensagem capturada. Escolha o formato adequado e confira se os segmentos estão completos. Preserve a request original de forma privada para não perder o contexto. Alterar o payload no editor não atualiza a assinatura com a chave do emissor.
Decodificação, verificação e aceitação são etapas diferentes
| Etapa | O que demonstra | O que ainda falta |
|---|---|---|
| Decodificar | O conteúdo representado pelos segmentos legíveis | Integridade e política de aceitação |
| Verificar assinatura | Integridade perante uma chave e algoritmo aceitos | Emissor, audiência, tempo e regras do destinatário |
| Observar aceitação na API | O comportamento daquela request e daquele contexto | Interpretar se o acesso era permitido e qual foi o impacto |
Um token pode ter assinatura válida e não servir para aquela API, por exemplo por audiência incorreta ou expiração. Também pode ser aceito para autenticação, mas não autorizar um objeto específico. A análise deve separar identidade, autorização e regra de negócio.
Para testes de acesso entre contas, use objetos e usuários preparados no ambiente de laboratório. O guia do Repetir apresenta uma matriz pequena para investigar autorização por objeto sem transformar a presença de um ID em conclusão de BOLA.
Não envie tokens a serviços de decodificação sem necessidade
Um bearer token pode conceder acesso a quem o possui. Copiá-lo para um site, issue ou ferramenta externa pode expor uma sessão. A análise local reduz esse compartilhamento, mas não torna screenshots, clipboard e arquivos exportados automaticamente inofensivos.
Guarde apenas o contexto necessário no relatório. Mostre o tipo de credencial e os campos relevantes, ocultando o valor operacional. Mesmo partes do token podem revelar identidade, organização ou dados pessoais. Um hash pode ajudar a relacionar evidências sem publicar o segredo, desde que o processo de coleta e a finalidade estejam claros.
Do candidato a segredo ao achado comprovado
Uma string com aparência de chave é um candidato, não uma credencial validada. Ela pode ser exemplo, material público, valor revogado ou identificador sem poder de autenticação. Registre onde apareceu e por que merece revisão. Não valide uma chave em um serviço externo fora do escopo.
| Classificação | Evidência adequada | Exemplo de texto |
|---|---|---|
| Observado | Conteúdo presente na captura | Header Authorization presente na request de laboratório |
| Hipótese | Sinal que exige teste adicional | Identificador de objeto controlável pelo cliente |
| Confirmado | Comportamento indevido reproduzido e impacto definido | Conta A recebeu os dados preparados para a conta B |
| Limitação | Parte da análise não realizada | Assinatura JWT não verificada e body truncado |
O CatSuite permite registrar achados com severidade, confiança, estado e evidências. Escolha a severidade a partir do impacto demonstrado. Não promova toda observação para alto risco apenas para destacar o relatório. O contrato de achados e dados apresenta os campos e a consolidação por fingerprint.
Uma ficha de evidência que permanece útil
Objetivo: verificar autorização de leitura entre contas de laboratório
Ambiente: Aurora, homologação isolada
Conta utilizada: ana-lab
Objeto solicitado: pedido-202, preparado para bruno-lab
Alteração: somente o identificador do pedido
Request: referência privada da mensagem efetivamente enviada
Response: status, tipo de conteúdo e campos relevantes
Observação: descrever apenas o conteúdo realmente recebido
Conclusão: confirmado, hipótese ou inconclusivo, conforme o resultado
Limitações: relógio, truncamento, captura parcial ou condição não testada
Versões: aplicativo, extensão e revisão do fluxo quando aplicáveisA ficha acima é um modelo de registro, não um resultado já encontrado. Preencha os campos com a observação real. Se o resultado for inconclusivo, explique qual verificação falta. Isso é mais útil para uma equipe de desenvolvimento do que uma afirmação genérica de que o endpoint parece inseguro.
Proteção, exportação e backup têm finalidades distintas
O cofre e os níveis de proteção ajudam a controlar o acesso ao material no aplicativo. Uma exportação de dados selecionados prepara informação para compartilhar; um backup portátil preserva conteúdo para recuperação. O backup pode conter material completo e precisa de proteção e guarda apropriadas.
Credenciais operacionais e pareamentos não devem ser publicados junto dos exemplos. Revise o conteúdo selecionado e confira a opção de evidências com dados sensíveis ocultados. Leia o guia de segurança, cofre e backups antes de escolher o formato e o destino do arquivo.
Se uma chave biométrica deixar de ser utilizável, a recuperação depende dos backups previstos no sistema. Teste seu procedimento com dados fictícios antes de depender dele para material importante. Proteção de acesso e capacidade de recuperação precisam ser planejadas juntas.
Como extensões ajudam sem exagerar a conclusão
O modelo de auditoria de identidade organiza etapas de JWT, candidatos a segredos e autorização. Ele ajuda a reunir sinais e contexto. Claims decodificadas continuam sem comprovação de assinatura; um identificador numérico continua hipótese de autorização até que um teste adequado demonstre o comportamento.
Você pode criar uma extensão com uma regra pequena e revisável, como a observação de cache apresentada no tutorial de plugins JavaScript. Depois conecte etapas usando fluxos visuais, preservando a origem dos dados e os limites de compartilhamento.
Perguntas frequentes sobre JWT no Android
Um JWT legível significa que está sem proteção?
Não necessariamente. Em JWS, o conteúdo é legível por projeto; a assinatura trata da integridade. Dados que exigem sigilo não devem depender apenas de Base64URL para proteção.
Encontrar role=admin confirma acesso administrativo?
Não. É um valor declarado. A confirmação depende da política e do comportamento do servidor com uma request adequada ao teste autorizado.
O relatório deve incluir o token inteiro?
Em geral, compartilhe uma representação ocultada e mantenha o original em evidência privada controlada quando necessário. Explicite a relação entre as duas versões e preserve apenas o que a finalidade do teste exige.
Próximo passo: uma análise com contexto
Instale o CatSuite, capture uma chamada do seu laboratório e conecte a leitura do token à comparação no Repetir. Para ampliar a rotina, consulte os guias de variações HTTP e documentação oficial. A meta é produzir uma conclusão que outra pessoa consiga reproduzir, com exposição mínima de dados.
