Jump to content
  • Checkout
  • Login
  • Get in touch

osCommerce

The e-commerce.

[Contribution] Session Regeneration


Guest

Recommended Posts

Session regeneration generates a new session id when the customer logs in or creates an account.

 

This contribution eliminates problems with sessions recorded by spiders as the identifier is recreated for visitors during the login/create-account process. It also eliminates problems with duplicate sessions being used by different customers simply because everytime someone logins to his account the session ID changes while the cart contents are preserved.

 

Contribution URL:

http://www.oscommerce.com/community/contributions,4112

Edited by enigma1
Link to comment
Share on other sites

  • Replies 84
  • Created
  • Last Reply

Top Posters In This Topic

Also few other notes not listed with the current documentation of v1.00

 

- Required PHP version where this contribution will have effect >= 4.3.2

- Links that are build prior to tep_session_recreate function call will not include the correct session ID. So if you have contributions/scripts installed that manipulate the URLs in the application_top.php you may have to modify them accordingly.

- The back button of the browser maintains a history with the old sessions on the client end. The navigation history mentioned in the document refers to the navigation class of the osc not that of the browser.

- If you have other scripts/classes/functions that store some sort of history with sessions those they need to be modifided too. Mosts tests were done with the default osc files.

Link to comment
Share on other sites

one question...i am curious what does this improve on the setting recreate sessions in the osC admin?

 

