PHP Session hosting is prone to vulnerabilities

The following content is intended for developers who use the PHP session_set_save_handler hosting mechanism to manage PHP sessions. Assume that PHP session management is managed through open, close, pick, dump, clear, and gc functions. There is no problem with the gc recovery mechanism of PHP sessions. The problem is that gc recovery is not performed and

The following content is intended for developers who use the PHP session_set_save_handler hosting mechanism to manage PHP sessions. Assume that PHP session management is managed through open, close, pick, dump, clear, and gc functions. There is no problem with the gc recovery mechanism of PHP sessions. The problem is that gc recovery is not performed and

The following content is intended for developers who use the PHP session_set_save_handler hosting mechanism to manage PHP sessions.

Assume that PHP session management is managed through open, close, pick, dump, clear, and gc functions. There is no problem with the gc mechanism of PHP sessions. The problem is that there is no gc mechanism, and the session is outdated.

In PHP applications, session management can all rely on the traditional gc mechanism for recovery. However, when the concurrency of a project is higher, the gc recovery probability is higher. For databases (or IO) it is a huge load, so we will increase the gc recovery base (ini_set ('session. gc_pisor ', xxxx);). This is not the focus of this article.

When trying to manage a SESSION, the actual purpose is to reduce some drawbacks of the php session mechanism (to save important user information in the $ _ SESSION variable). Secondly, it also helps us better grasp and manage the Sessions of the entire system.

A standard design, session data itself, will design a lifecycle for it. When the user's client holds the session_id and the session is processed, the session is deemed invalid. When the user logs on again to maintain the session connection with the server.

$ SessName = "MY_APP_SID ";
Session_name ($ sessName );
Session_start (); // => the hosted open and pick functions are called immediately.

For an open function:

Function open ($ sessId ){
$ Sess =/* obtain session data based on $ sessId */;
If ($ sess-> isValid () {/* check whether the session is valid */
Return $ anyVal;
}
Returnfalse;
}

The open function reads the sessId held by the client and the value of the SESSION (the value in $ _ SESSION). In the middle, PHP internally runs $ anyVal for session_decode () returned to $ _ SESSION.

When the isValid of a session returns false, We need to regenerate the session id and notify the client to update it. PHP provides us with such a function: session_regenerate_id (), but when to use this function is the key to the entire problem. As a seamless switch between the server and the client, the key step is to secretly write the newly generated sessId into the record container (Database, memory or I/O) During dump ), however, the dump function serves as the end of the PHP running process. The header has been output and you cannot rewrite the header. Or simply put, the PHP code we write every day is executed through the open-> dump process regardless of the length. When the session mechanism runs to the dump process, we have no choice but to turn around.

The solution to this problem is that when session_start is initially executed and the session is initially started, session_regenerate_id can be executed, but a global monitoring is required (at this time, js is very memorable, but php cannot ).

$ SessName = "MY_APP_SID ";
$ IsRegenerateId = false;
Session_name ($ sessName );
Session_start (); // => the hosted open and pick functions are called immediately.
If ($ isRegenerateId)
Session_regenerate_id ();

In the open function, it is used to notify $ isRegenerateId whether it has changed:

Function open ($ sessId)
....

If ($ sess-> isValid () {/* check whether the session is valid */
Return $ anyVal;
}
Else {
$ IsRegenerateId = true;
}
....

How to handle dump is not mentioned here, because after regenerate is executed, the global session_id will automatically follow the change.

However, what is lacking in the US is that the closed feature of php oop is not powerful enough. $ isRegenerateId, an important variable, is extremely dangerous to be exposed in any environment, even if private is used, the more private the code is, the easier it is to make the Code state uncontrollable (this is an envy of Scala. One can have both val and var, and you only need to declare the sealed class as a global monitor, this problem can be easily solved, but PHP does not work ). You can adjust the parameters as follows:

$ SessName = "MY_APP_SID ";
Session_name ($ sessName );
Session_start (); // => the hosted open and pick functions are called immediately.
If (defined ('regenerate _ SESS_ID '))
Session_regenerate_id ();

Naturally, in open, when isValid is false, define ('regenerate _ SESS_ID ', true.

Finally, what are the consequences of not performing regenerate:

First of all, from the original intention of session hosting, each session has a life cycle to avoid heavy global recovery, so that session data can be redundant and temporarily exist, but it will not cause too much impact and interference to the session holder. If the session is forcibly deleted, the client must log on again. This is only one of the cases. If it is not properly controlled, multiple instances may exist for the same sessId, or sessions that are supposed to exceed the lifecycle will be re-activated. Of course, the client's individual experience may be negligible in terms of global security. Especially for website applications, session persistence rarely lasts for more than 10 hours. However, this is only limited to websites. For APIs, games, and session lifecycles, the requirements become increasingly strict. If you are on an enterprise-level application, some parts of the application may be in seconds. It is very important to achieve seamless inheritance and transformation of the session lifecycle.

Second, as a system, sessions often hold significant user information. No matter how well-designed the system is, there is always a red line between the client and the server. In special applications, sessions always hold more special data, transfer data securely, and create proper redundancy for future data management, data Return provides more comprehensive and accurate data. Furthermore, only by fully implementing the design can we summarize and promote a more complete structure for the performance. Without knowing the existence of bugs, it is the biggest risk.