Learn More
Resend Email
2
Fexell
6y

Since my question, in all likelihood, won't get answered on StackOverflow, I hope I can ask it here instead. I hope that's alright.

So, I am currently developing a Feathers + Nuxt boilerplate, and am using localStorage to store the jwt.
But I noticed if I set the localStorage with the jwt manually, it will act as if I'm logged in, bypassing the entire login-function. So I solved this by using an iframe with a script that clears localStorage (and log out the user, if logged in) when something changes in the localStorage (by using the eventListener "storage"). (I am also observing the iFrame if someone deletes it, in the console, and re-inserts itself).

My question is if this would carry any security risks? Like, would this be a bad thing to do, security wise? Is it alright to leave it alone and let users/visitors to set the jwt manually?

question

localstorage

iframe

nodejs
Favorite
Ranter
Comments
  • 0
    6y
    .
  • 2
    6y
    Haven't really worked with any of these frameworks so hopefully someone else can verify what I'm saying. But I assume that if the token is to hold any value at all as far as security goes it would have to be validated on the server side in order for the user to be able to access protected content.

    Anything you do on the client side should always be considered insecure because the user can alter it to their liking. At best it will slow a determined attacker down. So trying to implement security on the front-end seems like a waste of time. The goal there should instead be to encourage the user to input correct information.
  • 2
    6y
    Huh? I don't know if I get your Problem correctly but the flow should be much easier like:
    Über visits page - no jwt in localstorage - he logs in - set jwt in localstorage - he can use Server apis with the jwt - user closes Browser - time goes by - user opens page again - jwt in localstorage found - calls Server for validating jwt - if valid - user is logged in - if not user is not logged in
    Does it make sense?
  • 1
    6y
    @ch0s3n Okay, I see. Then maybe I should skip it. The reason for trying to combat this problem, is if someone who is not the user gets a hold of somebody's JWT - he or she can then just add it into the local storage and voila, the "hacker" is logged in with someone else's account.
  • 1
    6y
    @Minion What I'm talking about is setting your local storage manually. As in opening up the console / storage window in the browser, type in the key "jwt" and provide it with the JWT.

    Under the application tab (in the console) you can view your local storage and also add items to it. This is what I'm trying to prevent.
  • 2
    6y
    @Fexell oh I See. So you don't have to think about users fiddling around manually, cause they cannot produce a valid jwt for your Server. If your API is secured and validates the jwt then everything is alright. The user may can achieve that thr ui looks like he is logged in but he cannot do anything because your API is secured.
  • 2
    6y
    @Fexell Yea I see where you're coming from. It's like putting a lock on your bike though. If the thief has a set of bolt cutters (or w/e tools bike thieves use), they can still break through it. It might be a bit more of a hassle, but it won't stop them if they really want the bike.

    If you want to read more on how to protect against these types of attacks you should look up session hijacking.
  • 1
    6y
    @ch0s3n Yeah, I know about session hijacking. But I've now instead decided to use cookies (as opposed to localStorage), since you cannot "easily" change the value of a cookie.

    Guess I'm gonna read a bit more about security in Node JS.
  • 1
    6y
    I stopped reading at 'iframe'
Related Rants
devRant © 2021 Hexical Labs LLC
Privacy Policy  |  Terms of Service
Add Comment