Prevent session hijacking over unencrypted HTTP connections

[tokuhirom]

I want to know the spec of the restarting process. Kweb handles the state on the server side, as a result, I want to know what's happing in the server restarting process for deployment on the production environment.

If my understanding is correct, Kweb clears the client state, and clear the input form on the browser after server restarting, right?

[sanity]

Yes, if there is a server restart then it will lose the client state and active clients will do exponential backoff until they can reconnect. At this point, they'll do a full page refresh, which will lose any page data like input forms that wasn't yet stored server-side.

A simple way to mitigate this problem is to synchronize form fields as they're being typed and store them server-side, this will provide an experience similar to Google Docs.

There are other more complicated ways to mitigate it, I can go into more detail if you like.

[sanity]

Note to whoever documents this (probably me):

Other ways to mitigate:

• Use JavaScript to record state in local storage and restore on a full refresh

[sanity]

@chandrin94, picking up from discussion on #399:

On the broader issue, I'm still not sure I follow how you're using the client ids. The current approach is that if there is a server restart the clients will do exponential backoff until they can reconnect, and then they should refresh the page if the server has lost their state - which should get them back in sync.

How are you using the client ids here?

[chandrin94]

@sanity the main use for the client ids, is for authentication, since the cookie is tied to the client id. If the server doesn't know it, then auth is lost.

For example, for an app that uses a classic login (username-password) , that means the users would get redirected to the login page after each server restart. Refreshing the page would not help in this case.

[sanity]

@chandrin94 Ah, I see - so you're using the kweb client id to identify the user. This is a bit of a tangent, but could that be a security risk given that the client id will be transmitted in plaintext if the connection is HTTP rather than HTTPS?

Actually, this may indicate a more general security issue with the client ids, since they're essentially acting as an authentication token for a reconnecting client, but aren't encrypted over HTTP 🤔

[chandrin94]

@sanity these are valid concerns, but the session is over TLS

[sanity]

@chandrin94 Yes, I think most people will be using secure transport these days so it won't be an issue, but I have to plan for the worst :) I'll give it some thought.

[frnknglrt]

Hello,I have the following opinion on this:1. I don’t use the client Id for authentication anyway. I store a separate token in the database that is used for authentication. This also resolves the issue if you have a load balancer and the request ends up at another instance.2. The session hijacking risk via insecure transports is unmitigated in nearly all frameworks I’m aware of. In the end it can’t be resolved without implementing an application layer transport encryption and even then one could play “man in the middle”. Unless we have a very good idea how to resolve this, I would prefer to document this issue and make sure every user is aware of this. An alternative could be a let’s encrypt plug-in, that requests tls certs on the fly. Then, per default, kweb would only run via secure transports. But it must be possible to disable this easily, if tls termination happens on a reverse proxy that runs in front of kweb.BR,FrankAm 03.12.2022 um 19:07 schrieb Ian Clarke @.***>: @chandrin94 Yes, I think most people will be using secure transport these days so it won't be an issue, but I have to plan for the worst :) I'll give it some thought.

—Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you are subscribed to this thread.Message ID: @.***>

[github-actions[bot]]

This issue is stale because it has been open 30 days with no activity. Remove stale label or comment or this will be closed in 5 days.

[github-actions[bot]]

This issue is stale because it has been open 30 days with no activity. Remove stale label or comment or this will be closed in 5 days.

[github-actions[bot]]

This issue is stale because it has been open 30 days with no activity. Remove stale label or comment or this will be closed in 5 days.