Need EMERGENCY help--customers seeing others info

[milauskas]

Okay, I've written a few posts now about various aspects of the same problem. It's got to do with sessions, spiders, etc. The result of session IDs getting mixed up and customers being able to view other customers' info is the problem I need to address immediately.

 

Is there a way to fix this problem RIGHT NOW? Here's what I am thinking.

 

If my client's store is at domain.com/catalog and the problem is that spiders may have indexed pages like so:

 

domain.com/catalog/product_info.php?products_id=68&osCsid=e24e3208d475f0a69be7e68a97fb0d7d

 

will changing the directory name of the store (e.g., "catalog") to something else allow me to fix this?

 

Are session IDs tied to the store name (whether it's "catalog" or something else)?

 

For example, if I rename my catalog directory to, say, "catalog2" (and make the necessary changes to the code to reflect this) am I not in effect creating a brand new store that has not been indexed (spidered)?

 

If that's the case, then anyone who logs in won't see another's personal info since the session IDs that have been indexed by the bots won't apply to this "new" store. Is this correct?

 

I'm desperate to try anything. The client keeps getting calls from people who either see someone else's info or they have items in their cart that they didn't choose. Of course I want to prevent spider sessions altogether, but am I on the right track here as far as a quick fix?

 

Please let me know, anyone, so that I can make the changes necessary. Thanks!!!

[tigergirl]

Have you installed the security update 060817? security update 060817

Also, in Admin you should set "Prevent Spider Sessions" to True to stop the bots indexing session ID which as you found is a security risk. The knowledge base article will help: security proposal

best of luck, not sure how to help you in the short term.

 

Tiger

[Jack_mcs]

Okay, I've written a few posts now about various aspects of the same problem. It's got to do with sessions, spiders, etc. The result of session IDs getting mixed up and customers being able to view other customers' info is the problem I need to address immediately.

 

Is there a way to fix this problem RIGHT NOW? Here's what I am thinking.

 

If my client's store is at domain.com/catalog and the problem is that spiders may have indexed pages like so:

 

domain.com/catalog/product_info.php?products_id=68&osCsid=e24e3208d475f0a69be7e68a97fb0d7d

 

will changing the directory name of the store (e.g., "catalog") to something else allow me to fix this?

 

Are session IDs tied to the store name (whether it's "catalog" or something else)?

 

For example, if I rename my catalog directory to, say, "catalog2" (and make the necessary changes to the code to reflect this) am I not in effect creating a brand new store that has not been indexed (spidered)?

 

If that's the case, then anyone who logs in won't see another's personal info since the session IDs that have been indexed by the bots won't apply to this "new" store. Is this correct?

 

I'm desperate to try anything. The client keeps getting calls from people who either see someone else's info or they have items in their cart that they didn't choose. Of course I want to prevent spider sessions altogether, but am I on the right track here as far as a quick fix?

 

Please let me know, anyone, so that I can make the changes necessary. Thanks!!!

If you are sure it is links that are causing it, or even if you just have links with SID's that you want to remove, then you should install the session remover and session regeneration contributions. But the problem can also be caused by other things, like using file to store cache instead of the database (option in the configure files) or using a tmp directory for cache that is not private to the site. This is one of those problems that is not always immediately fixable. You just have to try various things until you find the problem.

 

Jack

[Guest]

The worst thing I've seen was a store owner hard-coding a link to his store with the session appended in an announcements page and inside a products_description's text.

 

Just one hard-coded link with a session inside your site and your store can have critical problems.

[milauskas]

Thanks, Jack. I think I was able to--at least for now--solve the most pressing problem by renaming the catalog directory. Since any links containing the session ID contain the catalog directory in their address, these old links are no longer valid.

 

I did try installing the session regeneration contrib but it didn't work (at least I didn't think it did). I made another post about that on the forums. Have you used the session regeneration contrib? Has it worked for you?

[milauskas]

I think this was indeed the root of the problems. Since this jsut seemed to happen recently I wondered what might be causing it. Of course I've learned a lot about spider sessions in the last week, but I found that my client had given a link to one of their products to another site. The link contained the session ID. I now think that it was people coming from this other site, using the link with the session ID that started causing all the problems.