[BhavayGoyal]

Fixes #2593

Problem

With sessions enabled, findSessionForRequest() hands any non-empty JSESSIONID cookie value to SessionManager::getSession(), and getSession() creates a new session under that key when it isn't in the cache. So the client chooses the session ID:

• session fixation: an attacker can plant a known ID in a victim's browser and it becomes a real session,
• every made-up ID adds an entry to the shared session cache (with the default timeout of 0 they never expire),
• the IDs can be chosen to collide in the std::unordered_map behind CacheMap, which is the HashDoS described in the issue.

Fix

In SessionManager::getSession(), when the ID came from the cookie (needToSet == false):

• if it names a live session, return that session (unchanged behaviour), otherwise
• create the session under a new ID from the configured ID generator, with needToSet = true, so handleSessionForResponse() sends the new cookie.

So only server-generated IDs ever become cache keys. A client whose session expired (or who comes back after a server restart) just gets a new cookie, as it would without a cookie at all. Lookup of an existing session still refreshes its timeout as before (findAndFetch, like modify).

This covers the first suggestion in the issue. I didn't add a keyed hash or a session count cap here, to keep the change small; with only server-generated IDs as keys, clients can no longer pick colliding keys.

Testing

• New SessionManagerTest unit test: an issued ID returns the same session; an unknown ID gets a new session with a fresh server-generated ID; that new ID then resolves; the unknown ID is never stored. Against the current code it fails 5 of 9 assertions (the attacker-chosen ID is adopted); with the fix all pass.
• Full unittest suite passes (73 test cases, Ubuntu 24.04, GCC), and format.sh with clang-format-17 leaves no diff.

(Written with Claude, working with @BhavayGoyal.)