WebServer session and bad-login state is mutated from request threads without synchronization
Summary¶
The WebServer still processes accepted connections on separate request threads, but shared session and bad-login arrays are read and mutated without a lock. This can corrupt authentication state or session bookkeeping under concurrent login, logout, timeout, and failed-login requests.
Current Main Evidence¶
srchybrid\WebSocket.cppcreates an accepted-request thread for each allowed connection and dispatches intoCWebServer::_ProcessURL(...)or_ProcessFileReq(...).srchybrid\WebServer.cpp::_ProcessURL()adds and removes entries inm_Params.Sessionsandm_Params.badlogins._IsLoggedIn(),_RemoveTimeOuts(),_RemoveSession(),_GetSessionByID(),_IsSessionAdmin(),_SetLastUserCat(), and_GetLastUserCat()access or mutatem_Params.Sessionswithout a shared lock.- The code still contains the legacy comment that the WebServer is accessing main application state without synchronization and is relying on exception handling for containment.
Risk¶
MFC CArray mutation is not safe across concurrent request threads. A parallel
login/logout/bad-login burst can invalidate indices, lose updates, produce an
incorrect session count, or crash. Because this state is tied to WebServer
authentication, the fix should be treated as security-adjacent hardening even
if no bypass has been proven.
Broadband Fit¶
This is close-stock concurrency hardening. It should not change authentication policy, permissions, or the public WebServer API.
Resolution¶
Implemented on main with a narrow WebServer state lock covering session and
bad-login arrays. Blocking socket/UI/logging calls remain outside the lock.
Acceptance Criteria¶
- [x] add a narrow lock around WebServer session and bad-login state
- [x] avoid holding that lock while sending socket data or sending blocking UI messages
- [x] make session-count updates and timeout removal consistent with the same lock
- [x] keep REST request handling behavior unchanged
- [x] add targeted auth-state seam tests for bad-login throttling and session timeout policy; lock placement is covered by code review and app build