Els JSON Web Tokens s'han convertit en l'estàndard de facto per a l'autenticació i autorització en aplicacions modernes. No obstant això, la seva aparent simplicitat amaga múltiples vulnerabilitats que, explotades correctament, poden comprometre completament la seguretat d'un sistema. A Q2BSTUDIO, com a empresa especialitzada en aplicacions a mida, hem auditat desenes de projectes on la implementació de JWT presentava errors crítics, sovint ignorats fins i tot per equips amb experiència. Aquest article analitza tres vectors d'atac clàssics i, el més important, revela l'única regla defensiva que els bloqueja tots. A més, veurem com aquesta regla s'integra de forma natural en arquitectures cloud (AWS/Azure), solucions de BI amb Power BI i sistemes amb agents d'IA.
Abans d'entrar en matèria, convé recordar que un JWT està compost per tres parts codificades en base64url: el header, el payload i la signatura. El header especifica l'algorisme utilitzat per signar; el payload conté les reclamacions (com el rol de l'usuari); i la signatura es calcula sobre les dues primeres parts. Qualsevol que posseeixi el token pot llegir el payload, perquè només està codificat, no xifrat. Aquest fet, sumat a una verificació delegada al propi token, dóna lloc als atacs que descriurem.
Atac 1: Algorisme 'none'El primer atac és gairebé insultant per la seva senzillesa. Si el servidor confia en l'algorisme declarat al header, un atacant pot modificar el token perquè indiqui 'alg':'none', alterar el payload amb privilegis d'administrador i eliminar la signatura. El servidor, si no valida explícitament que l'algorisme sigui segur, acceptarà el token com a autèntic. Aquest error, documentat a CVE-2015-9235 per a la llibreria jsonwebtoken de Node.js, va afectar moltes implementacions per defecte. En projectes de ciberseguretat que hem revisat a Q2BSTUDIO, vam trobar que fins i tot equips que utilitzaven frameworks moderns oblidaven configurar una llista blanca d'algorismes, deixant la porta oberta a aquest vector.
Atac 2: Secret feble (offline brute force)Els algorismes HS256, HS384 i HS512 utilitzen HMAC amb una clau secreta compartida. Si aquesta clau ha estat triada per un humà (com 'secret' o 'changeme'), un atacant pot descarregar un diccionari com rockyou.txt i provar cada candidat contra el token original, sense necessitat d'interactuar amb el servidor. No hi ha límit d'intents ni bloqueig de compte. Un cop trobada la clau, l'atacant pot signar qualsevol token. La solució és utilitzar claus generades per un generador criptogràfic segur (CSPRNG) d'almenys 256 bits. En les solucions cloud (AWS/Azure) que desenvolupem a Q2BSTUDIO, recomanem emmagatzemar aquestes claus en serveis gestionats com AWS Secrets Manager o Azure Key Vault, i rotar-les periòdicament.
Atac 3: Confusió d'algorismes (RS256 a HS256)Aquest atac és més sofisticat i aprofita que el servidor confia en l'algorisme del header. Si el servidor utilitza RS256 (signatura asimètrica amb clau privada i verificació amb clau pública), l'atacant canvia l'algorisme a HS256. Llavors el servidor utilitzarà la clau pública (que és, per definició, pública) com a clau HMAC per verificar. L'atacant descarrega aquesta clau pública, signa un token fals amb HS256 utilitzant els bytes de la clau pública com a secret, i el servidor l'accepta. Un detall subtil: els salts de línia al final del fitxer PEM poden canviar el resultat. Per això, en auditar tokens, és important provar variants. A Q2BSTUDIO, quan implementem sistemes amb agents IA que intercanvien tokens entre microserveis, assegurem que la verificació no delegui l'elecció de l'algorisme al token entrant.
L'única regla que els deté totsEls tres atacs comparteixen una mateixa arrel: confiar en les dades del propi token per decidir com verificar-lo. La solució és senzilla i s'implementa en una línia de codi: fixar al servidor una llista blanca d'algorismes acceptats i rebutjar qualsevol altre, incloent 'none'. Per exemple:
ALLOWED = {'RS256'}claims = jwt.decode(token, public_key, algorithms=list(ALLOWED))
Aquest únic argument algorithms elimina de cop l'atac de l'algorisme 'none' i el de confusió RS/HS. Combinat amb una clau secreta robusta (per a HS256) o un parell de claus asimètriques ben gestionades, es tanca la tercera porta. A més, cal establir expiracions curtes, no incloure dades sensibles al payload (recordem que està només codificat) i auditar periòdicament els tokens en producció.
A Q2BSTUDIO, apliquem aquesta regla en tots els nostres desenvolupaments, ja sigui en aplicacions a mida, en solucions de BI amb Power BI que autentiquen mitjançant tokens, o en arquitectures cloud amb AWS o Azure on els serveis es comuniquen mitjançant JWT. La cultura de seguretat no és un afegit, sinó un pilar del disseny. Els nostres equips de ciberseguretat realitzen auditories de tokens com a part integral del procés de pentesting, i formem els desenvolupadors perquè no depenguin de configuracions per defecte.
Recomanem a qualsevol organització que utilitzi JWT que revisi els seus tokens amb eines com jwt-auditor (open source i offline). N'hi ha prou amb executar jwt-auditor audit <token> per detectar si l'algorisme és insegur, si la clau és endevinable o si el token verifica amb la clau pública com a HMAC. Vint segons de comprovació poden estalviar un incident de seguretat majúscul.
Els atacs descrits no són nous, però continuen sent efectius perquè molts equips assumeixen que el propi token es verifica a si mateix. La realitat és que la seguretat d'un JWT depèn enterament de com el servidor el valida. Adoptar la regla de no delegar l'elecció de l'algorisme és el primer pas cap a una autenticació robusta. A Q2BSTUDIO, ajudem les empreses a construir sistemes segurs des del disseny, integrant ciberseguretat, intel·ligència artificial i cloud de forma coherent. Si la teva organització utilitza JWT, no esperis que un atacant et demostri com de vulnerables són.
