PHP Session Lost, suhosin unchangeable

Question

On a Ubuntu 12.04, Apache2, PHP5 server, suhosin extension is installed. (phpinfo page)

This is a dedicated server with the latest security updates through automatic updates.

I have created the following test script (test script without setting suhosin conf)

session_start();

$error = 0;
ob_implicit_flush(true);

if ($_GET['is'] == 'set'){
    session_set_cookie_params ( '3600','/','.theparentingplace.com',false, false );
    error_log( "Old 'suhosin.session.encrypt': " . print_r( ini_set('suhosin.session.encrypt', 0), true) );    
    error_log( "Old 'suhosin.session.cryptdocroot': " . print_r( ini_set('suhosin.session.cryptdocroot', 0), true) );    
    error_log( "Old 'suhosin.cookie.cryptdocroot.': " . print_r( ini_set('suhosin.cookie.cryptdocroot', 0), true) );
}



if (empty($_SERVER['HTTPS']) && !$error){
    $_SESSION['test'] = 'abc';
    header('Location: https://'.$_SERVER['SERVER_NAME']
     .'/http_https_session_test.php');

}else{
    if ($_SESSION['test'] == 'abc'){
        print "Success." . $_SESSION['test'];
    }else{
        print "Fail.". print_r($_SESSION['test'],1);
    }
}

The error log shows:

[Sat Oct 26 20:00:23 2013] [error] [client 103.29.31.35] Old 'suhosin.session.encrypt': 
[Sat Oct 26 20:00:23 2013] [error] [client 103.29.31.35] Old 'suhosin.session.cryptdocroot': 
[Sat Oct 26 20:00:23 2013] [error] [client 103.29.31.35] Old 'suhosin.cookie.cryptdocroot.'

Other SO posts suggest to check session.cookie_secure and session.http_only parameters. Both are off on this server. Further, I tried to implement turning off specific suhosin settings, or to turn off suhosin altogether with suhosin.simulation=On I tried this both in php.ini

This script returns fail. If the script is run with the is=set parameter, it fails to set the parameters (test script 2)

On another dedicated server the test script work fine, ie. the https url picks up the session variable, however this server is Ubuntu 10.04.

Any idea what to do next?

Is there any particular reason you're trying to set `suhosin.session.cryptdocroot` three times? — Brian North, Oct 26 '13 at 06:20
Thanks for picking this up, the first one is supposed to be suhosin.session.encrypt and the other ones are cookie.cryptdocroot, session.cryptdocroot. I have updated the script on the live site and retested. Problem is I can't turn any of these settings off. Why? — jdog, Oct 26 '13 at 06:26
session_set_cookie_params() after session_start() makes no sense. It's session_start() that writes the header setting the session ID cookie. — Walter Tross, Oct 27 '13 at 00:12

score 1 · Answer 1 · answered Oct 26 '13 at 06:33

1

The options you're trying to change (e.g, suhosin.cookie.cryptdocroot) affect things that Suhosin does before your script starts running. As such, it doesn't make sense to change them at runtime - you'll need to set them in php.ini or similar.

answered Oct 26 '13 at 06:33

Thanks, they are set in php.ini - but they may not be the reason why I'm loosing the session in between. – jdog Oct 26 '13 at 06:53

score 1 · Accepted Answer · answered Oct 27 '13 at 18:53

I broke this myself recently when I merged the HTTP and HTTPS VirtualHost file into one and changed the apache server to MPM-ITK for security reasons.

In the merged VirtualHost file

<VirtualHost 120.138.18.91:80>
    ServerName www.theparentingplace.com

    DocumentRoot /var/www/www.theparentingplace.com/joomla
    CustomLog /var/log/apache2/www.theparentingplace.com-access.log   combined
    ErrorLog /var/log/apache2/www.theparentingplace.com-error.log

<IfModule mpm_itk_module>
    AssignUserId www-theparentingplace www-theparentingplace
