Think of a session as an identity that differentiates customers. Sessions in many cases are transparent when you do your online shopping. They typically sent with a cookie from the server end to the client end. Where server is the web-store and client is the visitor's browser. The browser stores the session information when is sent by a cookie from the server and re-transmits this information with each new page load.

This identity or session must be unique, must be generated by the server and must be validated with every request the visitor makes. After long time studying and experimenting with the original MS2.2 framework, Asymmetric Software has advanced the session mechanism to make this unique identifier or session ID as secure as possible. Using a combination of two separate methods, one that was released earlier on in the osCommerce contributions section and was heavily criticized and another that was integrated with the I-Metrics Layer, the session data and information exchange between server and client is now properly established.

SESSION REGENERATION

The first method implemented due to session or identity duplication on March 2006. A problem that still exists with the original MS2.2 framework. Session regeneration changes the visitor's identity when he logs-in or when he creates an account. The aim of the module was to generate a new session under these two circumstances thus protecting the visitor's shopping cart, account details and eliminate headaches for merchants who had to get to the email level apologizing to their clients.

The problem here was that 2 or more visitors could see each others information, account details, shopping cart contents etc. The way the same session was exposed to multiple visitors was either due to incorrect configuration settings of the eshop, or due to merchant's mistakes when he updated the web-content or due to intentional session injection to exploit weaknesses in the core code.

Despite a year of presenting the duplicate session case in various posts across the MS2.2 osCommerce forums, session regeneration remains as infamous as it was before its first release. Instead, countless and pointless suggestions circulate including  "a shared server problem move to a dedicated one", "change the oscsid to a different string","truncate the sessions table", "set the session recreate switch on the admin", just to state few myths that suppose to rectify this issue. Even though other pages here have stated about the danger of not validating the user input properly, the situation remains as before. The session id key can be any type and yet the server will accept it, when using the stock MS2.2 and derivatives.

