As it turned out customers placing orders on his site were seeing other customers information. The implementation was using MySQL as the database backend. The client was obviously paranoid and wanted me to fully investigate the issue. This blog post will focus on investigating what is happening with the client's OSCommerce installation.
Before beginning on a client's work, always make backups. That way you have something to fall back on in case something goes terribly wrong.
cp -p -r domain.com/ domain.com.032006So I visited the store and found the session id of 344d....
Since most of the customers come from search engines I wanted to see what sessions ids are indexed in Google. So I performed a search
I found a couple of session IDs in the URLs.
So I narrowed my search to get broader results :)
This gave me 17,500 results with various session IDs and almost all results marked "Supplemental Result" which is bad.
I logged in to MySQL.
I searched for a sesion id found in Google results to see whether that same session id was currently stored in the active sessions table.
To my horror, it was.
WHERE `sesskey` LIKE CONVERT( _utf8 'e6abd8...'
USING latin1 )
Now we want to see whether we can recreate this session when visiting from Google
We visited the page and got yet another session id 46bf*
So I followed the link from Google and got the session id that was indexed in Google. So basically I had taken over the session.
So I added a product called Miami* and to my horrors the cart showed another product from a previous person in the basket. I had not added this product.
We also noticed the sessions were NOT being retained for any length of time. Upon revisiting the page from the same computer, a new session id was being generated. This means that if someone had added anything to their cart once they got a new session id, those items would no longer be in their cart.
To take matters further I asked my colleagues to follow the above steps and visit the site after going to Google and following the link with the same session id. When they entered the site, the cart showed those two products in their baskets when it should have showed none.
We recommended the client to make sure they do not have any hard-coded links on their store that have a session id in them.
These changes will ensure that even if a customer follows a link from Google or other search engine with the session id encoded, the store will not regard that session by closing it and issuing a new session id that will be used for order tracking / placement purposes. In addition, the session id will only be present in links on the first visit to the page. On subsequent pages, the session id won’t be in the links.
We tested this by commenting the changes and noticed that someone else’s products kept coming back into the shopping cart. Upon uncommenting, the products that we added successfully appeared.
So the problem is fixed.