( the setting can be found here Configuaration>>Sessions>>Recreate Sessions and this is the description: Recreate the session to generate a new session ID when the customer logs on or creates an account (PHP >=4.1 needed)

Link to comment
Share on other sites

one question...i am curious what does this improve on the setting recreate sessions in the osC admin?

 

( the setting can be found here Configuaration>>Sessions>>Recreate Sessions and this is the description: Recreate the session to generate a new session ID when the customer logs on or creates an account (PHP >=4.1 needed)

 

sounds the same.

 

Still, even if a spider catches a session id and even if that page is indexed with it, the chance that that session id is still active by the time the index appears on the search engine's result pages are next to none.

Treasurer MFC

Link to comment
Share on other sites

one question...i am curious what does this improve on the setting recreate sessions in the osC admin?

the default recreate session does not generate a new identifier. It destroyes and rebuilds the session yet the identifier remains the same.

 

Still, even if a spider catches a session id and even if that page is indexed with it, the chance that that session id is still active by the time the index appears on the search engine's result pages are next to none.

What the active has to do with anything? You have the same identifier published all over the web. Anyone who clicks the link of a page with the session id appended can potentially use it throughout the checkout process. So just consider two customers coming from urls published with the id, shopping about the same time. It will cause a problem.

 

If you use cookies exlusively you do not need this contribution.

Link to comment
Share on other sites

the default recreate session does not generate a new identifier. It destroyes and rebuilds the session yet the identifier remains the same.

What the active has to do with anything? You have the same identifier published all over the web. Anyone who clicks the link of a page with the session id appended can potentially use it throughout the checkout process. So just consider two customers coming from urls published with the id, shopping about the same time. It will cause a problem.

 

If you use cookies exlusively you do not need this contribution.

 

They have to be shopping at the same time, using a link with the same session id.

 

But then they will share all session variables like language, currency and even the shopping cart and as such see eachothers cart contents before you recreate anything when they sign in.

 

I doubt they would checkout under those circumstances.

Treasurer MFC

Link to comment
Share on other sites

probably they won't checkout, but it can cause confusion and security concerns if customers see something like that. It is not good for the merchant. Also a lot of people on this forum (and elsewhere) they have a problem with their new site and then they post a link including the sid. SE here are active continuously so the sid is likely published and may stay there for long time.

Link to comment
Share on other sites

probably they won't checkout, but it can cause confusion and security concerns if customers see something like that. It is not good for the merchant. Also a lot of people on this forum (and elsewhere) they have a problem with their new site and then they post a link including the sid. SE here are active continuously so the sid is likely published and may stay there for long time.

 

All true but my point is that the strange cart behaviour and security concern, if it occurs, is already there before your facility is activated and no customer will be aware of the fact that it will be rectified once they sign in.

Even if you state an explanation to that effect, I doubt they would understand.

 

so in my opinion the best solution is still to

 

-prevent SE's from starting sessions (spiders.txt)

-use the 301 permanent redirect contribution for SE's which enter with a session id

-and ofcourse don't post links with session id's here, that is asking for trouble.

Treasurer MFC

Link to comment
Share on other sites

All true but my point is that the strange cart behaviour and security concern, if it occurs, is already there before your facility is activated and no customer will be aware of the fact that it will be rectified once they sign in.

Even if you state an explanation to that effect, I doubt they would understand.

 

so in my opinion the best solution is still to

 

-prevent SE's from starting sessions (spiders.txt)

-use the 301 permanent redirect contribution for SE's which enter with a session id

-and ofcourse don't post links with session id's here, that is asking for trouble.

 

 

or, just brainstorming here, maybe invoke your facility if a request comes in with a session id and the referer is from outside your site-space.

Then you may assume that the session id was picked up outside of your site and should be regenerated.

Treasurer MFC

Link to comment
Share on other sites

All true but my point is that the strange cart behaviour and security concern, if it occurs, is already there before your facility is activated and no customer will be aware of the fact that it will be rectified once they sign in.

Even if you state an explanation to that effect, I doubt they would understand.

 

so in my opinion the best solution is still to

 

-prevent SE's from starting sessions (spiders.txt)

-use the 301 permanent redirect contribution for SE's which enter with a session id

-and ofcourse don't post links with session id's here, that is asking for trouble.

 

without installing the contribution, the security issue is not just a concern. Sensitive information like name, address, email even payment details can be exposed and harvested by outsiders.

 

So for instance consider this scenario

1. Customer searches for product-X, finds it on the search engine (with the sid appended) then he clicks "add to favorites" in his browser. Now the sid is stored in his computer.

2. He goes straight to create an account with the store (many stores hard-code a links to create account or login page even when loged in), not paying attention to the shopping cart contents.

3. While doing that his information is exposed as the session remains the same.

4. If another guest comes in (or a bot that just harvested the sid from the SE) can now cache the customer's sensitive information.

 

In this scenario it is hard to figure out what happened and how such information was exposed. And it may take long time before the merchant or customer realizes it, especially with high traffic sites.

 

Also I understand what you're saying about the sid from visitors using the cart at the same time the contents will be mixed. But with this contribution sensitive information will not. For me it's at least a step towards better security. For the other points you mentioned 1,3 they're fundamental. For point-2 I have my concerns as I do not know the details what the SE algorithms is in each case and how they treat redirections. (like lowering the PR of the site or how they update their own database of search results).

Link to comment
Share on other sites

without installing the contribution, the security issue is not just a concern. Sensitive information like name, address, email even payment details can be exposed and harvested by outsiders.

 

So for instance consider this scenario

1. Customer searches for product-X, finds it on the search engine (with the sid appended) then he clicks "add to favorites" in his browser. Now the sid is stored in his computer.

2. He goes straight to create an account with the store (many stores hard-code a links to create account or login page even when loged in), not paying attention to the shopping cart contents.

3. While doing that his information is exposed as the session remains the same.

4. If another guest comes in (or a bot that just harvested the sid from the SE) can now cache the customer's sensitive information.

 

In this scenario it is hard to figure out what happened and how such information was exposed. And it may take long time before the merchant or customer realizes it, especially with high traffic sites.

 

Also I understand what you're saying about the sid from visitors using the cart at the same time the contents will be mixed. But with this contribution sensitive information will not. For me it's at least a step towards better security. For the other points you mentioned 1,3 they're fundamental. For point-2 I have my concerns as I do not know the details what the SE algorithms is in each case and how they treat redirections. (like lowering the PR of the site or how they update their own database of search results).

 

well, 4 I don't see as spiders do not cache login and accont pages if you set robots.txt right.

 

301 redirects are a perfect way to redirect spiders to new pages and away from old ones.

 

but you can also just do this:

 

if ( (isset($_GET[tep_session_name()])) and (!stristr($referer,HTTP_SERVER))) {

unset($_GET[tep_session_name()]);

}

Treasurer MFC

Link to comment
Share on other sites

I prefer not to have a robots.txt file unless you want to move a bunch of code in the .htacess. The reason is simple. Spiders can see the robots.txt but so outsiders and bots can experiment with the login, create_account, contact_us forms. So you have to put a bunch of code in the .htaccess to go around it ie restricting access to the robots.txt file for visitors.

 

Instead of the robots.txt you could do something simple in your application_top.php

 

  if( $request_type == 'SSL' && $spider_flag ) {
// Do redirect here.
 }

 

that would take care of spiders indexing secure pages.

 

how and where do you initialize the $referer variable in your snipset?

Link to comment
Share on other sites

I prefer not to have a robots.txt file unless you want to move a bunch of code in the .htacess. The reason is simple. Spiders can see the robots.txt but so outsiders and bots can experiment with the login, create_account, contact_us forms. So you have to put a bunch of code in the .htaccess to go around it ie restricting access to the robots.txt file for visitors.

 

Instead of the robots.txt you could do something simple in your application_top.php

 

  if( $request_type == 'SSL' && $spider_flag ) {
// Do redirect here.
 }

 

that would take care of spiders indexing secure pages.

 

how and where do you initialize the $referer variable in your snipset?

 

 

Trying to restrict access to robots.txt sound a little paranoid to me.

They do not need to read that file to find your filenames and folders.

 

 

 

I use :

 

if ($spider_flag) exit();

 

 

 

the $referer is set in application_top just after this:

 

ini_set('session.cookie_domain', $cookie_domain);

}

 

 

like this:

 

$referer = strtolower(getenv('HTTP_REFERER'));

Treasurer MFC

Link to comment
Share on other sites

Trying to restrict access to robots.txt sound a little paranoid to me.

They do not need to read that file to find your filenames and folders.

I use :

 

if ($spider_flag) exit();

the $referer is set in application_top just after this:

 

ini_set('session.cookie_domain', $cookie_domain);

}

