Live data from Hacker News

Stop using JSON Web Tokens for user sessions

ds-security.com

131–140 of 145 posts

Re: Stop using JSON Web Tokens for user sessions

#131
post #17

Earlier quoted context omitted.

And set the SameSite attribute to strict to prevent CSRF

Wouldn't SameSite=Lax work just as well to prevent CSRF? It prevents things like malicious forms and image links from other sites.

Yes, Lax is the option when you want preventing CSRF and nothing else.

I actually don't know any use case for Strict, but it makes sense, so it's probably useful.

And None is for when you want to explicitly allow CSRF (what is useful some times).

And either way, it's best to always set that flag on sensitive cookies (not only authentication, but anything that leaks user information too), even if it's the documented default, because browsers make quite a mess of their default.

Re: Stop using JSON Web Tokens for user sessions

#132
post #126
post #51

Earlier quoted context omitted.

I had a problem with cookies on iOS/safari, so we reached for the last hope: url query args. Works flawlessly now. If you use an external identity provider, you can hypothetically avoid storing any cookies at all in first party terms. All you'd have would be 3rd party AAD tokens or whatever. The only reason we even need first party client state is because we want to allow each user simultaneous app sessions that have…

Keep in mind that urls end up in logs, that might well not be so well protected

Particularly if you use cdns, tracing, analytics, etc.

Also, IIRC a parent frame can retrieve a child frame's current URL no matter what.

Re: Stop using JSON Web Tokens for user sessions

#133
post #81

Earlier quoted context omitted.

I don’t understand the downvotes here. The application should be as resistant to xss as possible but things do sneak through and we should try to limit the damage in other layers. An example is that you could think you have no xss issues because you use react to do your rendering. Meanwhile you have a window.location = something_from_url which is just as capable of running js code if you’re not careful. Having the au…

Using xss one might target login form and steal username/password instead of a token. So I do not see argument here against jwt. Sure the xss will have to be more sofisticated(?)

I’m not arguing for / against any specific technology. I’m saying that relying on a lack of security flaws in one layer isn’t a great idea.

Re: Stop using JSON Web Tokens for user sessions

#134
post #126
post #51

Earlier quoted context omitted.

I had a problem with cookies on iOS/safari, so we reached for the last hope: url query args. Works flawlessly now. If you use an external identity provider, you can hypothetically avoid storing any cookies at all in first party terms. All you'd have would be 3rd party AAD tokens or whatever. The only reason we even need first party client state is because we want to allow each user simultaneous app sessions that have…

Keep in mind that urls end up in logs, that might well not be so well protected

In our case this is fine. The URL doesn't pass any claims. It is opaque client state bound to a specific identity which is validated by other means.

Re: Stop using JSON Web Tokens for user sessions

#135
post #74

Earlier quoted context omitted.

because these are not cookies, right?

The law has never been about cookies themself but about tracking user and asking their consent for selling/sharing their identifying data for things unrelated to the displayed purpose of the site.

It is, in the minds of many.

And FYI it is not even a law.

Re: Stop using JSON Web Tokens for user sessions

#136
post #89

Earlier quoted context omitted.

I work for ab EU government, and cookies are a no-go because of cookies directive, so we use JWT and auth the javscript engine, not the browser. This leads to a multitude if problems, but who cares?

This makes no sense. The law didn't specify cookies specifically, it is agnostic about the technical implemention, surely? Is this a clueless manager thing?

Not a manager thing, it is a consensus in at least one major EU government sweatshop.

Go figure.

Re: Stop using JSON Web Tokens for user sessions

#137

Earlier quoted context omitted.

I work for ab EU government, and cookies are a no-go because of cookies directive, so we use JWT and auth the javscript engine, not the browser. This leads to a multitude if problems, but who cares?

That's bullshit. Even ec.europa.eu (the European Commission's website - I have to login there from time to time) sets session cookies on my browsers. Either you've misunderstood what's asked of you, or your manager has, or someone higher up in your organization. But the "cookie directive" has never prevented anyone from using cookies altogether. You don't even need to ask for consent for a session cookie.

*.europa.eu websites have been known to infringe on EU rules forever. Shoemaker without shoes, you know.

Re: Stop using JSON Web Tokens for user sessions

#138

Earlier quoted context omitted.

That's bullshit. Even ec.europa.eu (the European Commission's website - I have to login there from time to time) sets session cookies on my browsers. Either you've misunderstood what's asked of you, or your manager has, or someone higher up in your organization. But the "cookie directive" has never prevented anyone from using cookies altogether. You don't even need to ask for consent for a session cookie.

*.europa.eu websites have been known to infringe on EU rules forever. Shoemaker without shoes, you know.

That's a bold claim, any source?

Re: Stop using JSON Web Tokens for user sessions

#139
post #99

It's articles like these that make things more confusing for folks who are learning about auth/session security. It's obvious the author has developed strong convictions without really understanding the subject. I can't make it past the first sentence: > ...utilize JSON Web tokens (JWTs) for session handling instead of cookies. One has nothing to do with the other. You can use a jwt and cookies. You can use a db sess…

In a single page application you have to access the JWTs with JavaScript. When we use cookies to implement sessions we have attributes like HttpOnly to prevent the cookie from being referenced by JavaScript code. In this case a XSS vulnerability would not be able to simply access the cookie and take over another users session.

What I am trying to say here is that JWTs used in single page applications are dangerous because you have no layer of protection against XSS attacks.

Re: Stop using JSON Web Tokens for user sessions

#140

Just do not store JWTs in LocalStorage or any JavaScript accessible location. Use secured httpOnly cookies. Validate the JWT on server-side _stateless_. No need for a database. This idea is so good and it works! Just follow best security practice. If you don't, it is not the fault of the JWT. Bad blog article.. Yes, things like Keycloak and such follow _bad practice_. Still not the fault of JWT.

In a single page application it is necessary to access the JWT with JavaScript. Thats why it is so common to save it in the code directly or in the local storage. It is dangerous though, since a XSS vulnerability can be used to access the JWT. This would be totally different with a cookie that is stored with HttpOnly.
Post reply on HN