"JWT is protected against tampering" true to a limited extent
scenario 1:
the app gets a token from the server, but a proxy(like burp) intercepts the token then
decodes the payload, alters parameter(s) for example some user id parameter like email for example then passes the token to the app, since the app more than likely does not check the signature( usually verify is on the back-end) the app will now make a state update on altered user data
scenario 2:
their is a bunch of attacks based on the "algo" parameter
strongly advise working on the premise the JWT has been tampered with and coding defensibly against this, for example scenario 1, resend the JWT back to the back-end for verification before app state update
You described MITM attack where malicious proxy can read and modify arbitrary data between client and server. If client sends back to the server jwt token for verification, what prevents proxy from intercepting this request and spoofing the response?
u are correct nothing stops this,hopefully you can see that just trusting that the jwt is valid is an error, basic idea is if you get a jwt that does not verify on the server then this is a red flag that you are under attack and you then implement defensive code, which is better than just hoping everything is ok, as to spoofing the response need correct headers
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
"JWT is protected against tampering" true to a limited extent
scenario 1:
the app gets a token from the server, but a proxy(like burp) intercepts the token then
decodes the payload, alters parameter(s) for example some user id parameter like email for example then passes the token to the app, since the app more than likely does not check the signature( usually verify is on the back-end) the app will now make a state update on altered user data
scenario 2:
their is a bunch of attacks based on the "algo" parameter
strongly advise working on the premise the JWT has been tampered with and coding defensibly against this, for example scenario 1, resend the JWT back to the back-end for verification before app state update
You described MITM attack where malicious proxy can read and modify arbitrary data between client and server. If client sends back to the server jwt token for verification, what prevents proxy from intercepting this request and spoofing the response?
u are correct nothing stops this,hopefully you can see that just trusting that the jwt is valid is an error, basic idea is if you get a jwt that does not verify on the server then this is a red flag that you are under attack and you then implement defensive code, which is better than just hoping everything is ok, as to spoofing the response need correct headers