JWT : le jeton qui peut se falsifier lui-même

Le principe

Un JWT (JSON Web Token) est un jeton d’authentification composé de trois parties lisibles : un en-tête, des données (l’utilisateur, ses droits), et une signature qui prouve que le serveur l’a bien émis lui-même.

Le principe de sécurité entier repose sur cette signature : sans elle, n’importe qui pourrait écrire « je suis administrateur » dans ses propres données et se faire croire sur parole.

Un exemple concret

Certaines bibliothèques JWT, mal configurées côté serveur, acceptent un jeton dont l’en-tête annonce un algorithme « none » — littéralement « pas de signature à vérifier ». Un attaquant peut alors fabriquer lui-même un jeton avec les droits de son choix, sans avoir besoin de connaître le moindre secret.

Autre cas fréquent : le secret utilisé pour signer les jetons est un mot commun ou prévisible (le nom de l’entreprise, un mot du dictionnaire). Un attaquant le devine ou le casse hors-ligne en quelques secondes avec une liste de mots de passe classique, puis signe ses propres jetons comme s’il était le serveur.

Pourquoi c’est grave

Un JWT falsifié avec succès donne accès à n’importe quel compte, y compris administrateur, sans jamais toucher au système de mot de passe. C’est une prise de contrôle totale et silencieuse : aucune tentative de connexion échouée dans les journaux, aucune alerte déclenchée nulle part.

OWASP classe ce type de faiblesse sous A02:2021 – Défaillances cryptographiques et A07:2021 – Défaillances d’identification et d’authentification, selon l’angle exact du problème.

Comment s’en protéger

Toujours forcer explicitement l’algorithme de signature attendu côté serveur — ne jamais laisser le jeton présenté « choisir » lui-même son propre algorithme de vérification. Utiliser un secret HMAC long et véritablement aléatoire (32 octets ou plus), jamais un mot du dictionnaire ou une valeur prévisible.

Pour les algorithmes à clé publique/privée, ne jamais réutiliser la clé publique comme secret de vérification HMAC : c’est une confusion d’algorithme classique et dévastatrice. Vérifier systématiquement la date d’expiration du jeton à chaque requête, sans exception.

Comment SauronSec la détecte

Analyse passive d’abord : algorithme faible annoncé, secret HMAC cassable par dictionnaire hors-ligne, absence de date d’expiration, en-têtes dangereux qui pointent vers une clé externe non fiable.

En mode actif optionnel, SauronSec tente de forger un jeton sans signature et un jeton en confusion d’algorithme (clé publique réutilisée comme secret), puis vérifie sur une ressource RÉELLEMENT protégée si le jeton forgé est accepté par le serveur — jamais sur une simple supposition théorique.