I’ve been looking into a legacy application with a web-based user interface. Given its age (nearly 10 years some parts) there’s a lot that needs updating and re-architecting, but I’m wondering about a small point regarding how user sessions work.
In a nutshell:
- The entire UI is served via HTTPS.
- Users are authenticated unremarkably by comparing username and password hash with values saved in a database.
- Upon authentication, a browser cookie is set, which contains two values that save the last top-level and second-to-top level section/module the user has accessed, an expiration date, and a value like “loggedin=true”. Upon logout, the cookie is reset with “loggedin=false”. There is no session token in the cookie.
- The first page loaded after authentication, as well as each subsequent page load, contains a JavaScript variable “sessionToken”, which is a base64 encoded string with various parts, some of which encrypted:
var sessionToken = "...." - Each navigation link generates a HTTP POST request, via a
<form>element and JavaScript event handlers, with the relevant variables passed into it behind the scenes, along with the sessionToken, which in turn is set again, identically, on the next page load. The user stays logged in if at the same time the cookie has “loggedin=true”, and the expiration time hasn’t elapsed. - Sessions expire after a configurable time. The expiry happens on the next click on a navigation item after the expiry has elapsed. I believe this is simply by comparing the last time the session token was written out in the backend, but maybe the cookie is used — I haven’t found this out yet. When sessions expire, the “loggedin” value in the cookie is flipped and the user redirected to the login page.
I’m not a security specialist, and have not seen this design before. I’d be interested to know what pitfalls and risks, if any, you can see in it. (Me, I have a bad feeling, but would like some more solid input.)
If this is a standard way in some corner of the web, I’d like to hear about it, too.
Ian, in his answer, has already pointed out that reliance of cookie values for indicating the authenticated nature of a user is bad. I’ll focus on the manner in which the session cookie is managed.
Session cookies/tokens are meant to be unique and they’re not meant to be divulged to other users. Use of HTTPS ensure that these cannot be sniffed on the wire, in your application. But, is it possible to guess the values of the session token? If so, you have a problem; modern application rely on a secure framework to generate the session cookies/tokens using a good PRNG. If your application does not enjoy a similar level of randomness, then assume that the session token could be easily inferred, leading to users being able to spoof other users.
Moreover, the use of encryption in certain parts of the session token is interesting. Is the decryption key for these parts securely managed? In other words, is the key hard-coded, or does it happen to be a single key per installation, or randomly generated with a short lifetime? If the key can be guessed, inferred or compromised in any manner, then you have more or less the same problem.
Use of encryption for the session key might also lend it susceptible to the padding oracle attack, but I’m not sure about this. More details would help.
I’m just guessing here, since I do not have the exact details of the algorithm, but mere use of HTTPS need not grant any sense of security. I’ve noticed session tokens that obey mathematical sequences in the wild.
Finally, the availability of a hard configuration limit for session duration and/or sliding window duration for expiry of the session token needs to be verified. Otherwise, it is quite possible for a compromised session to be alive as long as possible, sometimes requiring “physical” eviction of the attacker due to the nature of certain systems.
PS: Also verify the hash algorithm used for passwords; using a salt is good. MD5 is broken for all practical purposes.
Implications of using a custom session management mechanism
At first glance, the use of session tokens without the use of cookies appears to be without any significant problems, but one tends to lose a few security features that are available on most platforms – cookie flags. The secure and HttpOnly cookie flags reduce the risk of the cookie being sniffed on the wire (when sent by the client to the server), and also ensures that client-side code does not have access to the token, that could later be compromised by a XSS attack. So, using a session cookie is better than using a custom session token (with little or no peer review done on the implementation).