After deploying a recent Magento security patch – SUPEE-10570 – I was receiving reports from fellow staff and customers that valid product pages were returning a 404 response. Oddly enough, if you logged into your customer account the page would be rendered just fine.
In a bit of a panic, I did pulled the major reset lever – a full reindex and cache flush of the full page cache and objects. And all was good!
A random Magento oddity that will not reoccur – right? Wrong. It happened again. And again. And then vendors pointed it out to us as well…
Additionally our internal staff seemed to be getting logged out of the Magneto admin at undesired times – like when submitting an order for a customer in the Magneto Admin…
Contents
Magento Installation
This issue was happening on a Magento Enterprise 1.14.2.0 fully patched site, including SUPEE-10570 v2 (though v1 is affected by this as well).
I have not looked into the Magneto 2 code to see if the same issue exists there.
SUPEE-10570 Bugs
The root bug with this patch is that it is setting a timestamp in the visitors session which is used to validate if a malicious person is trying to hijack session cookie. The timestamp will expire based on the session lifetime settings set in the Magento for the frontend and admin.
If that timestamp is in the past, Magento will invalidate the session. But it is not handled gracefully… And worse yet, not all timestamps are updated as expected.
In the users session stored on the server there are several namespaces – each of which have the session validation timestamp stored to them. But not all pages use all of the namespaces. So it’s possible to get a stale timestamp stored in your session.
Worse yet, if you are using the Full Page Cache (from Enterprise), the block of code that should update one of the namespaces – reports (for tracking page view stats) – isn’t called if the page is stored in the fullpage cache. For this reason it’s very easy for a visitor to have a stale timestamp in their session, which will result in an exception thrown in your server logs (exception.log) and a 404 page being returned to the visitor. Worse yet, that 404 response is now stored in the full page cache for future visitors to find!
This same scenario plays into the Magento admin as well. I haven’t dug as deep into how that is all affected but am aware that it is and that the below fix resolves the issues.
Exception Thrown in exception.log
When Magento detects a stale timestamp from the Reports module, it throws the following exception:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 | 2018-05-09T10:04:18+00:00 ERR (3): exception 'Mage_Core_Model_Session_Exception' in /var/www/vhosts/mysite.com/html/app/code/core/Mage/Core/Model/Session/Abstract/Varien.php:421 Stack trace: #0 /var/www/vhosts/mysite.com/html/app/code/core/Mage/Core/Model/Session/Abstract/Varien.php(236): Mage_Core_Model_Session_Abstract_Varien->validate() #1 /var/www/vhosts/mysite.com/html/app/code/core/Mage/Core/Model/Session/Abstract.php(84): Mage_Core_Model_Session_Abstract_Varien->init('reports', NULL) #2 /var/www/vhosts/mysite.com/html/app/code/core/Mage/Reports/Model/Session.php(43): Mage_Core_Model_Session_Abstract->init('reports') #3 /var/www/vhosts/mysite.com/html/app/code/core/Mage/Core/Model/Config.php(1354): Mage_Reports_Model_Session->__construct(Array) #4 /var/www/vhosts/mysite.com/html/app/Mage.php(463): Mage_Core_Model_Config->getModelInstance('reports/session', Array) #5 /var/www/vhosts/mysite.com/html/app/Mage.php(477): Mage::getModel('reports/session', Array) #6 /var/www/vhosts/mysite.com/html/app/code/core/Mage/Reports/Model/Product/Index/Abstract.php(158): Mage::getSingleton('reports/session') #7 /var/www/vhosts/mysite.com/html/app/code/core/Mage/Reports/Model/Product/Index/Abstract.php(176): Mage_Reports_Model_Product_Index_Abstract->_getSession() #8 /var/www/vhosts/mysite.com/html/app/code/core/Mage/Reports/Model/Event/Observer.php(148): Mage_Reports_Model_Product_Index_Abstract->calculate() #9 /var/www/vhosts/mysite.com/html/app/code/core/Mage/Core/Model/App.php(1339): Mage_Reports_Model_Event_Observer->catalogProductView(Object(Varien_Event_Observer)) #10 /var/www/vhosts/mysite.com/html/app/code/core/Mage/Core/Model/App.php(1318): Mage_Core_Model_App->_callObserverMethod(Object(Mage_Reports_Model_Event_Observer), 'catalogProductV...', Object(Varien_Event_Observer)) #11 /var/www/vhosts/mysite.com/html/app/Mage.php(448): Mage_Core_Model_App->dispatchEvent('catalog_control...', Array) #12 /var/www/vhosts/mysite.com/html/app/code/core/Mage/Catalog/Helper/Product/View.php(135): Mage::dispatchEvent('catalog_control...', Array) #13 /var/www/vhosts/mysite.com/html/app/code/core/Mage/Catalog/controllers/ProductController.php(132): Mage_Catalog_Helper_Product_View->prepareAndRender(827, Object(OnePica_Catalog_ProductController), Object(Varien_Object)) #14 /var/www/vhosts/mysite.com/html/app/code/core/Mage/Core/Controller/Varien/Action.php(398): Mage_Catalog_ProductController->viewAction() #15 /var/www/vhosts/mysite.com/html/app/code/core/Mage/Core/Controller/Varien/Router/Standard.php(254): Mage_Core_Controller_Varien_Action->dispatch('view') #16 /var/www/vhosts/mysite.com/html/app/code/core/Mage/Core/Controller/Varien/Front.php(172): Mage_Core_Controller_Varien_Router_Standard->match(Object(Mage_Core_Controller_Request_Http)) #17 /var/www/vhosts/mysite.com/html/app/code/core/Mage/Core/Model/App.php(354): Mage_Core_Controller_Varien_Front->dispatch() #18 /var/www/vhosts/mysite.com/html/app/Mage.php(684): Mage_Core_Model_App->run(Array) #19 /var/www/vhosts/mysite.com/html/index.php(83): Mage::run('default', 'store') #20 {main} |
Long Standing Additional Bug Identified By This Issue
It seems to me that the report function of Magento that reports product view counts is not working as desired when the Full Page Cache is enabled. As mentioned above, that block of code is not called when a page is stored in the Full Page Cache, thus the counter is never updated…
Steps to Recreate the 404 Product Page Bug
- Enable the Full Page Cache in the Magento Admin
- Set the session Cookie Lifetime to a low value for testing like 60 (1 minute)
- Clear the full page cache
- Visit a product page (it should render as expected)
- Visit a category page
- Wait until the session Cookie Lifetime has lapsed – wait 60+ seconds based on the above suggested settings
- Visit any product page (except that visited in step 4) – a 404 response is shown to the customer.
- This 404 response is stored in the full page cache – as will be verified by step 8 below.
- View the exception.log file to notice an exception thrown – exception ‘Mage_Core_Model_Session_Exception’ in /var/www/vhosts/mysite.com/html/app/code/core/Mage/Core/Model/Session/Abstract/Varien.php
- Open a different browser/session and visit the same product page as step 7
- a 404 response is shown to this now new visitor because the page is stored in the full page cache.
Magento Support
I have brought this issue to the attention of Magento Support. It’s my understanding that they are working on a resolution and I will certainly update this post when I know more. But honestly their responses are rather vague and I have already implemented a working solution, so I have put that ticket on the sideburner a bit. They never did acknowledge if they can recreate the issue or not oddly enough… but have said they are working on my ticket…
Source of the Bug
The source of the bug is this bit of code added by patch SUPEE-10570:
1 2 3 4 5 6 7 8 9 10 11 | ## File: app/code/core/Mage/Core/Model/Session/Abstract/Varien.php ## Lines: 465-472 if ($this->useValidateSessionExpire() && isset($sessionData[self::VALIDATOR_SESSION_EXPIRE_TIMESTAMP]) && $sessionData[self::VALIDATOR_SESSION_EXPIRE_TIMESTAMP] < time() ) { return false; } else { $this->_data[self::VALIDATOR_KEY][self::VALIDATOR_SESSION_EXPIRE_TIMESTAMP] = $validatorData[self::VALIDATOR_SESSION_EXPIRE_TIMESTAMP]; } |
This is where Magento checks the timestamp. When Magento returns false there can be undesired, depending on what namespace called the validate() function.
Mitigating the Session Timeout Bug
Mitigation is simple – just comment out / remove the problematic lines of code.
I personally don’t suggest modifying core files – as does any good Magneto developer. For that reason, you should copy the entire file to the local path:
1 | app/code/local/Mage/Core/Model/Session/Abstract/Varien.php |
NOTE: Because this a an abstract file you do need to copy the entire file – not just the method you are overriding.
In that local file you can then comment out these lines and all will be resolved. That said, this is a mitigation – NOT a Magento approved/supplied fix.
Magento intended to add this step of validation for security reasons. I don’t personally feel this really helps much of anything in terms of security, but I’ve never claimed to be a security expert either – I’m a developer. Also, if/when Magento does publish a solution to this issue we will likely need to remove this mitigation, so keep in mind that implementing this may require additional maintenance in the future.
