Web Application - Cookie Expiry

Question

We are using a web application on cloud. I need a small clarification. We are using Perl with Apache. I see a following issue here for the below scenario. I need some inputs of whether this is most vulnerable or not? Scenario:

Login user to webapp.
remember the home page URL post login.
process: cookie gets set along with value.
save the cookie and the value.

Logout from web browser.
create the same cookie with the same value before logout.
hit the home url.
it bypasses the authentication mode.

The cookie expires after 20 minutes.

Most worrying factor is, even when I transfer the cookie to some other browser and try hitting the post login url, the authentication is bypassed.

I would like to know how vulnerable this is and how severe if this is most vulnerable.

Answer 1

You need memory. If the server does not remember who clients are and when they were last authenticated, and instead trusts the clients for keeping track of themselves, then the clients are in position to fool the server. What you describe (saving and then resetting the cookie) is called, in all generality, a replay attack. To see things conceptually, with cookie expiration, you are expecting the potential attacker to be graceful enough to forget some sensitive data, where not forgetting it would imply some gain for the attacker.

This leads to two main ways to avoid the issue:

1. Have the server remember the time of last authentication for each user, and enforce expiration, regardless of whether the client browser did expire the cookie, or not.

2. Encode in the cookie the expiration date, so that the server can check it. This is offloading the server memory onto the clients; to make it safe (because the client could alter his cookies in order to extend his session lifetime), you then need some cryptography, namely add a MAC computed with a secret key that the server knows but tells nobody (in particular, clients don't know it).

Since cryptography is full of lethal traps, you are encouraged to apply the first kind of solution. This is mostly a matter of adding a column in your table of users, in your database (I assume that you have a database on the server); this will be cheap.

Cookie expiration is not reliable anyway, even in non-hostile contexts, because some users don't set their computer clock correctly. Some are off by several hours (e.g. they are in the wrong time zone), and some are off by several years (they just don't care).

Answer 2

There are many ways in which a session management mechanism can fail and this could lead to severe security risks.

As a good practice you should:

• Use HTTPS, so that the information in the cookies could not be intercepted in transit.
• Set the secure flag for the cookies, so that they are not sent over unencrypted connections.
• Set the HTTPOnly flag for the cookies, so that they could not be read using JavaScript
• Ensure that the session identifier (the value in the cookie that identifies a valid user session) is not easy to predict. Use large random strings for this purpose.
• Ensure that the session identifier is changed when the user starts a new session (logs in), to prevent session fixation
• A session expiration mechanism should be implemented on the server. Do not trust the user for this job.
• When the user logs out, invalidate the session on the server, so that even if an attacker attempts to use the identifier, it would not be accepted by the server.

From your description, your aplication fails to meet the last point in the list above. You should check to see if the other points are satisfied. The sum of all the vulnerabilities in the application is the one that offers you a general view of how secure/vulnerable you are.

You should take into account that by exploiting the problem you have described, one may be able to access an user account without credentials. How bad is this in the context of your application? Could this malicious user access sensitive data, place orders, etc? For one application this may have a great impact, for another one it may be less important.

For further reading check out: OWASP Session Management Cheat Sheet

Answer 3

At a minimum, the cookies should keep track of where the user was connecting from and invalidate on logout (ie, the record of the session should be expired in the DB). Ideally, HTTPS should be used to protect the cookie in transit, but if security isn't that critical overall for the site, expiring the cookie session after both a time limit and logout and limiting it to a given IP will do a minimal job of preventing casual abuse in the way you described. It won't stop a Man in the Middle from being able to hijack the session if they can prevent the logout, or from being able to do stuff while the user is logged in, but it at least would limit it to MITM attacks as opposed to any old person that happens to get (or guess) the cookie. Also, if you are choosing your own session keys, make sure they are big and random so as not to simply be guessed.

I must reiterate that best practice is HTTPS for all credential exchange, including session cookies, but I also wanted to give an approach that is better if you don't have HTTPS as an option.