Doc #72345 [Ana]: session_start() is not subject to max_execution_time

Edit report at https://bugs.php.net/bug.php?id=72345&edit=1 ID: 72345 Updated by: yohgaki@php.net Reported by: maggus dot staab at googlemail dot com Summary: session_start() is not subject to max_execution_time Status: Analyzed Type: Documentation Problem Package: Session related PHP Version: Irrelevant Assigned To: yohgaki Block user comment: N Private report: N New Comment: For those who would like to mitigate DoS attacks by session lock. Minimizing locked period works. i.e. use session_start('read_and_close'=>1), use session_commit() as soon as you've finished updating $_SESSION. Drawback is you may accidentally update $_SESSION while it's not active. Be careful for this! Previous Comments: ------------------------------------------------------------------------ [2016-09-05 06:46:01] yohgaki@php.net Automatic comment from SVN on behalf of yohgaki Revision: http://svn.php.net/viewvc/?view=revision&amp;revision=339984 Log: Fixed Doc Bug #72345 and improve session security.xml ------------------------------------------------------------------------ [2016-09-03 20:53:10] yohgaki@php.net We have to make this a doc issue because signal handling in PHP is problematic. I'll update doc to encourage use of readonly sessions. ------------------------------------------------------------------------ [2016-08-27 07:19:15] yohgaki@php.net Thank you for reporting. It's possible attackers setup clients that exploit session locking mechanism to use all server processes/threads. Counter measure is difficult because "locks" are handled by save handlers. "lock" is implemented by save handler in various ways. Any lock mechanism in PHP could be exploited. i.e. It's not a session only issue. Can we handle timeout signal in the engine? ------------------------------------------------------------------------ [2016-07-14 13:00:46] maggus dot staab at googlemail dot com put the following code into a file called "experiment.php" and you can reproduce the issue. with my custom session files handler (see comment above) registered $handler = new FileSessionHandler(200); session_set_save_handler($handler, true); the queued up requests immediately fail. with the native php-session handler 20 apache workers are are bound with just 1 request. depending on how "slow" you simulate the first 8 workers, the things get very fast a lot worse as the apache nearly needs forever to fullfill all the requests. if (!empty($_GET['worker'])) { $worker = $_GET['worker']; echo "<xmp>"; echo "ID: ". $worker."\n"; $start = microtime(true); echo "ACQUIRE LOCK: ". $start ."\n"; try { session_start(); } catch (Exception $e) { var_dump($e->getMessage()); exit(); } $waited = ((microtime(true) - $start) * 1000); // simulate work $sleep = 500; if ($worker < 8) { $sleep = 5000; } usleep($sleep * 1000); // make sure the server needs to update the sess file after each request $_SESSION['worker'][$worker]++; $finished = ((microtime(true) - $start) * 1000); echo "FINISHED: ". $finished ."ms\n"; // highlight runs which were blocked by others // (so session_start() couldn't return immediately) if ($waited > 10) { echo '</xmp><span style="color:red">'; } echo 'BLOCKED FOR '. $waited .'ms'; return; } foreach(range(1,20) as $workerId) { echo '<iframe src="experiment.php?worker='. $workerId .'"></iframe>'; } ------------------------------------------------------------------------ [2016-07-14 12:56:50] maggus dot staab at googlemail dot com I created a custom FileSessionHandler class which works arround this (in my eyes php bug) using a non-blocking flock() call. https://gist.github.com/staabm/ce225d4b01d7b4e2560848646e13d6fc As anyone can easily DDOS any web-sapi based php application because of the blocking default-file-session-handler I hope for a fix at php-src though. ------------------------------------------------------------------------ The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at https://bugs.php.net/bug.php?id=72345 -- Edit this bug report at https://bugs.php.net/bug.php?id=72345&edit=1