Sessions initialized for all users

I have a candidate patch that fixes this: https://gist.github.com/azito122/503c9fc5006c71922e94ae014db597dc

Basically we just attach session_start to wp_authenticate instead of wp_loaded. I also had to throw in a session_start() call in the logout action to prevent an error.

This bug just took down a customer’s server by using up over 1.75 Million inodes on the file system. The server ran out of disk space with 80% of its disk space free.
The root cause was wp-cassify and it binding its session start to init, as described in this post.

I see it’s been updated to wp_loaded which is the exact same problem.

The root issue is that the top level plugin page (plugins/wp-cassify/wp-cassify.php) is loading up an instance of the public class *and* the admin class on every single page load. This (among other things) creates a PHP session, which not only breaks cachign (bad) but can fill up the entire filesystem by using up all the inodes (also really bad, crashes the entire server).

In the top level wp-cassify.php we have:

$GLOBALS['wp-cassify'] = new \wp_cassify\WP_Cassify_Plugin();
$GLOBALS['wp-cassify']->init_parameters(
        $wp_cassify_network_activated,
                $wp_cassify_default_xpath_query_to_extact_cas_user,
                $wp_cassify_default_xpath_query_to_extact_cas_attributes,
                $wp_cassify_default_redirect_parameter_name,
                $wp_cassify_default_service_ticket_parameter_name,
                $wp_cassify_default_service_service_parameter_name,
                $wp_cassify_default_gateway_parameter_name,
                $wp_cassify_default_bypass_parameter_name,
                $wp_cassify_default_cachetimes_for_authrecheck,

The WP_Cassify_Plugin::init_parameters() method calls the session_start that creates all the problems.

This is easily fixed becgause you only need a session for users that have submitted the login page! Only if someone *submits* the login form do you need a session. All other instances should have no session started, so that caching can work, and so that the disk is not filled with zero byte session files.

This bug means that any site with wp-cassify on has zero caching active, which leads to overloads and downtime. the fact that every bot HTTP hit can create a php session leads to a DDoS vulnerability and site outages. Please fix!

Hi Damien,

Thank you for your explanation. But, i’m not sure. But i think i needs to keep early PHP Session initialization to process CAS Client gateway mode. (=> Automatic login if user has already authenticated by CAS). And to implement this mecanism, i’ve ported phpCas implementation based on PHP Session.
For the moment, I have not found any other way to implement this feature.

Take a look at this and you will understand that i said.
https://github.com/apereo/phpCAS/blob/master/source/CAS/Client.php#L1515

Best regards.