Os perigos do JWT que nunca expira: vulnerabilidades ocultas de segurança

Os tokens da Web JSON (JWTs) se tornaram o método preferido de autenticação de muitas organizações. Eles são fáceis de implementar, o que os torna uma opção popular para proteger APIs e aplicativos da Web. No entanto, se não forem gerenciados adequadamente, os JWTs podem introduzir vulnerabilidades de segurança, colocando seus sistemas em risco. Você provavelmente já os utilizou.

Mas você os implementou e lidou com eles de forma segura?

Uma postagem no blog da Akamai destacou várias vulnerabilidades de segurança comuns associadas aos JWTs. Foi um alerta para os riscos potenciais do gerenciamento inadequado de seus JWTs. Nesta postagem do blog, quero me basear nisso, concentrando-me em uma vulnerabilidade adicional que geralmente é ignorada: JWTs que não expiram. Veremos como esse problema surge, juntamente com as vulnerabilidades de segurança associadas. Em seguida, oferecerei algumas orientações para que você saiba como se proteger dessas vulnerabilidades de segurança.

Visão geral das vulnerabilidades comuns do JWT

Antes de nos aprofundarmos, vamos analisar brevemente as vulnerabilidades do JWT destacadas na publicação do blog que mencionei acima. As seis ameaças aos JWTs que o autor mencionou foram:

1. Permitir que o servidor use um token sem validação: Isso pode acontecer quando o servidor não verifica a integridade do token, facilitando a manipulação e a exploração por parte dos invasores. Os invasores também podem definir o algoritmo de verificação (alg) como nenhum, tentando manipular o servidor para que ele não valide o token.
2. Usar a mesma chave privada para diferentes aplicativos: Essa prática pode comprometer vários aplicativos se a chave for exposta.
3. Uso de um algoritmo de assinatura fraco: Algoritmos de assinatura fracos podem ser quebrados mais facilmente, levando a um acesso não autorizado.
4. Escolha de uma chave privada curta e/ou de baixa entropia: As chaves que são muito curtas ou não têm aleatoriedade são mais suscetíveis a ataques de força bruta.
5. Manter dados confidenciais na carga útil de um JWT: As informações confidenciais armazenadas na carga útil podem ser expostas se o token for interceptado.
6. Confundir as chaves: O mau gerenciamento das chaves pode levar a uma validação incorreta, permitindo o acesso não autorizado.

Para obter informações detalhadas sobre essas vulnerabilidades, consulte a publicação no blog. Continuando, vamos dar uma olhada em outra vulnerabilidade: o JWT que não expira.

Vulnerabilidade adicional: JWTs que não expiram

Vamos dar uma olhada no JWT a seguir, que se baseia em um exemplo do mundo real que encontrei há pouco tempo:

Esse é um JWT usado para autenticar e autorizar o acesso de um usuário a uma API. Ele é assinado com um segredo seguro para evitar falsificação. À primeira vista, parece bom. Mas vamos dar uma olhada mais de perto na carga útil:

Quando você olha para essa reivindicação ttl, provavelmente pensa em tempo de vida, porque é isso que o TTL normalmente representa. Portanto, isso provavelmente tem a ver com o tempo de validade do JWT. Esse deve ser o tempo de expiração.

Podemos fazer alguns cálculos simples aqui. Talvez 86.400.000 seja o número de segundos e, nesse caso, o emissor pretende que esse JWT seja válido por 1.000 dias. Ou talvez eles estejam se referindo a milissegundos e, nesse caso, pretendem que esse JWT seja válido por 1 dia. Isso também pode fazer sentido.

Mas aqui está o problema: a especificação do JWT diz que o tempo de expiração é especificado como exp, não ttl:

Portanto, temos alguns problemas aqui.

Primeiro, o emissor desse JWT está usando ttl para especificar a expiração, mas ttl não é uma reivindicação padrão do JWT. A maioria das bibliotecas projetadas para lidar com JWTs não reconhecerá ttl como uma instrução relacionada à expiração do token. Isso levará a problemas de compatibilidade, e o token provavelmente será tratado como não expirante.

Em segundo lugar, a reivindicação exp exige um registro de data e hora real de expiração, não um número relativo de milissegundos (ou segundos) a partir da hora de emissão. Essa confusão provavelmente decorre do uso de ttl em vez de exp. No entanto, o emissor precisa entender o formato esperado para a reivindicação exp para garantir a expiração adequada do token.

Se você deixar de definir o tempo de expiração de um JWT ou defini-lo incorretamente (como no nosso exemplo), seu JWT será tratado como não expirado. E isso representa uma falha de segurança significativa.  

Mitigando as vulnerabilidades de segurança do JWT

Agora que cobrimos as possíveis vulnerabilidades de segurança, a pergunta seguinte é: o que você deve fazer a respeito? Felizmente, a atenuação dessa vulnerabilidade é simples e direta!

Sempre use a reivindicação de expiração. Defina um tempo de expiração em cada token que você gerar. Ao fazer isso, certifique-se de usar a declaração exp padrão com o formato de valor esperado para garantir que ela esteja em conformidade com as especificações do JWT e expire como pretendido.

Atualize aplicativos e bibliotecas. Certifique-se de que seu aplicativo e as bibliotecas que você usa estejam atualizados e sigam os padrões JWT mais recentes. As atualizações regulares ajudam a corrigir vulnerabilidades de segurança e a melhorar a compatibilidade.

É isso aí. Siga essas diretrizes simples e você reduzirá significativamente o risco de acesso não autorizado por meio de um JWT que não expira. Isso aumentará a segurança geral de suas implementações de JWT.

Conclusão

Compreender e solucionar as vulnerabilidades do JWT é fundamental para manter a segurança de seus aplicativos. Nesta postagem, destacamos o risco de tokens que não expiram. Ao usar a reivindicação de expiração corretamente e manter suas bibliotecas atualizadas, você pode atenuar esse risco de forma eficaz.

Para obter mais soluções de segurança e práticas recomendadas, explore os recursos disponíveis na documentação da Linode. A Linode oferece guias abrangentes para ajudá-lo a remover as vulnerabilidades de segurança de seus aplicativos.