I am wondering if it is smart to hash my session IDs before writing sessions to the session storage, in order to prevent session ID disclosure.
I am writing an application in PHP on top of the Symfony framework. By default PHP stores sessions as files in a directory readable by the PHP process using the session ID as part of the file name. The problem I see is that, if there is a local file inclusion bug or RCE in the application, an attacker can easily list all valid session IDs and hijack sessions.
Alternative session storage for PHP exists, such as Redis or Memcache, but these suffer from the same flaw. You can easily enumerate all keys in Redis or memcache and thus get a list of valid session IDs.
My idea for mitigation is very simple. Instead of storing sessions using the session-ID as the key, use the hash(session-ID) as the key instead. If an attacker then enumerates all existing keys, he still does not have any session IDs. Performacne matters and sessions are relatively short lived (as opposed to e.g. passwords) so I would use a fast hash like SHA-256 or BLAKE instead of e.g. bcrypt for hashing the session IDs.
My question: Does this make any sense? Does this buy me any extra security? Or does a local file inclusion bug or RCE already mean "Game Over" and is this just security theatre?
I can't be the first person to see this possible threat, but I cannot find any mention of this, or of hashing session IDs as a good mitigation or defense-in-depth. Perhaps I just lack the right vocabulary to put into Google?