CRE Loaded Session Fixation Vulnerability

[inetbiz]

Has this been reported in the CRE bug tracker, david? I don't see any activity this year.

[David M. Graham]

I have, on a development site, added session_regenerate_id to about 4 places (conditionally in one).  This seems to block the issue. 

Difficulties remain, this is a shallow defense at best - but a definite improvement over the current situation.

Once I have completed a code merge, I will migrate this to a live site for more active testing.  Then it will be released to the public.

I have reported this to us-cert and expect the vulnerability to appear in security advisories soon.

David

[zip1]

Another possible item that may help is :

file: application_top.php (both admin and catlog)

to above the line:
session_set_cookie_params(0, $cookie_path, $cookie_domain);

add:
 @ini_set('session.cookie_httponly', 1);

This will only allow the session info to be changed via a http request, which will block changing by javascript. The major problem is the browsers who actually support this The below information is from the php manual.

this works if the customer is using the browsers:
In Response to RC
>23-Apr-2008 04:45
>For anyone looking for which browsers support the httponly >flag, per my research:
>
>IE 6 SP 1 and higher.
>Firefox 3 and higher.
>Opera 9.50 and higher.

This method is better since session_set_cookie_params only support httponly since 5.x and iwll work with 4.2X installs of php.

[HoosierWeb]

putting this in the php.ini file seems to make the pci scan happy

session.use_only_cookies = 1
session.use_trans_sid = 0

[David M. Graham]

A security issue was recently brought to my attention by a vendor in the community - Jason at Hoosier Web Design (http://www.hoosierwebdesign.com).

During a security scan on one of his servers, he received a report that a sessions fixation issue exists in CRE Loaded 13.1.  I was able to confirm that this DOES exist, and continues to exist in CRE Loaded 6.3 as well.  I have not yet examined older releases, but I do expect these to contain the issue as well.

Here are the details.

To see the vulnerability, hit any CRE Loaded site with the URL:

http://yourdomain/index.php?osCsid=12345  or
https://yourdomain/index.php?osCsid=12345

View the form data in the page  using FireFox's web developer toolbar or other tool of your choice.  You will see that your session ID has been accepted.

This confirms the basic existence of the vulnerability.  Next question, how has the application handled it?

Descriptions of what the vulnerability is and approaches to manage session fixation (and hijacking, to which fixation is one gateway), can be found  at these locations:

http://shiflett.org/articles/session-fixation  and http://en.wikipedia.org/wiki/Session_fixation  as well as http://www.acros.si/papers/session_fixation.pdf


Login.php does NOT check for SSL state, and appears to only recreate the session if the SESSION_RECREATE key is set to true or yes.

further investigation notes forthcoming,