1

I'm reading OWASP Top 10 - 2017 The Ten Most Critical Web Application Security Risks, and came across the following risk, under Broken Access Control vulnerabilities:

Metadata manipulation, such as replaying or tampering with a JSON Web Token (JWT) access control token or a cookie or hidden field manipulated to elevate privileges, or abusing JWT invalidation

I think I understood what the risks are, but I failed to see how someone could achieve this. Is it possible to change JWT data after it is generated? Or am I missing the point here?

  • Well the point of JWT is that it should not be possible to change it. But suppose that the application didn't check its integrity... – Ángel Sep 18 '19 at 21:04
  • That's what I understood by the abusing JWT invalidation part, but im having a hard time understanding replaying or tampering. – Bruno Mazzardo Sep 18 '19 at 21:06
1

There are multiple options for JWT tampering. Some web applications do not validate the signature, or don't use it at all. That means an attacker can modify the contents at will, insert all kind of nasty payloads (XSS, SQLi), ignore the expiration time by using an arbitrary value for the timestamp, and so on.

Another way is called signature exclusion. JWTs have only two mandatory signing-algorithms that are mandatory to implement: "none" and "HS256". Inspect the JWT by Base64-decoding it:

{"alg":"HS256","typ":"JWT"}

If you see the algorithm being HS256, it is an indicator that the system may be using a default implementation (and probably even an outdated one). You can then replace the algorithm with "none", and remove the signature completely (the part after the last period).

If the server accepts the JWT like this, you can then start tampering the contents again, as explained above.

  • What is a "default" implementation? How is using HS256 a sign that the webapp is using an outdated JWT library? What do you recommend implementers should use instead? – Sjoerd Sep 19 '19 at 10:05
  • @Sjoerd Since HS256 is usually the default signing algorithm, if it is using a different algorithm that would mean it cannot be the default. All 'secured' implementations I have seen have been using RS256. HS256 can be bruteforced. And all cases of successful signature exclusion attacks that I've experienced (or found) have been using HS256. Also while we're at it I'd like to add (to my above answer) that JWTs are often not encrypted, so there shouldn't be any sensitive information (e.g. credentials) stored inside. – Martin Fürholz Sep 19 '19 at 12:17
1

I think I understood what the risks are, but I failed to see how someone could achieve this. Is it possible to change JWT data after it is generated? Or am I missing the point here?

JWT was made in such a way to prevent what you are saying(token signing).Infact if you use an updated JWT library you can prevent token tampering.Most of JWT related vulnerability stems from using a vulnerable library trusting the header part which specifies the algorithm being used.You could base64 decode and tamper it to use the NONE algorithm and strip away the signature.You could also try and break the "secret" used in the HS256 and then sign the tokens yourself(This is only possible if the secret used has low entropy). There is another attack where if an attacker can obtain the public key he can change the algorithm from RS256 to HS256 then sign the token using public key.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.