9 ms·

Doesn'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 tho

Doesn'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.

s_ting765 9mo ago
You may be thinking of CSRF mitigations. XSS exploits are more dangerous and can do more than steal sessions.
ddlsmurf 9mo ago
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
- collinmanderson 9mo ago
  with http-only they can't _steal_ the cookie, but they can still _use_ the cookie. It reduces the impact but doesn't fully solve it.
hackermondev 9mo ago
Discord puts the authentication token in local storage
- edoceo 9mo ago
  Is that a problem on its own? It's like, encrypted right? Maybe a time sensitive token?
  - seangrogg 9mo ago
    Depends on the token; JWTs usually have payloads that are only base64 encoded. As well, if there's a refresh token in there it can be used to generate more tokens until invalidated (assuming invalidation is built in).
  - socketcluster 9mo ago
    Not a problem in itself. Also, there's not much point of encrypting tokens. The attacker could use the encrypted token to authenticate themselves without having to decrypt. They could just make a request from the victim's own browser. They could do this with cookies too even with httpOnly cookies. XSS is a big problem. If a hacker can inject a script into your front end and make it execute, it's game over. Once they get to that point, there's an infinite number of things they can do. They basically own the user's account.
    - arethuza 9mo ago
      Does anyone actually encrypt the contents of JWTs? I'd have thought that anyone who has concerns about the contents of the token being easily visible would be likely to avoid JWTs anyway and just use completely opaque tokens?
      - kbolino 9mo ago
        Encrypted tokens are opaque but they are also offline-verifiable. A simple opaque token has to be verified online (typically, against a database) whenever it's used. Auth0, for example, supports JWE for its access tokens: https://auth0.com/docs/secure/tokens/access-tokens/json-web-encryption https://auth0.com/docs/secure/tokens/access-tokens/json-web-...
      - socketcluster 9mo ago
        JWT supports some encryption algorithms as an alternative to signatures but my experience is that most people like to keep it simple. JWT is intended for authentication. Most of the time you're basically just signing a token containing an account ID and nothing else... Sometimes a list of groups but that only scales to a small number of groups.
notnullorvoid 9mo ago
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).
- drewvlaz 9mo ago
  Wow did not realize a url could be set like that without promoting a page reload...
  - notnullorvoid 9mo ago
    To be clear only the path and query parameters part of the url can change, the domain (or sub domain) stays intact.
    - sdf456 9mo ago
      Even scarier to me than the vulnerability is that Fidelity (whom I personally think is a good bank and investment company) was using a third party that allowed injection that could potentially steal a whole lot of money, affect markets, ruin or terminate billions of lives, and affect the course of humanity. What the fuck.
      - DANmode 9mo ago
        Their knowledge of finance is certainly better than their knowledge of web tech. Historically and today.
      - sebmellen 9mo ago
        That’s why I’m a Schwab junkie… but finance is a hotspot for this kind of stuff.
      - udev4096 9mo ago
abustamam 9mo ago
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.
selfmodruntime 9mo ago
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.
- collinmanderson 9mo ago
  with http-only they can't _steal_ the cookie, but they can still _use_ the cookie. It reduces the impact but doesn't fully solve it.
netdevphoenix 9mo ago
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
- Aldipower 9mo ago
  The cookie storage and the local storage by all means is not the same! Cookies are not stored in the local storage and could be httpOnly, so they are not directly accessible by JavaScript. Nevertheless, as described above, with this XSS attack it is easy to bypass the token and just steal the user credentials by pretending a fresh login mask keeping the origin domain intact. That's why XSS attacks are dangerous since existence. Nothing new actually.
z3t4 9mo ago
https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Headers/Set-Cookie#httponly https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/...
giancarlostoro 9mo ago
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.
- seaal 9mo ago
  Probably because the end user hates login in, my friends always complain about the “remember me” button being useless for some services.
  - giancarlostoro 9mo ago
    No, these are tokens that you get a new one per request, if you open up dev tools, and open the user settings panel, you will see that you get a new one every single time you open the user settings panel. They never expire, at least for years they were insanely long lasting.