This session duplication situation was rectified by the session regeneration module (contribution #4112 in osC), so at least for customers who were doing their online shopping, the module could ensure uniqueness of the cookie or session appended with the URL following a login or create-account operations. The original osCommerce framework is perhaps one of the very few e-commerce engines available that can handle the visitor's identity either by appending it to a link or sending the session cookie. When properly used, this approach is a major advantage for a merchant's eshop.Not many engines allow the session via the URL making sites inoperable with hosts using shared SSL.

URL sessions can support e-shops that are hosted in a sharing SSL environment on a server where the regular catalog domain is different than the secure checkout procedure or any other script that handles sensitive customer information. Yet the eshop appears the same to the visitor. The drawback is that not everyone understands the implications. If the store is not configured properly to send cookies, the sessions will be appended with each URL. Ideally sessions should be conveyed with cookies wherever possible.

The way the session regeneration operates is by voiding the old session information from the URLs and cookies and securely generate a new identifier utilizing as much as possible the existing PHP and MS2.2 core functions to maintain compatibility between different PHP versions and stores with lots of custom features.  The information transmitted by the Session Regeneration was 3 different headers to cancel the old cookie generate a new one, maintain integrity of the session information and transfer the old session array data to the new one.

The problem with just regenerating a session and sending a single header, is that the old session is still active and likely stored in the database. Therefore the old session can be re-transmitted by the browser and accepted by the server in which case the customer information remains exposed as before. Just calling the session_regenerate_id() is ineffective. The old session id must not by accepted by the server end. An additional method was needed to ensure that and the I-Metrics Layer uses this methodology to do the session transfer and at the same time validate incoming session data.

SESSION PROPER HANDLING

With the introduction of the I-Metrics Layer, the session handling changed to a large extend, to ensure that sessions are unique and cannot be exploited. The first problem with the current MS2.2, MS3 and with all their derivatives we've seen, is that the incoming session is not validated against the database. It is accepted as is and with some newer versions of the MS2.2 framework and derivatives a filter is applied to sanitize the session string. The filtering process typically implemented, checks that the session string is alphanumeric, a major pitfall that goes against the PHP session related functions and documentation. It can break stores and leave security holes open. Sessions may include other characters not just alphanumeric ones. In addition several, so called URL and parameter validation modules we see over the contributions section, deployed a similar approach to blindly filter incoming parameters including the session string, where even if the session was to be properly structured and verified by the core functions, the contribution code breaks the session functionality stripping the so called "invalid characters". If in doubt read the PHP manual what are the valid characters a session generation contains instead of doing some patchwork:

Reference:
http://docs.php.net/manual/en/session.configuration.php
Sections: session.hash_function mixed and session.hash_bits_per_character

Therefore, if for some reason, (and there is none) we wanted to filter the session identifier we would had to first check how the server operates, identify the bits/character information and apply the equivalent algorithm to  sanitize the session id string by the appropriate characters. Characters like "," "-" are valid characters for session identifiers, yet they're stripped when passed through these filters. See code in catalog/includes/functions/session.php function tep_session_start

    $sane_session_id = true;

    if (isset($HTTP_GET_VARS[tep_session_name()])) {
      if (preg_match('/^[a-zA-Z0-9]+$/', $HTTP_GET_VARS[tep_session_name()]) == false) {
        unset($HTTP_GET_VARS[tep_session_name()]);

        $sane_session_id = false;
............

The truth is there is no need to implement a filtering process over the session string. Because the session itself is generated on the server end and not on the client end. Pretty much like the customer md5 password string is generated every time someone creates an account, so is the session, the string is random and extremely hard to predict. The only difference is that the session id, is generated directly from the PHP. All the server end has to do, is verify the session string against the session database records. Sessions are stored normally in the database (sessions table) when first generated.

Starting with the I-Metrics layer set of enhancements, we removed all the bad filtering and re-structured the code such that, incoming session information is validated against the database records. If no session exists, or if there is a mismatch, the web engine treats the request as a first time visitor or a so called landing page. We call this the first step of session processing where a fundamental session validation must ensue.

Another area the I-Metrics Layer addresses with sessions, is the parameter and order the incoming session is sent back by the visitor's browser. Session maybe transmitted via cookies or URLs ie: /GET parameters and with the original MS2.2 also via the /POST parameters. We need to ensure, that the session information propagated within the scripts, is consistent, not just correct. Intentionally someone may create 2 or 3 different sessions one for the cookie another for the /GET and another for the /POST global arrays and sent them back to the server end. If the script blindly accepts incoming sessions without a proper order it may bring all sorts of problems to the store's functionality.

To get around these issues while maintaining some level of compatibility with the original framework and older contributions, the I-Metrics Layer eliminated the /POST array as the means to transmit sessions for forms. Now to avoid conflicts between the /GET array and /COOKIE a specific sequence of events is deployed where the session cookie maintains always the highest priority. Furthermore parameters passed via /POST are not accepted at all if the session hasn't been started and consequently removing the possibility for a spider or visitor to use a form without a session.

Other modifications for session handling include; leaving the $SID variable initially empty and only if the PHP SID definiition is defined and loaded, to change its value. Various checks added, to separate cases where cookies or URL sessions as well as invalid sequence of session events were used and redirection methods were applied to avoid session exploits as much as possible.

The PHP session callback handlers were altered in many ways, to take care of cases where the server would not handle the sessions, introduced garbage collector configurable timeouts, added session variables pre-check so no variables need to go through the registration process if no session was started. In addition the I-Metrics layer deployes an enhanced version of the session regeneration module, increasing the session cookie and session data security measures for e-shops.

There is an archive for the sessions problem in case you want to try it your self.

http://demos.asymmetrics.com/pub/sessions.zip

The files included replace the default sessions on the RC 2x versions of osCommerce. They should fix problems for users where sessions are not working properly because the default code strips out some of the session characters and doesn't follow the PHP sessions. The code in the archive uses the database to validate sessions. It should also solve the intermittent session problems reported with osCommerce 2.3.1.