Cannot delete/modify remember me cookie when using web sockets
Dear Wt team,
while testing an application I encountered a strange issue with the Wt::Auth remember me functionality: Despite explicitly (and repeatedly) logging out I got automatically logged in every time I reloaded the page, which clearly should not happen. I tested it with Edge 90.0.818.62 and Firefox 88.0.1. I traced the issue and found out that it is related to the remember me cookie and web sockets.
To rule out the possibility of using Wt::Auth incorrectly, I successfully reproduced the issue with the feature/auth1 example using the precompiled wt4.5.0 msvs2019 x64 binaries.
- configure the example to use web sockets
- verify websockets are used ('[info] "wthttp: ws: connect with protocol version 13"' should occur in the log output)
- create and verify a new user
- log in with the newly created user and check remember me (do not log out!)
- reload the session (you should be logged in automatically)
- reload the session (you should still be logged in)
I found that the remember me cookie was still present after logging out. Further testing showed that the remember me cookie gets properly deleted when logging out right after manually logging in (in the same session it was initially set), but not when the login is done with the remember me cookie. I noticed a difference in the cookie: After manually logging in, the cookies 'HttpOnly' flag is not set, after the remember me login the flag is set. I did some digging and found that the remember me cookie is re-set in
Wt::Auth::AuthModel::processAuthToken after a remember me login (which usually happens in the applications constructor). Tracing the
setCookie call lead to
Wt::WebRenderer::setHeaders, where I could find
if (!response.isWebSocketMessage()) header << " httponly;";
The same issue occurs for logging in (+ remember me) with another user after a remember me login. The cookie is not modified and thus the previous user is logged in again the next time the session is reloaded. I could not reproduce the issues when web sockets are disabled. Nevertheless I would consider this a security risk, as it effectively prevents logging out when using web sockets and remember me cookies.
A quick test revealed that the same issue occurs for other cookies, that are set in the constructor and are later 'deleted' from a websocket connection - the cookies remain unchanged.
Updated by Korneel Dumon about 1 year ago
- Status changed from New to InProgress
- Assignee set to Korneel Dumon
Thanks for the detailed analysis! To fix this, we're thinking to always use an HTTP request for cookie updates (apart from the active websocket connection). This way
httponly can still be added. This is already done for multi-session cookies, so it's a matter of generalizing it for all cookies.