CloudInsidr

Cyber security, infotech

  • Subscribe!
  • Privacy Policy
  • Legal
  • Contact Us

Join us on Twitter: @CloudInsidr

Follow us on Twitter: @cloudinsidr
  • news & alerts
    • events
    • industry analysis
    • industry gossip
    • people
  • cloud, edge & co.
    • AWS
    • administration & orchestration
      • web servers in the cloud
      • mail servers
      • databases
  • cybersec & warfare
    • encryption
  • blockchain
Home cybersecurity and cyber warfare Maximize your PHP session security by fixing errors and closing the session adoption vulnerability that allows session fixation attacks
Maximize your PHP session security by fixing errors and closing the session adoption vulnerability that allows session fixation attacks

Cloud Insidr 2017-02-20 Leave a Comment

Maximize your PHP session security by fixing errors and closing the session adoption vulnerability that allows session fixation attacks

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

Filed Under: cybersecurity and cyber warfare, NGINX, php-fpm, web servers in the cloud Tagged With: NGINX, permissions, PHP 7, php-fpm, session, session adoption, session fixation

Leave a Reply Cancel reply

Your email address will not be published. Required fields are marked *

Subscribe

SSL/TLS Certificate Square (250 x 250)

Pearson Education (InformIT)

SSL/TLS Certificate Medium Rectangle (300 x 250)

Recent Posts

  • Upgrading from CentOS 6 to CentOS 7 and Beyond?
  • How To Figure Out Who is Signing In To Dovecot to Send or Retrieve Email
  • OpenSSH 9.9 Introduces Enhanced Quantum-Resistant Algorithms
  • OpenSSL 3.3 Final Release is now live!
  • How to Activate HTTP/2 with TLS 1.3 Encryption in NGINX for Secure Connections without a Performance Penalty
  • Is AWS sucking your budget dry? Strip it down to the nitty-gritty (without breaking stuff)
  • How to attach and mount an NVMe EBS volume on EC2
  • SELinux security contexts: correcting SELinux labels on a file system
  • Intel gobbling up Israeli Tower Semiconductor, Stock Goes Through The Roof
  • NGINX on AWS EC2: setting up a web server from scratch on a domain of your choice
  • Log4j RCE and mitigation techniques
  • Set up logrotate for Postfix

Symantec

Categories

  • administration and orchestration
  • alerts
  • AWS
  • Bitcoin
  • cloud, edge and everything in between
  • cryptocurrencies
  • cybersecurity and cyber warfare
  • databases
  • DNS
  • encryption
  • events
  • FinTech and InsurTech
  • homeland security
  • HTTP Security Headers
  • industries
  • industry analysis
  • industry gossip
  • Java
  • Linux
  • mail servers
  • networking
  • news
  • NGINX
  • people
  • php-fpm
  • reviews
  • SELinux
  • tips and tricks
  • Uncategorized
  • web servers in the cloud

Tags

AMI AWS AWS EBS Azure certificate cipher suites cryptography cyber defense cybersecurity cyber security Diffie-Hellman DNS DNS over HTTPS Dovecot EBS EC2 email encryption Fedora HTTP/2 HTTPS IBM letsencrypt Linux logs MariaDB MFA MySQL NGINX OpenSSL permissions php-fpm PHP 7 postfix RegEx Route 53 RSA SELinux SQL SSH SSL TLS TLS 1.3 TLS vulnerabilities WordPress

Archives

  • January 2025
  • November 2024
  • October 2024
  • May 2024
  • January 2023
  • March 2022
  • February 2022
  • December 2021
  • December 2020
  • November 2020
  • September 2020
  • January 2020
  • November 2019
  • August 2019
  • July 2019
  • April 2019
  • December 2018
  • October 2018
  • September 2018
  • August 2018
  • June 2018
  • May 2018
  • April 2018
  • February 2018
  • December 2017
  • November 2017
  • October 2017
  • August 2017
  • April 2017
  • February 2017
  • January 2017
  • November 2016
  • September 2016
  • August 2016
  • July 2016
  • March 2016
  • February 2016
  • January 2016
  • December 2015
  • November 2015
  • October 2015
  • September 2015
  • July 2015
  • February 2015

Recent Comments

    Wicked fast Networking (With a Government Clearance to Boot)

    ©2022 CybrAnalytiqa OÜ

    • Content purchasing and syndication