like this:

 

$referer = strtolower(getenv('HTTP_REFERER'));

 

I see, if you're worrying they will find them through the sitemap for instance you can also change the links in the html_output.php if the spider flag is on for SSL pages. That should take care of the links pointing to a non-redirected page. But just having it in application_top no matter what the redirect will take place for spiders.

 

Now for the referer, for example I may block it when I go do some shopping. So it will show empty (or maybe I will put some funny name like "calculator" to see what happens). And the code you posted earlier will always unset the session name so my shopping cart won't work with sessions.

Link to comment
Share on other sites

I see, if you're worrying they will find them through the sitemap for instance you can also change the links in the html_output.php if the spider flag is on for SSL pages. That should take care of the links pointing to a non-redirected page. But just having it in application_top no matter what the redirect will take place for spiders.

 

I have no idea what you are saying here.

 

Now for the referer, for example I may block it when I go do some shopping. So it will show empty (or maybe I will put some funny name like "calculator" to see what happens). And the code you posted earlier will always unset the session name so my shopping cart won't work with sessions.

 

Nonsense as you cannot overwrite the referer once browsing the site.

 

Even if you could and would go thru the trouble of trying, then you do not deserve a session.

Treasurer MFC

Link to comment
Share on other sites

They have to be shopping at the same time, using a link with the same session id.

 

But then they will share all session variables like language, currency and even the shopping cart and as such see eachothers cart contents before you recreate anything when they sign in.

 

I doubt they would checkout under those circumstances.

 

This can and does happen, just look here:

http://www.oscommerce.com/forums/index.php?showtopic=23532&hl=

 

or here:

http://www.oscommerce.com/forums/index.php?showtopic=200311&hl=

 

or here:

http://www.oscommerce.com/forums/index.php?sho...s+bleeding+over

 

There are a bunch of post like this, As a matter of fact I am trying to fix this issue myself right now, because the customers HAVE checked out under these conditions. Thankfully this isn't a big problem, but out of 3000 orders in 2 different store it's happened about 3 times so far.

Edited by Steel
Link to comment
Share on other sites

The Problem with Hijacked Sessions and accounts getting combined.

 

 

How it?s happening:

 

Google (or any other search engine) starts a session, indexes it, and then displays it on their search engine site just as the example above showed. It also lists the Session ID in the link that it started, even if it was hours, days, or even weeks ago!

 

 

Customer ?A? (we?ll call him JOHN) goes to Google and does a search for a ?BLUE CAR?. A link for ?examplewebstore.com? comes up. Now look at the URL for the link

 

http:// examplewebstore.com /catalog/product_info.php?products_id=345&osCsid=b7f635beafc3f8bfdd538815cd4d514

 

Pay Attention to the Session ID: osCsid=b7f635beafc3f8bfdd538815cd4d514

And

Pay Attention to the Product ID: products_id=345

 

 

NOW, Customer ?B? (we?ll call him FRED) goes to Google and does a search for a ?RED CAR?. A link for ?examplewebstore.com? again comes up. Now look at this link.

 

http:// examplewebstore.com /catalog/product_info.php?products_id=789&osCsid=b7f635beafc3f8bfdd538815cd4d514

 

Notice the Same Session ID: osCsid=b7f635beafc3f8bfdd538815cd4d514

And

Notice the Product ID: products_id=789

 

If you notice the URL for the link for the ?RED CAR? it?s almost identical to the link for the ?BLUE CAR?. The only difference is that that although the Product?s ID portion is not the same, the Session ID is a perfect match!

 

If seems as if the way a session ID works is that the last person to actually SIGN IN using a particular Session ID Now becomes the default person who is assigned that ID. This is so the next time that they come back and log in, their account will pop up and the same Session ID will be restored.

 

(Note: This can and will also happen if the 2 customers click on the same link for the same item as well. It doesn?t have to be different products.)

 

The Problems that it can cause:

 

 

Situation 1.

 

Customer ?A? John comes along, does his search, sees the Google link, clicks on it and then ends up resuming the session that Google had started. Once he signs in, while using this session ID, it now becomes associated to his account. Now let?s say he checks out, completes the transaction and then logs off. Then customer ?B? Fred comes along and clicks on a Different Google link (OR EVEN THE SAME LINK) with the same Session ID, and at this point, if he were to SIGN IN, Fred would now have that exact same Session ID now assigned to his account instead of Johns.

 

