Session Management Library

Introduction

A session management library is used to manage multiple sessions. Sessions are used in web-application to store some user data. Since HTTP connections are connection-less, the application needs a way to associate all transactions to its user to make the application dynamic in nature. For e.g. take the scenario of an online marketing website selling some goods. This application has many customs and they do a lot of transaction. Since the HTTP connection is connection-less, the application cannot differentiate between each connection and cannot know what the user did previously. Hence sessions are used on top of the HTTP protocol to remember data about clients. In sessions, during the client-server handshake process, the server allocates an unique ID to the client. Usually client stores this ID in its cookies. After the first connection, the client can produce this ID to the server so that the server can pull records from the application about this user. This way the servers associate transactions with users in an application.

        With many users (each user can have multiple sessions and they might be using multiple devices to access the application) the task of keeping track of sessions, storing and retrieving data, expiring sessions, etc. become a challenging task. This is where "Session Management Library" steps in. Its sole purpose is to look and manage sessions in an application so that security risks can be mitigated from the abusive and careless use of sessions.

Problems with Sessions

There is no denying that sessions give applications huge amount of power. But with great power comes great responsibility. Hence its important to keep the sessions safe. Failing to do so creates security holes in the application so severe that security of the whole application can be compromised. There are many reasons to keep the sessions safe:

• Sessions represents a user identity. If these gets leaked, then an attacker can pose as a legitimate client and can ask server for user data.
• Several attacks such as "Session Hijacking" and "Session Fixation" persists.
• Sessions often are stored in cookies, and cookies can be stolen via several methods. Hence all cookie related attacks automatically affects sessions.
• Stolen sessions are very hard to detect by the system, because stolen sessions acts as normal sessions and there is no anomaly whatsoever. There are methods such as "User-behavior detection", but they are not very much effective until a strong anomaly is detected.

PHPSEC Session Management Implementation

In this library we have tried to eradicate all of the possible vulnerabilities inside sessions. To ease the process of session management, we have provided several simple functions which makes the task easy and more efficient to handle. These functions internally use a number of methods to handle session vulnerabilities. Each of those methods are over-viewed here in each paragraph.

Databases over cookies: The first issue that I would like to address is the use of cookies and its harmful effects. The server stores all the session data inside path defined under "session.save_path". But the session IDs are stored in client's browser, inside cookies. Its the client's responsibility to send this cookie to the server each time. Now every time the client sends this sensitive piece of information, there is a chance that this might be hijacked using some means. e.g. passive attacks, because in HTTP connections, nothing is encrypted. Therefore we decided to control this situation using databases to store session IDs instead of cookies. Also the session data is stored in databases instead in files and folders. This way the user does not have to send their IDs each time. The application itself can access session data using the user's username. The application can also create several sessions for user in the database and link them with user's username.

Session Timeouts: We have provided functions to delete a session after a certain period of time. This introduces a time-frame to attackers because after that time-frame, the stolen session ID will be destroyed. There are two ways to delete a session. First is Session Inactivity Timeout, where the session gets deleted if a user was not active for a certain period of time. Second is Session Expiry Timeout, where the session gets deleted once its maximum lifetime has reached.

Session Length and Randomness: With modern day computing power and advancement in parallel processing, its trivial to break a short string via brute-search. However a long string cannot guarantee your safety if its not random. Hence, we need long and cryptographically secure random strings to be able to defend against these kinds of attacks. In our library, we generate strings of length >= 32 which are also cryptographically random, thus making our session IDs safe from those attacks.

Session Refresh: Sessions can be refreshed in a number of events - such as user activity before time expires. Therefore we have provided functions to refresh a session. This makes the sessions as good as new by updating its "creation date" and "User Last Activity" time.

Session Rolling: Sessions are distributed to users as soon as they visit the application. However there are events within the application which can change the privilege level of the user. E.g. An anonymous user logs in. This event definitely changes the privilege level of the user. Now the user has access to more sensitive data before they were logged in. Most of the time, the session IDs are used to access data within the application which is logical because a session ID represents a user. Thus if sessions are not replaced at the time of these sensitive events, then an unprivileged session would be able to access data that it was not supposed to. So, this function "session rolling" is to be called whenever events like this happens. This function deletes the old session and copies that session's data to a new session. This ensures that the session IDs change every time a privilege promotion/demotion happens.

Session Management: With all the useful functions that makes our session implementation safe, we also have created other important functions to manage all the sessions. Some of these functions are to "delete a session", "delete all sessions related to a user", "get all sessions for a user from the DB", "GET/STORE session data from the DB" etc. With all these functions, the task of session management reduces only to a few lines for the developers.

Other Helpful Links:

• https://www.owasp.org/index.php/Session_Management_Cheat_Sheet