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?

LTPCGO
  • 965
  • 1
  • 5
  • 22
Bruno Mazzardo
  • 111
  • 1
  • 3
  • 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

3 Answers3

4

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.

Martin Fürholz
  • 795
  • 9
  • 21
  • 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
2

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.

yeah_well
  • 3,699
  • 1
  • 13
  • 30
0

It can be achieved via man-in-the middle scenarios, in two ways

  1. If a malicious actor has a foot on the client device or at any of the hosts that are part of the processing and have access to JWT in clear text (i.e. after SSL transmission), then they can easily tamper the JWT. But, this is only useful when that hosts sends the JWT to another host for further/additional processing.

  2. If a malicious actor has access to SSL-protected internet packets and can convince the parties to use its own SSL, then they can listen and tamper the whole communication, including JWT. But this is not easy: they must have an SSL based on CA root certificate installed on the SSL participant (i.e public key user), not the initiator (i.e. private key holder). (Even Google certificates were found to generated by a CA several years ago. This is possible because any CA can issue Google or anyone's certificates and there are many CAs worldwide. Things are getting better since then though but slowly)

Please take a look at my answer here for a more detailed discussion in JWT

Is it necessary to encrypt a JSON Web Token more than what is built-in?

K4M
  • 542
  • 3
  • 8