</IfModule>

    RewriteEngine On
    RewriteCond %{QUERY_STRING} ^.*=(ht)|(f)+(tp)+(://|s://)+.*(\?\?)+
    RewriteRule .* http://gggooooooglleee.com/ [R,L]

    <FilesMatch "images/\.(asp|php|php5|pl)$">
        Deny from all
    </FilesMatch>
</VirtualHost>

<VirtualHost 120.138.18.91:443>
ServerName www.theparentingplace.com
    DocumentRoot /var/www/www.theparentingplace.com/joomla

CustomLog /var/log/apache2/www.theparentingplace.com-ssl-access.log combined
ErrorLog /var/log/apache2/www.theparentingplace.com-ssl-error.log

<IfModule mpm_itk_module>
    AssignUserId www-theparentingplace www-theparentingplace
</IfModule>

SSLEngine on
SSLCertificateFile /etc/apache2/ssl/www.theparentingplace.com.crt
SSLCertificateKeyFile /etc/apache2/ssl/server.key
    SSLCertificateChainFile /etc/apache2/ssl/www.theparentingplace.com.ca.crt

BrowserMatch ".*MSIE.*" \
    nokeepalive ssl-unclean-shutdown \
    downgrade-1.0 force-response-1.0

   RewriteEngine On
   RewriteCond %{QUERY_STRING} ^.*=(ht)|(f)+(tp)+(://|s://)+.*(\?\?)+
   RewriteRule .* http://gggooooooglleee.com/ [R,L]

   <FilesMatch "images/\.(asp|php|php5|pl)$">
       Deny from all
   </FilesMatch>
</VirtualHost>

I had forgotten to add the

<IfModule mpm_itk_module>
    AssignUserId www-theparentingplace www-theparentingplace
</IfModule>

block to the secure site section, hence the https site was not able to read the session files.

Thanks to Brian North who got me onto the idea of checking if I can force the session_id for https (I was not able to with the wrong configuration)

score 0 · Answer 3 · edited May 23 '17 at 11:57

0

session_start() must be called before you output anything - so in your if ($_GET['is'] == 'set') block, the print calls are preventing your session from starting. Without that, $_SESSION['test'] will never persist long enough for your if ($_SESSION['test'] == 'abc') block to test true. EDIT: All headers must be sent before any output (which is the reason session_start() must be called before as well) - so your print calls in the ini_set block are still blocking your header( 'location' ... ) call. if you need to see what ini_set() returns, output it's value to the error log by error_log( "Old 'suhosin.session.encrypt': " . print_r( ini_set('suhosin.session.encrypt', 0), true) ); for each configuration. Or cache the results and print them after any possible headers are sent.

Transferring between http and https will also lose your session variables, since they start separate sessions. This question should cover the rest of your problem. Session lost when switching from HTTP to HTTPS in PHP

For your suhosin... ini settings, ini_set will return the previous values - so if the ini configuration was previously false, you'll get false, even if the call was successful.

edited May 23 '17 at 11:57

Community

1
1

answered Oct 26 '13 at 06:34

Brian North

1,398
1
14
19

Thanks, have moved session_start to top. The 3 suhosin settings are actually set to Off in php.ini, so you might be quite right there. I may be chasing the wrong thing with suhosin, the problem I want to solve is that the session is lost between http and https. – jdog Oct 26 '13 at 06:53
If those settings in ini.php are off, then the `ini_set()` function will return false for them. For persisting the same session between http and https, the problem is PHP and your server treats them as starting separate sessions. The question/answer I included in my last edit addresses this problem. Basically, you have to pass the session id manually when you make the switch. – Brian North Oct 26 '13 at 07:02
I've seen that answer, however it is simply not correct. Unless additional parameters are set, Session variables are not lost between HTTP and HTTPS. I have this running on another server, where the session is not lost: http://www.acgedu.com/http_https_session_test.php P.S. Seen your last comment, but not correct IMO – jdog Oct 26 '13 at 07:03
Your `session_set_cookie_params` call has the `$domain` parameter as `''` - what happens when you pass it ".theparentingplace.com"? `session_set_cookie_params ( '3600','/','.theparentingplace.com',false, false );` – Brian North Oct 26 '13 at 07:22
No change, see edited question for double checking what I understood – jdog Oct 26 '13 at 07:28
The next step I would try is see if any session vars are carried over even between http -> http and https -> https. If they aren't, then the problem lies in starting your session altogether, not just transferring it from http -> https. – Brian North Oct 26 '13 at 07:42
There is actually a working E-Commerce site on this domain with login and basket. All is working, just the switch to https on checkout stopped a couple of days ago. I'm pretty sure that qualifies as a working session. – jdog Oct 26 '13 at 08:28
@jdog, the basket is probably implemented with values stored in a cookie, not as a session! The reason is that this way you can clear sessions after a short while, and leave the basket with the customer for a long time. – Walter Tross Oct 27 '13 at 00:50
Hi Walter, no. Virtuemart 1.x uses its own session cookie – jdog Oct 27 '13 at 01:29

PHP Session Lost, suhosin unchangeable

3 Answers3