Attaques de confusion entre HS256 et RS256

La confusion d’algorithmes dans les JWT paraît très spécialisée jusqu’au jour où l’on trouve un service avec trois bibliothèques d’authentification et un helper partagé nommé verifyToken. L’attaque classique exploite un vérificateur qui accepte HS256 et RS256 tout en utilisant le même matériau de clé dans le mauvais rôle. Si le serveur traite une clé publique RSA comme un secret HMAC, l’attaquant peut signer un faux jeton HS256 avec des données qui n’étaient jamais censées être secrètes.

Pourquoi le bug passe les revues

En revue de code, on voit souvent jwt.verify(token, key) et l’on continue. La décision dangereuse est cachée dans les valeurs par défaut: algorithmes acceptés, sélection de la clé, branchement éventuel sur l’en-tête du jeton. Les équipes copient aussi des extraits entre services. Une chaîne de clé publique sûre dans un vérificateur RS256 devient dangereuse lorsqu’elle est donnée à un vérificateur qui fait confiance à alg dans l’en-tête.

Les attaquants cherchent des endpoints JWKS exposés, des fichiers PEM dans des applications mobiles, des bundles frontend, des exemples de documentation et des messages d’erreur qui trahissent le comportement du vérificateur. Une fois la clé publique obtenue, ils créent un jeton avec alg à HS256, signent le payload en utilisant les octets de cette clé publique comme secret HMAC, puis testent l’acceptation. Le changement de payload reste souvent discret: augmenter scope, changer tenant_id ou mettre admin à true.

Tester sans faire de bruit

Utilise un compte peu privilégié et commence par un endpoint non destructif, comme les métadonnées de profil ou une route de feature flags. Garde iss, aud et exp valides afin qu’un rejet renseigne mieux sur le traitement de signature. Une réponse invalid algorithm est bon signe. Une réponse invalid signature demande plus d’analyse: l’algorithme est-il fixé, ou le format de clé est-il mauvais? Les en-têtes PEM, retours ligne et espaces finaux comptent.

Liste de contrôle défensive

Fixe les algorithmes par émetteur. Ne laisse pas l’en-tête du jeton décider si une clé est symétrique ou asymétrique. Stocke les secrets HMAC et les clés publiques RSA ou EC dans des chemins de configuration séparés, avec des types séparés si le langage le permet. Un vérificateur RS256 doit refuser de démarrer avec un secret HMAC, et un vérificateur HS256 ne doit jamais charger une clé publique depuis JWKS.

La leçon opérationnelle

La correction consiste à séparer clairement les choses. Un émetteur, une famille d’algorithmes attendue, une source de clé, un wrapper de vérification. Pendant une migration de HS256 vers RS256, n’accepte pas les deux algorithmes indéfiniment sur la même audience. Prévois une courte fenêtre, observe l’usage de l’ancien algorithme, puis supprime le fallback.