s_ting765 9mo ago

You may be thinking of CSRF mitigations. XSS exploits are more dangerous and can do more than steal sessions.

ddlsmurf 9mo ago

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

collinmanderson 9mo ago
with http-only they can't _steal_ the cookie, but they can still _use_ the cookie. It reduces the impact but doesn't fully solve it.

hackermondev 9mo ago

Discord puts the authentication token in local storage

edoceo 9mo ago
Is that a problem on its own? It's like, encrypted right? Maybe a time sensitive token?
- seangrogg 9mo ago
  Depends on the token; JWTs usually have payloads that are only base64 encoded. As well, if there's a refresh token in there it can be used to generate more tokens until invalidated (assuming invalidation is built in).
- socketcluster 9mo ago
  Not a problem in itself. Also, there's not much point of encrypting tokens. The attacker could use the encrypted token to authenticate themselves without having to decrypt. They could just make a request from the victim's own browser. They could do this with cookies too even with httpOnly cookies. XSS is a big problem. If a hacker can inject a script into your front end and make it execute, it's game over. Once they get to that point, there's an infinite number of things they can do. They basically own the user's account.
  - arethuza 9mo ago
    Does anyone actually encrypt the contents of JWTs? I'd have thought that anyone who has concerns about the contents of the token being easily visible would be likely to avoid JWTs anyway and just use completely opaque tokens?
    - kbolino 9mo ago
      Encrypted tokens are opaque but they are also offline-verifiable. A simple opaque token has to be verified online (typically, against a database) whenever it's used. Auth0, for example, supports JWE for its access tokens: https://auth0.com/docs/secure/tokens/access-tokens/json-web-encryption https://auth0.com/docs/secure/tokens/access-tokens/json-web-...
    - socketcluster 9mo ago
      JWT supports some encryption algorithms as an alternative to signatures but my experience is that most people like to keep it simple. JWT is intended for authentication. Most of the time you're basically just signing a token containing an account ID and nothing else... Sometimes a list of groups but that only scales to a small number of groups.

notnullorvoid 9mo ago

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).

drewvlaz 9mo ago
Wow did not realize a url could be set like that without promoting a page reload...
- notnullorvoid 9mo ago
  To be clear only the path and query parameters part of the url can change, the domain (or sub domain) stays intact.
  - sdf456 9mo ago
    Even scarier to me than the vulnerability is that Fidelity (whom I personally think is a good bank and investment company) was using a third party that allowed injection that could potentially steal a whole lot of money, affect markets, ruin or terminate billions of lives, and affect the course of humanity. What the fuck.
    - DANmode 9mo ago
      Their knowledge of finance is certainly better than their knowledge of web tech. Historically and today.
    - sebmellen 9mo ago
      That’s why I’m a Schwab junkie… but finance is a hotspot for this kind of stuff.
    - udev4096 9mo ago

abustamam 9mo ago

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.

selfmodruntime 9mo ago

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.

collinmanderson 9mo ago
with http-only they can't _steal_ the cookie, but they can still _use_ the cookie. It reduces the impact but doesn't fully solve it.

netdevphoenix 9mo ago

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

Aldipower 9mo ago
The cookie storage and the local storage by all means is not the same! Cookies are not stored in the local storage and could be httpOnly, so they are not directly accessible by JavaScript. Nevertheless, as described above, with this XSS attack it is easy to bypass the token and just steal the user credentials by pretending a fresh login mask keeping the origin domain intact. That's why XSS attacks are dangerous since existence. Nothing new actually.

z3t4 9mo ago

https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Headers/Set-Cookie#httponly https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/...

giancarlostoro 9mo ago

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.

seaal 9mo ago
Probably because the end user hates login in, my friends always complain about the “remember me” button being useless for some services.
- giancarlostoro 9mo ago
  No, these are tokens that you get a new one per request, if you open up dev tools, and open the user settings panel, you will see that you get a new one every single time you open the user settings panel. They never expire, at least for years they were insanely long lasting.