PHP presents "Failed to write session data" error at random times

Question

PHP presents "Failed to write session data" error at random times

Navigation

#1 by (5 votes)

1

I have a site that is fully functional and has a failure rate of 0.0037%, but all errors are the same.

Unknown: Failed to write session data (files). Please verify that the current setting of session.save_path is correct (/tmp)

I looked for some information on PHP session handling error and also on Failed to write session data (files) . But both solutions did not solve the problem, in addition the questions apparently referred to a persistent problem, I mean a problem that was presented at all times.

In my case this problem occurs for a short time, for an average of two minutes and does not affect all users, because there are few data in the logs. In the last 24 hours it only occurred between 5:52 p.m. and 5:54 p.m., after which there was no error of the same type and everything continues to function normally. Because it is a small space of time, I can not test the site right now or do other verifications.

I wanted to know what might be causing this problem.

Is there a limit of files per folder or some limitation in creating new sessions, which then blocks writing? Is there a PHP process (or even CentOS itself) that alters the permissions of the folders or is it blocking writing?

I have not tried to change the folder where the sessions are saved, but I will do this soon.

php session centos

asked by anonymous 12.10.2016 / 10:15

1 answer

Allow login by email, CPF or CNPJ Woocommerce Problems with csrf_token laravel

score 5 · Accepted Answer

I discovered the problem, which was one of the things I suspected but thought it was not the problem.

I use some vulnerability testing software, although they do not accuse errors I started to think that such errors were related to such tests, because errors were presented in "big quantity" after 2 ~ 3 hours of testing are started at random times!

The problem I discovered is related to the use of "invalid" characters as the cookie value of SESSION , this causes the reading problem of SESSION .

Testing the problem:

If the session cookie (by default has PHPSESSID name) has a value of type !@#$!%!@#$@#!!!#!#!@#% it will accuse the problem:

Unknown: Failed to write session data (files). Please verify that the current setting of session.save_path is correct (/tmp)

To change the value of the cookie you can use the EditThisCookie extension.

If you want, you can use Javascript to change the cookie:

var nome = "PHPSESSID";
var valor = "!$!@$!@@#!@#!@#";

document.cookie = nome+"="+valor;

Correction:

To cause the problem requires that some curious (being optimistic) have changed the value of the cookie used to set the session.

The correction I thought was as follows:

$sessao = "PHPSESSID";

if(isset($_COOKIE[$sessao]) && !preg_match('/^[A-Za-z0-9,-]+$/', $_COOKIE[$sessao])){
     unset($_COOKIE[$sessao]);
}

session_start();

This would be a generic, not an ideal solution.

First is to know exactly which characters would be valid, this depends only on this:

session.hash_bits_per_character = 5

If it is 4 it will be [a-f0-9] . If it is 5 it will be [a-v0-9] . If it is 6 it will be [A-Za-z0-9,-] .

Read the documentation at link

Second is the number of valid characters, PHP by default generates sessions of 26 characters, this depends on the COMBINATION of the following values:

session.hash_function = md5
session.hash_bits_per_character = 5

This combination will result in a higher or lower session value, so you will need to test to change the number of REGEX characters based on the number of characters.

Read the answer at link

In my case I am EXACTLY using this:

if(isset($_COOKIE['_sid']) && !preg_match('/^[a-v0-9]{52}$/', $_COOKIE['_sid'])){
     unset($_COOKIE['_sid']);
}