Ferramentas de desenvolvedor · Decodificador JWT
O ataque alg:none e a confusão de chaves: por que os verificadores devem fixar algoritmos
· Por que é importante
jwt segurança criptografia
Se um verificador permitir que o token escolha seu próprio algoritmo, um invasor poderá escolher nenhum ou trocar RSA por HMAC. Esta postagem explica os ataques e a regra que os impede.
O token que se auto-verificou — como um campo de cabeçalho se tornou uma superfície de ataque
Um rótulo de algoritmo fica dentro da entrada do token controlada pelo invasor. Se um verificador tratar esse rótulo como permissão para selecionar qualquer modo de validação disponível, o token começa a influenciar a regra usada para julgar a si mesmo. ToolAcre expõe o rótulo precisamente para que os revisores possam vê-lo, mas nunca age criptograficamente.
A direção segura é a inversa: a configuração do serviço confiável define famílias de algoritmos aceitáveis e chaves associadas, então os cabeçalhos recebidos devem corresponder a essa política. Um painel de decodificação não pode fornecer essa política e não deve ser confundido com proteção simplesmente porque destaca um valor suspeito.
O repositório sinaliza alg:none, mas não estabelece o histórico de especificações por trás de JWTs inseguros
A implementação trata `alg: none` como uma declaração não assinada e avisa que aceitá-la aceitaria conteúdo arbitrário. Também relata um terceiro segmento vazio separadamente. A evidência do repositório suporta a rejeição de tais entradas em fluxos de trabalho autenticados; ele não documenta por que JWTs inseguros foram originalmente incluídos em uma especificação.
Essa formulação histórica é, portanto, corrigida e não inventada. O que importa operacionalmente é claro: um serviço que espera credenciais assinadas não deve permitir que um cabeçalho de token desative a verificação de assinatura. O próprio ToolAcre não realiza verificação, portanto, sua capacidade de exibir `none` é detecção apenas para inspeção.
O ataque alg:none – removendo a assinatura e pedindo ao verificador para aceitar uma vazia
Um ataque não assinado altera o cabeçalho para solicitar `none`, altera as declarações se desejado e não fornece bytes de assinatura. Cada segmento ainda pode ser sintaticamente válido e os dois primeiros são decodificados em JSON polido. Um verificador permissivo converteria a preferência do invasor em um desvio de autenticação.
Um verificador estrito não possui ramificação que atualize essa entrada para o status confiável quando tokens assinados são necessários. O aviso de ToolAcre ajuda a identificar a forma durante a depuração, mas a leitura da palavra `none` não impede que um back-end tome uma decisão errada. A aplicação pertence ao local onde a credencial é consumida.
Confusão de chaves — apresentar uma chave pública como um segredo HMAC para que os tokens RS256 sejam verificados como HS256
A confusão de chaves surge quando um verificador permite famílias de algoritmos com funções de chave incompatíveis e não consegue vincular cada escolha ao tipo de chave correto. Uma chave de verificação pública RSA não é um segredo HMAC. Tratar seus bytes como um após um invasor alterar um rótulo de algoritmo colapsa a separação public/private pretendida.
Prevenir esse tipo de erro requer mais do que verificar um segmento em formato de assinatura. O serviço deve emparelhar algoritmo esperado, tipo de chave, emissor e perfil de token por meio de configuração confiável. Um decodificador que mostra RS256 ou HS256 não pode dizer se o back-end mantém essas ligações.
A correção – fixe os algoritmos aceitos no verificador e nunca os derive do token
Fixe algoritmos aceitos na configuração do verificador e mantenha a lista tão restrita quanto o contrato do emissor permitir. Rejeite `none` para fluxos de credenciais assinadas e rejeite incompatibilidades em vez de tentar outro algoritmo. Não derive a lista de permissões do cabeçalho não verificado ou de uma declaração de carga útil.
A pesquisa de chave segue o mesmo princípio. Um `kid` pode selecionar entre candidatos já confiáveis, mas não deve criar uma nova fonte confiável. URLs de cabeçalho ou chaves incorporadas não devem ser seguidas apenas porque o token as solicita. O verificador decide suas fontes de forma independente.
Exemplo resolvido - lendo um cabeçalho no decodificador ToolAcre JWT para detectar alg:none e por que detectá-lo não é o mesmo que estar protegido
Crie um cabeçalho de token inofensivo declarando `none` e deixe o terceiro segmento vazio. ToolAcre decodifica o JSON, relata o algoritmo declarado, avisa que não está assinado e anota a assinatura ausente. Este é exatamente o comportamento esperado de uma ferramenta de inspeção.
O exercício não prova que um API rejeite o token. Confirme isso separadamente com um teste negativo controlado em relação ao verificador e configuração reais. Se API aceitar, a correção pertence a esse limite de verificação; adicionar um aviso mais alto a um decodificador não protegeria as solicitações.
O que isso não cobre — as muitas correções específicas da biblioteca; consulte RFC 8725 e o changelog da sua biblioteca
As APIs da biblioteca, os padrões e as correções históricas variam de acordo com o produto e a versão. Este módulo não estabelece qual nome de opção fixa algoritmos em sua pilha, e este artigo não inventa nenhum intencionalmente. Leia a documentação atual e o changelog da biblioteca selecionada e, em seguida, exercite os casos de rejeição em seu próprio conjunto de testes.
Teste também tipos de chave errados, valores `kid` desconhecidos, assinaturas ausentes e perfis de token inesperados. O objetivo é mostrar que a configuração vence as sugestões de tokens. Uma decodificação bem-sucedida não pertence a nenhuma dessas afirmações de aceitação porque o sucesso da sintaxe é compatível com todos os exemplos maliciosos.
Conclusão: o verificador decide, não o token – um decodificador ajuda você a ver o cabeçalho, mas apenas a verificação fixada protege você
O verificador decide; o token não. ToolAcre pode revelar um cabeçalho que diz `none`, um algoritmo desconhecido ou um identificador de chave surpreendente. Essa visibilidade ajuda na triagem, mas apenas a política de algoritmo fixada e as chaves confiáveis vinculadas corretamente impedem a aceitação.
Nunca recomende ativar `none`, escolher uma chave de verificação de um cabeçalho não confiável ou tratar um comprimento de assinatura exibido como validação. Decodifique para inspeção e, em seguida, comprove o comportamento de rejeição e aceitação no limite criptográfico real com testes controlados.