Para os não iniciados, um Decodificação de assinatura da Web JSON A operação parece trivial - um simples exercício de decodificação Base64URL para visualizar as reivindicações dentro de um token. Mas para engenheiros de segurança, testadores de penetração e pesquisadores de segurança de IA, a "decodificação" é apenas a fase de reconhecimento de um campo de batalha muito mais complexo.
Enquanto os desenvolvedores usam a decodificação para depurar fluxos de autenticação, os invasores a usam para fazer engenharia reversa da lógica de assinatura. A lacuna entre decodificação um token e verificação sua integridade é onde residem as vulnerabilidades de desvio de autenticação mais perigosas da história moderna da API.
Este artigo disseca a anatomia do JWS, analisa as falhas críticas de verificação, incluindo CVEs de alto impacto, e explora como a segurança orientada por IA - como os mecanismos que alimentam o Penligente-está mudando a forma como auditamos esses mecanismos criptográficos.
A anatomia de um JWS: Mais do que apenas Base64
Antes de analisar as explorações, devemos nos alinhar com a estrutura definida em RFC 7515. Uma assinatura da Web JSON (JWS) representa o conteúdo protegido por uma assinatura digital ou código de autenticação de mensagem (MAC).
Uma string JWS compacta consiste em três partes separadas por pontos (.):
Header.Payload.Signature
A lógica de decodificação
Quando você executa um decodificação de assinatura web jsonSe você estiver convertendo os dois primeiros segmentos do formato Base64URL de volta para JSON.
Aqui está uma implementação Python bruta para pesquisadores de segurança que preferem a CLI a ferramentas baseadas na Web que podem registrar tokens confidenciais:
Python
`import sys import json import base64
def padding_fix(data): missing_padding = len(data) % 4 if missing_padding: data += '=' * (4 - missing_padding) return data
def decode_jws(token): try: header_b64, payload_b64, signature_b64 = token.split('.')
header = json.loads(base64.urlsafe_b64decode(padding_fix(header_b64)))
payload = json.loads(base64.urlsafe_b64decode(padding_fix(payload_b64)))
return header, payload
exceto ValueError:
print("[-] Formato de token inválido")
sys.exit(1)
Contexto de uso
cabeçalho, carga útil = decode_jws(sys.argv[1])
print(json.dumps(header, indent=2))`
A saída de uma operação de decodificação normalmente revela os metadados que determinam como a verificação é feita. deve acontecer. Esses metadados são o principal alvo do invasor.
| Parâmetro do cabeçalho | Descrição | Implicações de segurança |
|---|---|---|
alg | Algoritmo (por exemplo, HS256, RS256) | Determina a primitiva de criptografia. Principal alvo de ataques de downgrade. |
tip | Tipo de token (por exemplo, JWT) | Geralmente ignorado, mas pode ser usado para confusão de tipos. |
garoto | ID da chave | Indica a tecla a ser usada. Pode ser manipulado para Travessia de diretório ou Injeção de SQL em casos raros. |
jku / x5u | URL da chave da Web JSON | Aponta para o URL da chave pública. Alvo para SSRF ou hospedagem de chaves maliciosas. |
A lacuna "Decodificar-Verificar": onde vivem as vulnerabilidades
O principal problema é que muitas bibliotecas e implementações personalizadas desacoplam o decodificar da etapa verificar etapa. Um aplicativo pode decodificar o cabeçalho para ler o alg e, em seguida, usar essa entrada controlada pelo usuário para decidir como verificar a assinatura.
1. O desvio do algoritmo "Nenhum"
Esse é o "Hello World" das explorações do JWS, mas ele persiste em sistemas legados. Se uma implementação de back-end depender do alg do token decodificado para determinar a lógica de verificação, um invasor pode modificar o token:
- Decodificar o cabeçalho.
- Mudança
algparanenhum(ouNenhum,NENHUM). - Retire a assinatura.
Se a biblioteca for compatível com nenhum (destinado à depuração) e não inclui algoritmos na lista de permissões, a verificação de assinatura é totalmente ignorada.
2. Confusão de algoritmos (Confusão de chaves)
Esse é um ataque mais sofisticado. Ocorre quando um servidor oferece suporte à assinatura simétrica (HMAC) e assimétrica (RSA/ECDSA), mas não consegue validar qual delas está sendo usada para uma chave específica.
- Cenário: O servidor espera um token RS256 (assinado com uma chave privada e verificado com uma chave pública).
- Ataque: O invasor executa um decodificação de assinatura web json, alterações
algparaHS256(HMAC), e assina o token usando o Chave pública como o segredo HMAC. - Resultado: Como a chave pública geralmente está disponível para o cliente (ou é facilmente acessível), o invasor pode forjar uma assinatura válida que o servidor verifica usando sua própria chave pública (tratando-a como um segredo HMAC).
Estudo de caso: CVE-2022-21449 ("Psychic Paper")
Embora a confusão de algoritmos seja uma falha lógica, algumas vulnerabilidades existem profundamente na própria implementação criptográfica.
CVE-2022-21449 (CVSS 7.5), apelidada de "Psychic Paper", afetou a implementação de assinaturas ECDSA do Java. Esse é um excelente exemplo de como a simples validação de que uma "assinatura existe" é insuficiente.
O Mecanismo
No ECDSA, a verificação envolve uma equação matemática: $v = R'$ (simplificado). A vulnerabilidade estava na função ECDSA implementação em que, se as partes da assinatura $r$ e $s$ fossem definidas como 0a lógica de verificação retornaria incorretamente verdadeiro para qualquer carga útil.
Um invasor pode:
- Decodificar um JWS legítimo.
- Modificar a carga útil (por exemplo,
{"admin": true}). - Construa uma assinatura em que $r=0$ e $s=0$.
- Envie-o para um backend baseado em Java (executando Java 15, 16, 17 ou 18).
O servidor verificaria a assinatura como válida, permitindo um desvio completo da autenticação. Isso destaca que mesmo as bibliotecas padrão e amplamente utilizadas não são imunes a falhas catastróficas.
Auditoria de JWS orientada por IA: A abordagem Penligent
A análise manual dos tokens JWS é eficaz para explorações individuais, mas as arquiteturas modernas de microsserviços geralmente empregam centenas de chaves diferentes, políticas de rotação e configurações de algoritmo. Um engenheiro humano não pode fazer manualmente decodificação de assinatura web json e testar todas as permutações de injeção de cabeçalho, confusão de chaves e desvios específicos de biblioteca em toda uma superfície de ataque.
É nesse ponto que os testes de penetração automatizados orientados por IA se tornam essenciais.
Penligente utiliza modelos avançados de linguagem grande (LLMs) e aprendizado por reforço para automatizar essa profundidade de teste. Diferentemente dos scanners tradicionais que usam regex estático para procurar cadeias de caracteres ruins conhecidas, o mecanismo da Penligent:
- Decodificação contextual: Ele intercepta o tráfego, decodifica os tokens JWS e entende o contexto (por exemplo, "Este token é usado para o gateway de pagamento, não apenas para login").
- Geração de carga útil adaptável: Ele não se limita a tentar
alg: nenhum. Ele analisa as respostas de erro do servidor para inferir a biblioteca de back-end. Se detectar um ambiente Java, ele pode tentar variações do CVE-2022-21449. Se ele virgarotoele procura por injeção de SQL ou injeção de comando via Key ID. - Análise de fluxo lógico: A Penligent pode identificar se um token é verificado corretamente em um endpoint, mas simplesmente decodificado e confiável sem verificação em um microsserviço secundário - uma falha arquitetônica comum.
Ao integrar a análise inteligente de JWS, a Penligent vai além da simples varredura de vulnerabilidades e entra no campo da equipe vermelha autônomagarantindo que as implementações criptográficas sejam robustas contra CVEs conhecidos e falhas lógicas de dia zero.
Diretrizes de endurecimento para engenheiros
Para proteger os aplicativos contra ataques de JWS, precisamos passar da "confiança implícita" para a "verificação explícita".
1. Aplicar a lista branca de algoritmos
Nunca confie no alg do token decodificado para determinar o método de verificação. Codifique o algoritmo esperado em seu verificador.
JavaScript
// Abordagem segura (biblioteca jose do Node.js) const verified = await jose.jwtVerify(token, secretKey, { algorithms: ['RS256'], // Lista de permissões explícita SOMENTE RS256 });
2. Validar o garoto (ID da chave) STRICTLY
Se sua configuração usar várias chaves (JWKS), verifique se a chave garoto corresponde a uma chave em sua lista de permissões. Não passe o cabeçalho garoto diretamente para uma consulta ao banco de dados ou chamada ao sistema de arquivos.
3. Use bibliotecas modernas
Evite escrever seus próprios wrappers de criptografia. Use bibliotecas testadas em batalha, como jose (Node.js), PyJWT (Python), ou jjwt (Java). No entanto, verifique se você está inscrito nos boletins de segurança dessas bibliotecas.
4. Separe a decodificação da verificação (logicamente)
Entenda que decodificação de assinatura web json é para exibição fins (UI, registro). Verificar é para autorização. Nunca use dados decodificados para lógica de negócios antes que a etapa de verificação retorne verdadeiro.
Conclusão
A capacidade de decodificação de assinatura web json é uma habilidade fundamental, mas é apenas a arranhadura da superfície. Para o engenheiro de segurança, o JSON bruto é um mapa de possíveis configurações incorretas. Do algoritmo clássico "Nenhum" a desvios matemáticos como o CVE-2022-21449, a integridade da Web depende de uma verificação rigorosa, não apenas de uma decodificação bem-sucedida.
À medida que a complexidade dos aplicativos aumenta, o uso de ferramentas baseadas em IA, como Penligente para automatizar a detecção dessas falhas criptográficas sutis está se tornando uma necessidade para uma postura de segurança empresarial robusta.
Referências:
