Project

General

Profile

Actions

Bug #8531

closed

Cannot delete/modify remember me cookie when using web sockets

Added by Steven Köhler over 3 years ago. Updated almost 3 years ago.

Status:
Closed
Priority:
Normal
Assignee:
Roel Standaert
Target version:
Start date:
05/18/2021
Due date:
% Done:

100%

Estimated time:

Description

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.

  1. configure the example to use web sockets
  2. verify websockets are used ('[info] "wthttp: ws: connect with protocol version 13"' should occur in the log output)
  3. create and verify a new user
  4. log in with the newly created user and check remember me (do not log out!)
  5. reload the session (you should be logged in automatically)
  6. logout
  7. 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;";

Since the updated remember me cookie is set from the applications constructor, seemingly in a response before the web socket connection is fully established (according to the log output), it gets the 'HttpOnly' flag set. Unfortunately the 'HttpOnly' flag prevents the cookie from being manipulated from javascript, which is the reason it is not deleted when logging out while using web sockets. To verify this, I manually unset the flag in the browsers debug console and logging out afterwards works as intended - the cookie gets deleted.

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.

Best regard
Steven


Related issues 1 (0 open1 closed)

Related to Bug #8668: cannot get private resource after loginClosedKorneel Dumon06/09/2021

Actions
Actions #1

Updated by Korneel Dumon over 3 years 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.

Actions #2

Updated by Roel Standaert over 3 years ago

  • Status changed from InProgress to Review
  • Assignee changed from Korneel Dumon to Roel Standaert
Actions #3

Updated by Roel Standaert over 3 years ago

  • Target version set to 4.6.0
Actions #4

Updated by Roel Standaert over 3 years ago

  • Related to Bug #8668: cannot get private resource after login added
Actions #5

Updated by Roel Standaert over 3 years ago

  • Status changed from Review to Implemented @Emweb
Actions #6

Updated by Roel Standaert over 3 years ago

  • % Done changed from 0 to 100
Actions #7

Updated by Roel Standaert about 3 years ago

  • Status changed from Implemented @Emweb to Resolved
Actions #8

Updated by Roel Standaert almost 3 years ago

  • Status changed from Resolved to Closed
Actions

Also available in: Atom PDF