When the server can’t write to the session data directory, if will use /var/cache/nginx/fastcgi_temp/ and complain in the error log. You don’t want any of these errors, but a setting considered insecure will not even be reported as such. Here is how to bolster your PHP 7 session security with NGINX and php-fpm.
1. First things first: fix session errors
Error messages located in /var/log/nginx, as far as it concerns lack of write access to the session directory, may look something like this:
2017/02/19 02:54:53 [warn] 10265#10265: *81744 an upstream response is buffered to a temporary file /var/cache/nginx/fastcgi_temp/1/40/0000000401 while reading upstream, client: 123.123.123.123, server: www.cloudinsidr.com, request: "GET /content/feed/ HTTP/1.1", upstream: "fastcgi://127.0.0.1:9001", host: "www.cloudinsidr.com", referrer: "" 2017/02/19 02:57:58 [error] 10265#10265: *81774 FastCGI sent in stderr: "PHP message: PHP Warning: Unknown: open(/var/opt/remi/php70/lib/php/session/sess_57aj23cdh4geatuecs2nloql21, O_RDWR) failed: Permission denied (13) in Unknown on line 0 PHP message: PHP Warning: Unknown: Failed to write session data (files). Please verify that the current setting of session.save_path is correct (/var/opt/remi/php70/lib/php/session) in Unknown on line 0" while reading upstream, client: 123.123.123.123, server: www.cloudinsidr.com, request: "GET /content/wp-login.php HTTP/1.0", upstream: "fastcgi://127.0.0.1:9001", host: "www.cloudinsidr.com", referrer: "somereferrerhere"
In the above snippet, the server has already given away the location of its session directory:
/var/opt/remi/php70/lib/php/session
All you have to do now is fix the permissions.
To figure out correct permissions on the session directory using php-fpm, you need to look up the group shared by your pools. This setting is defined in the config file of the pool (think of the pool as a group of websites sharing the same socket or port number and permissions—basically sharing some rather relevant security parameters).
To figure out the location of the settings file, ask systemctl for the status of php-fpm and look for the path specified for the master process in the output of this command:
systemctl status php70-php-fpm
You should see something like this:
├─29146 php-fpm: master process (/etc/opt/remi/php70/php-fpm.conf
Therefore, the location of your pools’ config files is this directory:
/etc/opt/remi/php70/php-fpm.d/
If your pools are configured correctly, each of them should run with the user permissions of the owner of the website’s document directory and nginx as the group.
Here is your fix for the session directory:
chown -R root:nxinx /var/opt/remi/php70/lib/php/session
Restart php-fpm and nginx and the error should be gone for good. To verify this, visit your site and compare the log using:
tail /var/log/nginx/error.log
against the current server timestamp obtained via:
timedatectl
Done. No, wait. By default, your PHP sessions are not secure. You can protect your server from session fixation via session adoption using strict mode.
2. Prevent session fixation by closing the session adoption vulnerability
The session.use_strict_mode in your server’s php.ini file specifies whether the module will use strict session id mode. This mode is disabled by default as of this writing. Don’t believe it, check it for yourself:
# grep -i session.use_strict_mode /etc/opt/remi/php70/php.ini session.use_strict_mode = 0
By enabling this mode, you will ensure that the module no longer accepts uninitialized session ID. If the server receives an uninitialized session ID from a browser, the server will send a new session ID back. The strict mode protects your applications from session fixation via a vulnerability known by the name of session adoption.
Edit your php.ini:
nano /etc/opt/remi/php70/php.ini
Comment out the default and replace it with the correct setting:
; session.use_strict_mode = 0 session.use_strict_mode = 1
Restart:
# systemctl restart php70-php-fpm; systemctl restart nginx