0

I'm currently working on a personal project including a RESTful API and also trying to understand how to make it as secure as possible. I have read a bit about JWT, the possible vulnerabilities as well as some suggestions on how to mitigate these vulnerabilities. From this information I came up with the following "procedure" for lack of a better term, to me it is sound but I know I'm wrong because someone much smarter than me would have already come up with this so I'm curious where my logic is wrong. This is of course assuming all traffic is on HTTPS and disregarding any "social engineering" XSS attacks which I am assuming is 100% up to the user to defend themselves against.

So here it goes,

  1. User logs in, gets a long lived "refresh" JWT as an HttpOnly cookie.

  2. Anytime the user wants to make a request to the API the JWT Cookie is sent to a specific API endpoint where another "access" JWT is issued as either a header or payload.

  3. This "access" JWT is then used as the actual authentication token, again as either a header or payload, to access the various endpoints.

The logic behind this is that HttpOnly Cookies are vulnerable to CSRF but not XSS, so although an attacker might send a request on your behalf during a CSRF attack they would not be able to intercept the resulting "access" token. This resulting "access" token is short lived, no more then 10 second lifespan, so if there is a XSS attack the chances of an attacker intercepting and then using the "access" token is very slim.

Therefore as long as the user does not fall for phishing/fake login type screens that would steal their credentials they would be pretty safe. Obviously this is overkill for the application I'm working on but I'm using it as an exercise in security as well so yea, can someone explain where my logic is wrong?

0

Your Answer

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

Browse other questions tagged or ask your own question.