alt Hacker NewsDoesn't stealing the cookies/token require a non-HTTP-only session cookie or a token in localstorage? Do you know that Discord puts their secrets in one of those insecure places, or was it just a guess?
I believe if you always keep session cookies in secure, HTTP-only cookies, then you are more resilient to this attack.
I interviewed frontend devs last year and was shocked how few knew about this stuff.
Replies
No because Discord auth tokens dont expire soon enough. The only thing that kills them is changing your password. Idk why Discord doesnt invalidate them after some time, it is seriously amateur hour over there and has been for a while.
if you set the cookier header right (definitely not always the case), this is true, but the javascript can still send requests that will have that cookie included, effectively still letting the hacker use the session as the logged in user
Discord puts the authentication token in local storage
Token stealing hasn't been a real danger for a decade now. If you don't mark your token's as non-HTTP you're doing something explicitely wrong, because 99% of backends nowadays do this for you.
As a FE dev, I wouldn't be able to articulate what you just did in the way you did, but it is something I know in practice, just from experience. I don't think any of the FE courses I took tackled anything like that.
You may be thinking of CSRF mitigations. XSS exploits are more dangerous and can do more than steal sessions.
Surely, if a script is in a position to sniff the cookie from local storage, they can also indirectly use the http-only cookie by making a request from the browser. So really not much of a difference as they will be taking over the account
In general if a script can run, users sessions and more importantly passwords are at risk.
It's true that an HTTP-only session cookie couldn't be directly taken, but it's trivial to present the user with a login screen and collect their password (and OTP), at which point you can easily get a session remotely. It can look entirely like the regular login page right down to the url path (because the script can modify that without causing a page load).