We have just been experiencing issues where multiple customers have reported security issues when trying to log in and checkout.
Customers report that after entering their own usename and password, they are granted access to the account dashboard, but then see someone else’s name and data. Somehow it appears as if the software mixes up login sessions. We have had multiple reports today.
We are running Magento CE 184.108.40.206. However we recently (a month or so ago) upgraded from 220.127.116.11 because we were experiencing the same issue.
This has behavior tends to happen after heavy bursts of site traffic. Sometimes when we post a sale (depends on the sale), we will get a spike in traffic which consumes most if not all of the servers resources. This is when we typically start getting reports that the store is mixing up customer login access. The reports seem to roll in after the spike in traffic starts to roll off. It is a hunch that the issue is related to the server load as a trigger before the Magento software starts the login collisions.
For reference. We have got around 15,000 visitors with in a two hour time line. In the control panel, the real-time server bandwidth graph pegs at 1.2MBytes per second for the first 15 minutes. It happened on several occasions using 18.104.22.168. This motivated us to upgrade hoping to resolve this issue. This is the first time we have seen the behavior since we have been using 22.214.171.124 for the last three weeks.
-Server resources Peg for 15 minutes
-Customer logs in
-Customer see another’s data after logging in.
-This occurs with Magento CE 126.96.36.199 and 188.8.131.52
-Using MemCached on the server in both instances
We have disabled our site and are researching this issue and hoping for some sort of a resolution soon.
Here are a few screenshots of my attempts to use your site this morning. As you can see, there are seven different names on the “Welcome” bar - none of whom are me. These are only a few of the ones that I’ve come across (the only ones I have screenshots of).
As for what would happen - I went to your page, and attempted to add some products to my cart. The site was very slow, which I assumed was just a traffic issue. When I proceeded to my cart, it would be someone else’s cart entirely with their products (and their name on the welcome bar). If I hit refresh, a whole new cart/account would come up. If I hit proceed to checkout, it would show someone else’s shipping information. I never did go past this point.
Quote that suggests problem is bigger than an accounts log in issue.
The problems I am encountering is that when I click on one to add it to my cart, it will take a while (green bar at the bottom showing that it is loading) and then when it does load, it will show other items in my cart that I didn’t put there. (I.e. I wanted to order an <product 1>, but it added <product 2>, and another) then when I tried to remove the ones that I didn’t want, it will remove all of them. The extras that it adds to the cart are different each time. Sometimes its just one extra, one time it had added up to 6 <products> (even changing the quantity). I have been exttra careful to make sure that it wasn’t just because I was impatient and clicking twice or something.
Hope that helps to solve your site problems! I haven’t logged in though, so I’m not sure about logging in issues.
Another thing to note: we are using multiple stores and have the SID in the URL because we have multiple domains that all check out to one secure URL. Checkout won’t work if we turn the SID off in the URL.
we have a similar setup
we’re running multi-site setup (4 websites). But each domain has its own ssl cert and checkout.
We dont have sessions ID’s in the url.
This is good to know. I will try and have a play with orders on the other sites and let you know if I see anything weird. Gotta be something with multi-site systems. I havent seen many posts about this issue. As i think most people dont see it happening
Making the above update did appear to fix this, however it broke a payment gateway (Sagepay) - but strangely enough not Paypal. So had to revert to default i.e.
Validate REMOTE_ADDR: No
Validate HTTP_VIA: No
Validate HTTP_X_FORWARDED_FOR: No
Validate HTTP_USER_AGENT: No
Since I am running multiple stores (on the the same domain) then I have to;
Use SID on Frontend: Yes
My best guess is that the SID is cached somewhere on Google or Yahoo and potentially a customer has followed this and picked up someone else\’s session (i.e.www.domain.com?SID=99123d60a14a80cd0c6a19922797a9ca40). Although I cannot replicate this.
Any thoughts on this, it would be greatly appreciated.