2

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?

|improve this question
  • I've not completely thought through your setup, but in general terms, storing hashed session IDs is a good idea, for similar reasons that storing hashed passwords is a good idea (same applies to password reset tokens too). It's not a super important control, but given that it's quite easy to implement, I do recommend it in my training course. – paj28 Dec 16 '19 at 15:49
2

LFI on session file is possible, but there are plenty of other options like /proc/self/environ, file descriptors, web server logs, raw database files, SSH/FTP/mail logs, an uploaded file or a temporary uploaded file located in /tmp is also possible, so you gain very little security through obfuscation from doing this. If the attacker can enumerate all session files they can just try all of them until one works. You would be better off spending the would be development time hardening your server or reviewing your code.

|improve this answer
  • If the attacker can enumerate all session files they can just try all of them until one works but if I use the hash as key instead of the session ID, an attacker cannot try them, right? He has no way of getting the correct session ID for any of the session files. – Sander Marechal Dec 16 '19 at 16:55
  • 1
    If the attacker has another bug that lets them enumerate files on the disk they can leak the session filenames, bugs in code bases rarely exists in isolation, there are likely multiple bugs that can be combined. But it hardly matters because session files is only one vector. If you have LFI you cannot rely on session obscurity to keep you safe as any multiform POST request with a file upload to any PHP file will create a temporary file under /tmp so there is always a possibility an attacker can exploit it. If you have LFI and a phpinfo page then this is 100% reliably exploitable – wireghoul Dec 16 '19 at 17:03

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.