QUESTION: Security concerns

[jonDel]

Issue type

I'm submitting a ...

• bug report
• feature request
• question

Issue description

Hello. I'm new to frontend development, and after reading and implementing the authentication part of the nebular tutorial, some concerns came to my mind. In the case of the authentication using JWT token, after the login (when successful) nebular stores the token retrieved from the backend in the local storage, so it can be verified by the guards in order to enable further navigation to protected views. There is no more token validation between frontend and backend after that.
So, if an attacker never contact the backend and forge a token in the local storage, since the token validation is done only in the login, the guards will check for the existence of the token (forged) and wrongly assume a user is logged in. It could possibly lead the attacker to access all the protected views by forging the user role. I know that the calls to retrieve data from the backend won't work (the backend will discard the forged token), but I think an unauthorized user by definitition must not even navigate to any protected view. The solution would possibly be to change or extended the isauthenticated method to send an additional request to the API ( to a /status endpoint, per example), with the token from local storage in the header, instead of using local storage directly. Does it make sense?

[nnixaa]

Hi @jonDel, no being a security specialist I can only comment that Nebular auth implementation is done according to https://tools.ietf.org/html/rfc6749, and there is no additional token validation.

I would say, that in your case the token check will just duplicate the very same check done by the resource API before returning any data back to the client.

Anyway, if you'd like to protect a route that is being accessed, you can implement this additional call to the API to validate the token before allowing to navigate to the requested page.

[MenchenFive]

@jonDel Just follow the golden rule: validations and security shall be implemented in BOTH front-end and back-end.

The way we do it is that we've set up http interceptors in our app, so that the token is sent in every request to the server, in the header. And our REST API backend validates that the token is signed with its own super secret key (which is never sent anywhere).

This way, even if the attacker could 'forge' a false token; at worst, the only thing he would've be able to access would be the menu interfaces, but not the server-stored sensitive data.

[jinxiu3939]

The backend should have the auth checking when the frontend request every api, and the wrong auth must be forbidden in the backend. Although the token is valid in the frontend, but it can not get any data from the api.
The frontend may not pay more attention for the token, I think the token should have the expires-in when the backend send it to the frontend, because the backend generate the token,so it must ensure the token is right.