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

Os JSON web tokens (JWTs) tornaram-se o método preferido de autenticação de muitas organizações. São fáceis de implementar, o que os torna uma escolha popular para proteger APIs e aplicações Web. No entanto, se não forem geridos corretamente, os JWTs podem introduzir vulnerabilidades de segurança, colocando os seus sistemas em risco. Provavelmente já os utilizou.

Mas será que as implementou e geriu de forma segura?

Uma publicação no blogue da Akamai destacou várias vulnerabilidades de segurança comuns associadas aos JWTs. Foi uma chamada de atenção para os potenciais riscos de uma gestão incorrecta dos JWTs. Nesta publicação do blogue, pretendo desenvolver essa ideia, concentrando-me numa vulnerabilidade adicional que é frequentemente ignorada: JWTs que não expiram. Veremos como este problema surge, juntamente com as vulnerabilidades de segurança associadas. Em seguida, darei algumas orientações para que saiba como se proteger destas vulnerabilidades de segurança.

Visão geral das vulnerabilidades comuns do JWT

Antes de nos debruçarmos sobre o assunto, vamos rever brevemente as vulnerabilidades do JWT destacadas na publicação do blogue que mencionei acima. As seis ameaças aos JWTs que o autor mencionou foram:

1. Permitir que o servidor utilize um token sem validação: Isto pode acontecer quando o servidor não verifica a integridade do token, facilitando a sua manipulação e exploração por parte dos atacantes. Os atacantes também podem definir o algoritmo de verificação (alg) como nenhum, tentando manipular o servidor para não validar o token.
2. Utilizar a mesma chave privada para diferentes aplicações: Esta prática pode comprometer várias aplicações se a chave for exposta.
3. Utilização de um algoritmo de assinatura fraco: Os algoritmos de assinatura fracos podem ser decifrados mais facilmente, conduzindo a um acesso não autorizado.
4. Escolher uma chave privada curta e/ou de baixa entropia: As chaves demasiado curtas ou sem aleatoriedade são mais susceptíveis a ataques de força bruta.
5. Manter dados sensíveis na carga útil de um JWT: As informações sensíveis armazenadas na carga útil podem ser expostas se o token for intercetado.
6. Confundir as chaves: A má gestão das chaves pode levar a uma validação incorrecta, permitindo o acesso não autorizado.

Para obter informações detalhadas sobre estas vulnerabilidades, consulte a publicação no blogue. Continuando, vamos analisar uma vulnerabilidade adicional: o JWT que não expira.

Vulnerabilidade adicional: JWTs que não expiram

Vejamos o seguinte JWT, que se baseia num exemplo real que encontrei não há muito tempo:

Trata-se de um JWT utilizado para autenticar e autorizar o acesso de um utilizador a uma API. Ele é assinado com um segredo seguro para evitar falsificação. À primeira vista, parece bom. Mas vamos olhar mais de perto para a carga útil:

Quando você olha para essa reivindicação ttl, provavelmente pensa em tempo de vida, porque é isso que TTL normalmente significa. 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 este JWT seja válido durante 1000 dias. Ou talvez queiram dizer milissegundos, e nesse caso pretendem que este JWT seja válido por 1 dia. Isso também pode fazer sentido.

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

Portanto, temos aqui dois problemas.

Em primeiro lugar, o emissor deste JWT está a utilizar ttl para especificar a expiração, mas ttl não é uma reivindicação JWT padrão. A maioria das bibliotecas concebidas para lidar com JWTs não reconhecerá ttl como uma instrução relacionada com a expiração do token. Isto levará a problemas de compatibilidade e o token será muito provavelmente tratado como não expirando.

Em segundo lugar, a reivindicação exp requer um carimbo de data/hora real de expiração, não um número relativo de milissegundos (ou segundos) a partir da hora de emissão. Esta confusão resulta provavelmente da utilização de ttl em vez de exp. No entanto, o emissor precisa de compreender o formato esperado para a reivindicação exp para garantir a expiração correta do token.

Quer não defina o tempo de expiração para um JWT ou o defina incorretamente (como no nosso exemplo), o seu JWT será tratado como não expirando. E isso apresenta uma falha de segurança significativa.  

Atenuando as vulnerabilidades de segurança do JWT

Agora que já abordámos as potenciais vulnerabilidades de segurança, a pergunta seguinte é: o que deve fazer em relação a isso? Felizmente, a atenuação desta vulnerabilidade é simples e direta!

Utilize sempre a afirmaçãoexp. Defina um tempo de expiração em cada token que você gerar. Quando o fizer, certifique-se de que utiliza a reivindicação exp padrão com o formato de valor esperado para garantir que está em conformidade com as especificações JWT e expira como pretendido.

Atualizar aplicações e bibliotecas. Certifique-se de que a sua aplicação e as bibliotecas que utiliza estão actualizadas e cumprem as normas JWT mais recentes. As actualizações regulares ajudam a corrigir vulnerabilidades de segurança e a melhorar a compatibilidade.

É isso aí. Siga estas diretrizes simples e reduzirá significativamente o risco de acesso não autorizado através de um JWT que não expira. Isso melhorará a segurança geral das suas implementações de JWT.

Conclusão

Compreender e resolver as vulnerabilidades do JWT é crucial para manter a segurança das suas aplicações. Neste post, destacamos o risco de tokens que não expiram. Usando a reivindicação de expiração corretamente e mantendo 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 vulnerabilidades de segurança de seus aplicativos.