JWt is composed in 3 parts, header, payload, signature.Header and payload are json base64 encoded so if you want to change information inside it encode with base64 algorithm.Don’t forget to change your signature to have a valid jwt.
Unfortunately, some libraries treated tokens signed with the none algorithm as a valid token with a verified signature. The result? Anyone can create their own “signed” tokens with whatever payload they want, allowing arbitrary account access on some systems.
Put header alg key to none and delete signature.
The JWT spec also defines a number of asymmetric signing algorithms (based on RSA and ECDSA). With these algorithms, tokens are created and signed using a private key but verified using a corresponding public key. This is pretty neat: if you publish the public key but keep the private key to yourself, only you can sign tokens, but anyone can check if a given token is correctly signed.
So change alg header to HS256 and sign your jwt with your public key.
To create the signature part you have to take the encoded header, the encoded payload, a secret, the algorithm specified in the header, and sign that.
Example: If alg is HS256, your signature is: HMACSHA256(base64UrlEncode(header) + “.” + base64UrlEncode(payload),secret)
We see before when jwt use HSXXX alg, the jwt was signed with a key so if you guess the key you can create a new jwt with a new payload. So you can test signature with a new secret and iterate this action for each word present in a dictionary(txt file)
Since the attacker can modify the kid header parameter, the attacker controlled value would be passed to the “system” function. The attacker could supply a command injection payload and retrieve the key from the server.
001; cd /flag && echo flag.txt
When the jwt have a key “jku” in header and the value is an url to jwks file , You try to create a new private,public key, and host your own jwks and finally sign your jwt with private key. (don’t forget to change you jku header with your public url/your_file)