Can we hack a site that just stores the username as a session variable?

Question

I've developed my website that checks if the user is registered and creates a session variable with the username. It's all that is stored as a session variable. If I want to protect my pages (so that only registered users may see them), I check if the session variable is set. Is this secure? Or can you give a more secure method?

Answer 1

These articles appear to be quite useful in explaining the security concerns:

• http://www.sitepoint.com/blogs/2004/03/03/notes-on-php-session-security/
• http://phpsec.org/projects/guide/4.html
• http://www.sitepoint.com/article/php-security-blunders/

The first in particular seems to deal with several of the methods of session ID storage, and it appears the others cover certain ones in more detail.

Answer 2

If you store the username in the session then anyone who can create a valid session cookie for your site can inject the username and impersonate that user. This would be really bad if that user happened to have administrator privileges. There are a lot of things that you probably need to consider, but at a minimum you should be generating a random session key with a fixed or sliding expiration window and store that in your session cookie instead of the user name. You can then associate that key with the a particular session object on the server, the session object can contain the username for use in authorization. Your session cookie ought to be encrypted to make it harder to generate. These two things will go a long way in solving your problem.

Answer 3

Generally, the Session is server side, but If I somehow get the Session ID I can just hijack it.

I'd recommend at least storing either the IP and maybe also the User-Agent, and in case of mismatch, invalidate the Session.

Answer 4

Basically, you are fine with storing whatever you want in Session. The only caveats are:

• if you are not using secured connections (like SSL), the sessionId can be sniffed and hijacked. This is of no importance because the username and pass can also be hijacked, and you are subject to "man in the middle" attacks, etc. So basically, your system is fine and provides low security without SSL.
• In the articles on PHP they mention some concerns with shared hosting and session hijacking. I'm not sure if this is true, so I've posted a question here. Edit: This concern seems to be real, so you'll have to use one of the workarounds for storing session (e.g., database) if you use PHP.

In general, though, most of the security concerns mentioned (including XSS attacks) are not with storing stuff in Session but rather general security concerns. Storing userid -- or some encrypted form of the same -- in Session is generally quite secure.

Most importantly: if you were to use your own algorithm to generate a random cookie code for each user, that would no doubt have more security flaws (not being an expert) than the session-key generation algorithms of PHP, ASP.NET, Rails, whatever...

I could find a more appropriate Bruce Schneier quote, but this one will do, "No one can duplicate the confidence that RSA offers after 20 years of cryptanalytic review.”