Regression on session handling for security fix
After upgrading from 4.3.11 to 4.3.12, an embedded application (run as a TYPO3 extension) did not work anymore. After some research, I discovered it was due to the change introduced in #24456, which moved the call of "session_start()" from a place where it was only called on demand (when doing a challenge/response login) to a place where it is always being called (even on the frontend).
Two issues with this changes:
1) My embedded application for a misfortune also does a session_start. But it also includes lots of Objects into this session. The classes for this objects are loaded by the application before calling session_start(), so PHP can build the objects just fine.
But now when TYPO3 calls a session_start on every hit and very early: the classes of my applications are not loaded yet! Thus the session is filled with "__PHP_Incomplete_Class" objects! The application no longer works.
2) Another issue which happened after this change is that several customer sites began running over quota, simply because every FE hit (even from Google & Co) created new PHP session (files in phptmp). This was not so before and will cause annoyances for bigger sites, which are tuned for fast FE rendering explicitly without Cookies / Sessions.
In my situation the result is worse than the "security gain" obtained by this change. So please consider either reverting it again (also in 4.4 and 4.5) or apply it somewhere else.
Updated by Frederic Gaus about 10 years ago
The Patch is working for me.
This solves the following error in conjunction with TypoGento:
Fatal error: Mage_Core_Model_Session_Abstract::getMessages() [<a href='mage-core-model-session-abstract.getmessages'>mage-core-model-session-abstract.getmessages</a>]: The script tried to execute a method or access a property of an incomplete object. Please ensure that the class definition "Mage_Core_Model_Message_Collection" of the object you are trying to operate on was loaded before unserialize() gets called or provide a __autoload() function to load the class definition in XXX on line 215
Updated by Roland Hager about 10 years ago
We updated to 4.4.10 yesterday and run into exactly that issue. I would even consider it a severe vulnerability to a DoS attack. Since the network filesystem we are using for our multi server environment has a hard limit for the maximum number of files per directory our site was getting real slow after about two hours running the new version. A BE/FE-Login was not possible any more, because no new sessions could be made due to a filled up session directory.
It should be quite easy to generate loads of sessions on the serverside and depending on the filesystem used by the server causing issues related to quota or filesystemlimits. This way an attacker can prevent normal users from logging in to the BE and/or FE.
The good news: The provided patch seems to do the trick. No null-byte sessions per hit and the login still works -Thanks!
Updated by Christian Opitz about 10 years ago
I wrote an extension that is a middleware between Zend Framework and TYPO3 - since the call to session_start mentioned above, a later call to Zend_Session::start() rightly leads to this exception:
session has already been started by session.auto-start or session_start() Zend_Session_Exception thrown in file [...]Zend/Session.php in line 462.
The patch makes that this exception is not thrown when nobody is logged in but when someone is trying to log in it's there again. Could you pleeaase wrap the call to session_start() in a protected function so that it's possible to override it from a XCLASS? I provide a patch if you like...
Updated by Helmut Hummel about 10 years ago
The problem with the information disclosure was, that if a valid user was found the session_start() (which also sends headers) was called before noCacheHeaders are sent, while in all other situations (invalid username) session_start() is called after noCacheHeaders are sent.
In the initial approach (#24456) we made sure that the order was always the same by starting the session always before sending the noCacheHeaders.
As this obviously caused a lot of problems I now suggest to do it the other way around and send the noCacheHeaders in any case before we may start a session.