Session Crossover

[james-siddall]

I currently have turpentine installed on several websites and on the odd occasion the session ID generated by the VCL matches one already generated. This is resulting in customers being logged in automatically on someone else's account.

Is there a reason why we can't increase the frontend cookie length over 32 characters? And if not, how do we stop the session collisions from occurring?

[miguelbalparda]

@james-siddall would you mind adding how did you solved your issue for future reference?

[james-siddall]

At the moment I'm looking into whether the session validation settings under System -> Config -> Web fix the issue. They have on my test instance however I have avoided these as ebizmarts SagePay gives a warning with these settings enabled:

The module will not be able to receive payments unless you match System > Configuration > GENERAL > Web > Session Validation Settings with this image (http://bit.ly/YLr4PG)

I emailed ebizmarts and they believe they shouldn't cause an issue. Placing a test payment works just fine with those settings on, and session collisions no longer cause an issue unless I'm on the exact same IP/browser etc.I'll be testing this with live payments tomorrow.

There is the problem that if a session collides the cached content is returned, so if the original user had something in their basket, the header will show x products in your basket for the new collided session. But if you browse to the basket you get redirected as it is empty once the session validation kicks in when the request hits Magento. I can live with that for now with how rarely this happens. As long as it stops logging people in to other peoples accounts.

[james-siddall]

The session validation settings do fix the security side of the problem, so users cannot be logged on to someone elses account. However it does create the issue whereby the ESI blocks are now empty when a session collides.

This is most obvious on the header block where the cart is normally injected over ESI. The session gets validated and in Mage_Core_Model_Session_Abstract_Varien an exception is thrown in the public validate() method. Because it is ESI the cookie doesn't get deleted so the problem persists until the user browses to a page that hits Magento.

So is there a way to increase the session ID length to reduce the chance of session collisions?

[james-siddall]

To add more to this... SagePay iframe with ebizmarts module doesn't work with session validation settings on, only the direct method does. So creating a much longer session ID is the only way I can see of resolving this.

Is there any reason it is currently limited to 32 characters?

[aricwatson]

The Kount fraud detection modules cause problems when session keys are over 32 characters. See #275 for more information about this.

You might test with the current devel branch, which contains code to reduce the number of sessions generated by turpentine, and so should reduce the chance of a session collision like this. Specifically Miguel's PR #846 adds two different options to fix formkey/session issues.

[james-siddall]

I'll give the devel branch a go then. As for the kount fraud, I take it as long as I don't use that 3rd party extension I can increase the session ID length to whatever I want?

[aricwatson]

As for the kount fraud, I take it as long as I don't use that 3rd party extension I can increase the session ID length to whatever I want?

I believe so. If you don't mind, please let us know how it goes!

[james-siddall]

I have doubled the session ID length in uuid.c and have had to increase the uuid_buf variable to 100 in version-3.vcl. This hasn't caused me any issues so far in testing and makes the chance of a collision much more unlikely.

For anyone interested in turning on session validation as well when using sagepay iframe I have had to override Mage_Core_Model_Session_Abstract_Varien::_validate() and return true when the sgps module is called. Not ideal but it means the session is validated everywhere else, so if there is a collision (however unlikely) it won't cause an issue.

[lisandroc]

Do you think that this could cause that all browsers get the same cart? When someone adds a product every cart is modified. Every user get the same cart.
I dont know why is happening or hoa to solve it

[aricwatson]

Do you think that this could cause that all browsers get the same cart? When someone adds a product every cart is modified. Every user get the same cart.

No, I don't think so - if there's a session collision, then two users might get the same cart or be logged into the same account, but I don't think everyone would end up seeing the same cart.

[lisandroc]

Thank you!!! Probelm Solved: we saw that our crawler & Varnish had the same IP address and it was the cause.