This might not seem like that big of a deal and some people might think Ahhhhhh what?s the matter with that happening?it?s not causing any harm? Well in situation 2, I will show you.

 

Situation 2.

 

Customer ?A? John comes along, does his search, sees the Google link, clicks on it and then ends up resuming the session that Google had started. Once he signs in, while using this session ID, it now becomes associated to his account. Now let?s say, this time he adds a few things to his cart and leaves. When customer ?B? Fred comes along and clicks on another Google link with the same Session ID, not only does he resume John?s cart, but if he were to SIGN IN, the Session ID, that was first assigned to Google and then to John, would be now once again be reassigned to Fred?s account. Fred would unknowingly take over John?s cart completely.

 

Now in the worst case situation?

 

Situation 3.

 

Customer ?A? John comes along, does his search, sees the Google link, clicks on it and then ends up resuming the session that Google had started. Once he signs in, while using this session ID, it now becomes associated to his account. This time however he sign?s in, adds a few things to his cart, and is browsing around when customer ?B? Fred comes along and clicks on another Google link with the same Session ID. If Fred does this while John is still logged in under this Session ID, Fred is now ALSO signed in under John?s account at the exact same time as John and Fred doesn?t even have to SIGN IN himself at all! He has total control over John?s account.

 

 

The Result:

 

This is one way that accounts are getting mixed up. Fred places his order under John?s account, changes the billing and Ship to info and completes the transaction. Meanwhile John contacts the store wanting to know why some ?Fred guy? has an order under his account. Or, Fred emails asking about his order, but it?s no where to be found, because the order was placed under Johns account and not his own.

Link to comment
Share on other sites

Hi steel, yes some of these scenarios are addressed by installing the contribution. What amanda was saying was it will not help before the login or create account process. So in other words if you have 2 visitors the shopping cart can still be mixed up because they're using the same id from a search engine.

 

However during login or create account the session id will change, so this will protect the privacy of the customer and of course all sensitive information. If you want to enhance it further you could deploy the referer modification as she mentioned (or do another session recreate with a redirection to the same page). This should take care of the links coming from search engines with the identifier appended right from the start.

Link to comment
Share on other sites

Hi steel, yes some of these scenarios are addressed by installing the contribution. What amanda was saying was it will not help before the login or create account process. So in other words if you have 2 visitors the shopping cart can still be mixed up because they're using the same id from a search engine.

 

However during login or create account the session id will change, so this will protect the privacy of the customer and of course all sensitive information. If you want to enhance it further you could deploy the referer modification as she mentioned (or do another session recreate with a redirection to the same page). This should take care of the links coming from search engines with the identifier appended right from the start.

 

 

I just installed the contrib and nothing changed. I even looked at the files included and did notice a difference on the navigation_history.php file that was different from the instructions:

 

2.1 Locate the following code:



function unserialize($broken) {



Add above it the following:



//-MS- Add session regeneration

function update_session() {

  $name = tep_session_name();

  $session_id = tep_session_id();

  for ($i=0, $n=sizeof($this->path); $i<$n; $i++) {

	if(isset($this->path[$i]['get'][$name]) && tep_not_null($this->path[$i]['get'][$name]) ) {

	  $this->path[$i]['get'][$name] = $session_id;

	}

	if(isset($this->path[$i]['post'][$name]) && tep_not_null($this->path[$i]['post'][$name]) ) {

	  $this->path[$i]['post'][$name] = $session_id;

	}

  }

}

//-MS- Add session regeneration EOM

But in the included file, instead of being above it, it is below it.

 

So I tried that instead...still nothing. It did not change the ID at all. I tired re-logging in and refreshing the screen too and still nothing.

 

Any Thoughts?

 

Also, in case this helps,

I do not have the Register Globals Contrib installed as it is still turned on by my Host.

 

Thanks Again

Steel

Link to comment
Share on other sites

one other note. The referer unset on the _GET array, amanda mentioned earlier likely will not work in all cases and can cause problems. Couple of reasons.

 

1. If the customer comes into the store from an external link and presses refresh on the browser the same session will likely pass over and after the refresh this exact session will propagate to the other links. (because the session id will stay on the address bar of the browser).

2. A problem arises for secure/non-secure pages where the server url is different. The referer will not match the session and the cart contents will be lost.

 

Both points are in case you want to unset the session from the _GET array.

If instead you call tep_session_recreate when the referer is different, it should maintain the cart contents and generate a different session id. This should cover both cases mentioned above.

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Unfortunately, your content contains terms that we do not allow. Please edit your content to remove the highlighted words below.
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...