Cara menjalankan analisis mendalam tentang rangka kerja drupal8 dan penyahpepijatan dinamik kelemahan

Kata Pengantar

Dalam rangka kerja drupal, yang paling klasik dan paling hampir dengan kami ialah kerentanan CVE-2018-7600 pada 2018. Walau bagaimanapun, dalam proses membaca dan mengkaji artikel analisis kelemahan ini, saya mendapati bahawa semuanya adalah analisis terperinci tentang titik kelemahan ini. Orang yang tidak begitu biasa dengan proses menjalankan rangka kerja ini mungkin mengalami kesukaran untuk memahaminya selepas membacanya.

Yang berikut terbahagi terutamanya kepada dua bahagian:

Bahagian pertama ialah pengenalan kepada proses rangka kerja drupal (di sini terutamanya untuk siri 8.x), memberitahu kami tentang asas rangka kerja sumber terbuka symfony Rangka kerja drupal pada halaman ini menggunakan mod pendengar untuk menyokong keseluruhan proses pemprosesan yang kompleks dan memberi kita pemahaman asas tentang cara rangka kerja mengendalikan permintaan.

Bahagian kedua ialah tafsiran terperinci tentang proses berjalan CVE-2018-7600 kerentanan berdasarkan rangka kerja Pada titik permulaan pencetus kerentanan, kami mula-mula mempelajari proses pemprosesan rangka kerja drupal dengan menyahpepijat paket data biasa secara dinamik Ini menggunakan pembolehubah yang boleh dikawal dalam pakej biasa untuk membina pakej POC. Kita bukan sahaja dapat memahami permulaan dan akhir, tetapi kita juga boleh membuat proses pertengahan telus. Boleh melukis selari.

1. Pengenalan latar belakang

Drupal ialah rangka kerja pengurusan kandungan sumber terbuka (CMF) yang ditulis dalam bahasa PHP Ia terdiri daripada sistem pengurusan kandungan (CMS) dan rangka kerja pembangunan PHP (Framework). Ia telah memenangi anugerah CMS terbaik dunia selama bertahun-tahun berturut-turut dan merupakan aplikasi WEB paling terkenal berdasarkan bahasa PHP.

Seni bina Drupal terdiri daripada tiga bahagian: teras, modul dan tema. Ketiganya berkait rapat melalui mekanisme Hook. Antaranya, bahagian teras dibangunkan dan diselenggara oleh pasukan yang terdiri daripada ramai pakar pembangunan WEB terkenal di dunia.

Drupal menyepadukan fungsi yang berkuasa dan boleh dikonfigurasikan secara bebas, dan boleh menyokong projek tapak web dengan pelbagai aplikasi daripada blog peribadi (PersonalWeblog) kepada tapak web yang dipacu komuniti yang besar (Didorong oleh Komuniti). Drupal pada asalnya adalah satu set perisian perbincangan komuniti yang dibangunkan oleh DriesBuytaert. Kemudian, disebabkan seni bina yang fleksibel, pengembangan yang mudah dan ciri-ciri lain, beribu-ribu pengaturcara di seluruh dunia menyertai pembangunan dan aplikasi Drupal. Hari ini, ia telah berkembang menjadi sistem yang berkuasa, dan banyak organisasi besar menggunakan rangka kerja berasaskan Drupal untuk membina tapak web, termasuk The Onion, Ain't ItCool News, SpreadFirefox, Ourmedia, KernelTrap, NewsBusters, dsb. Ia adalah perkara biasa di laman web yang diterajui komuniti.

2. Persediaan

2.1 Muat turun kod sumber

Mula-mula, anda boleh memuat turun terus versi terkini melalui laman muat turun laman web rasmi https://www.drupal.org/ muat turun atau muat turun versi terkini melalui https ://www.drupal.org/project/drupal/releases/xxx xxx mewakili nombor versi yang anda ingin muat turun untuk memuat turun fail kod sumber versi yang sepadan. Anda juga boleh menggunakan komposer alat pengurusan pakej PHP untuk memuat turun.

Pemasangan 2.2 drupal

Persekitaran pemasangan: WIN7 32-bit

Persekitaran bersepadu: PHPSTUDY

Persekitaran penyahpepijatan: PHPSTORM

Kemungkinan semasa pemasangan Masalah dan penyelesaian:

1. Masalah versi PHP: sebaik-baiknya PHP7.0 ke atas

2. Masalah tarikh

Penyelesaian:

Tetapkan dalam php.ini

3. Amaran pemasangan

Kedua-dua ini. masalah (amaran) tidak perlu diselesaikan.

Penyelesaian kepada masalah 1: Naik taraf versi php kepada 7.1 dan ke atas.

Penyelesaian kepada masalah 2:

Dalam php.ini, cari [opcache] dan tambah kandungan berikut di sini.

zend_extension="C:xxxxxxphpphp-7.0.12-ntsextphp_opcache.dll"

opcache.memory_consumption=128

opcache.max_accelerated_files=4000

opcache.revalidate_freq=60

opcache.fast_shutdown=1

opcache=1

enable_cli 🎜> 4. Oleh kerana drupal memproses beberapa permintaan terlalu perlahan, yang mungkin menyebabkan pengecualian tamat masa, cuma tetapkan pilihan max_execution_time dalam Php.ini kepada nilai yang lebih besar.

3. Analisis ringkas rangka kerja

3.1 Struktur direktori

Berikut ialah direktori selepas penyahmampatan kod sumber drupal 8.5.7:

/core Folder teras drupal, sila rujuk penerangan berikut untuk butiran

/modul menyimpan modul tersuai atau dimuat turun

/kedai profil dimuat turun dan dipasang fail konfigurasi tersuai

Folder

/sites, dalam drupal 7 atau lebih awal, menyimpan terutamanya tema dan modul yang digunakan oleh tapak dan fail tapak lain. Tema tersuai atau dimuat turun disimpan dalam

/themses

/vendor stores pustaka pergantungan kod

Seterusnya mari kita lihat struktur direktori di bawah teras folder teras

/core/assets - Pelbagai pustaka sambungan yang digunakan oleh drupal, seperti jquery, ckeditor, backbone, normalizeCSS, dll.

/core/config - drupal Fail konfigurasi teras

/teras/termasuk – fungsi fungsi tahap rendah modular, seperti sistem modular itu sendiri

/teras/lib – kelas teras asal yang disediakan oleh drupal

/ teras/misc – pelbagai fail hadapan hadapan yang diperlukan oleh teras, seperti JS, CSS, imej, dsb.

/teras/modul – modul teras, kira-kira 80 item

/teras/profil – fail konfigurasi pemasangan terbina dalam

/teras/skrip – pelbagai jenis digunakan oleh pembangun Skrip tekan

/tests - uji fail berkaitan

/core/themes - tema kernel

3.2 rangka kerja logik

Drupal dibina berdasarkan rangka kerja sumber terbuka symfony, anda boleh melihat dari laman web rasmi symfony bahawa sysmfony ialah set komponen PHP yang boleh digunakan semula Anda boleh menggunakan mana-mana komponen secara bebas dalam aplikasi anda sendiri, setiap komponen mempunyai Dokumentasi bebasnya sendiri komponen digunakan secara langsung oleh drupal, dan ada yang diubah suai mengikut ciri drupal sendiri.

Mari kita lihat dahulu proses pelaksanaan symfony

Drupal dan symfony juga menggunakan konsep yang sama dalam reka bentuk mana-mana Sistem laman web sebenarnya adalah sistem yang menukar permintaan kepada respons.

Dalam sistem penghalaan drupal, kita dapat melihat hubungan antara pelbagai komponen:

Atas dasar ini, proses pemprosesan drupal untuk symfony Ia telah diperhalusi untuk membentuk proses pemprosesan dan tindak balas drupal yang besar semasa.

Alamat pautan imej ialah https://www.drupal.org/docs/8/api/render-api/the-drupal-8-render-pipeline Jika perlu, anda boleh memuat turun high-. versi definisi sendiri.

3.3 Daripada fail entri

Fail entri sangat ringkas, dengan hanya 6 baris kod, tetapi ia berjalan melalui Bagi keseluruhan drupal, kerana sistem teras drupal terlalu besar, adalah mustahil untuk menganalisis segala-galanya Kami akan melihat fail kemasukan baris demi baris dan menganalisis proses berjalannya.

Pertama, $autoloader =require_once 'autoload.php'; Di permukaan, ia hanya mengandungi fail autoload.php Malah, drupal akan menggunakan mekanisme autoloader PHP untuk membuat autoloader dan mendapatkan An secara automatik objek.

Mari kita lihat secara ringkas proses dari perspektif kod: Proses asas ialah memanggil fungsi getLoader dalam vendor/autoload.php.

Kemudian kita masukkan fungsi untuk melihat fungsinya:

Objek ClassLoader menggunakan surat-menyurat asas yang ditakrifkan di dalam untuk mencari fungsi dan fail definisi kelas. Fungsi

akhirnya mengembalikan pemuat instantiasi Sekarang langkah pertama telah selesai Drupal tidak perlu lagi memasukkan banyak fail secara manual, menjimatkan banyak kerja.

Kemudian $kernel =new DrupalKernel('prod', $autoloader); drupal mencipta objek kernel drupal baharu untuk menyediakan pemprosesan objek permintaan yang akan datang.

Mengikut baris kod ini ialah $request= Request::createFromGlobals() dalam fail masukan. Untuk sistem berorientasikan objek, kita tidak seharusnya menggunakan pembolehubah global secara langsung seperti $_POST, $_GET, $_COOKIE, dsb. Drupal merangkumkan kesemuanya ke dalam objek $request. Ini bukan sahaja mudah dan mudah, tetapi juga membolehkan anda menambah secara langsung beberapa fungsi tambahan dan atribut tersuai menggunakan objek yang diminta.

Akhir sekali, pembolehubah global yang sepadan akan ditambahkan pada objek permintaan dan objek permintaan terkapsul akan dikembalikan.

Jika operasi di atas hanyalah peringkat awal, maka baris seterusnya kod $response = $kernel->handle($request); dan kernel objek kernel drupal akan mengendalikan permintaan permintaan.

Inti pemprosesan Drupal ialah corak pendengar dalam corak reka bentuk. Ia termasuk sumber acara, yang mengandungi acara dan peringkat acara yang berbeza. Bahagian lain ialah program atau fungsi yang perlu melaksanakan acara, kami memanggilnya pendengar. Dalam proses pemprosesan permintaan, setiap kali nod dicapai, peristiwa yang sepadan akan dihantar dan pendengar akan melakukan operasi yang sepadan berdasarkan objek dan tahap peristiwa yang diperolehi.

Peristiwa teras sistem terus menggunakan peristiwa dalam rangka kerja symfony, terletak di kernelevents.php, yang mengandungi lapan teras:

Const REQUEST = 'kernel.request' melaksanakan sebarang acara dalam kod rangka kerja Kod dicetuskan sebelum permulaan penghantaran permintaan.

Const EXCEPTION = Peristiwa 'kernel.exception' tercetus apabila pengecualian yang tidak ditangkap berlaku.

Const VIEW = 'kernel.view' Dicetuskan apabila nilai pulangan pengawal bukan contoh tindak balas. Pada masa ini, pengawal mengembalikan tatasusunan pemaparan untuk kerja pemaparan selanjutnya.

CONTOLLER Const = 'kernel.controller' Dicetuskan apabila menghuraikan permintaan dan mencari pengawal yang sepadan, dan pengawal ini boleh diubah suai.

Const CONTROLLER_ARGUMENTS = 'kernel.controller_arguments' Dicetuskan apabila menghuraikan parameter pengawal, dan parameter boleh ditukar.

Const RESPONSE = ‘kernel.response’ Dicetuskan apabila membuat permintaan balasan respons, dan boleh mengubah suai atau menggantikan respons untuk dibalas.

Const TERMINATE = 'kernel.terminate' Dicetuskan sebaik sahaja respons dihantar. Peristiwa ini akan membolehkan pengendalian tugasan pasca respons yang berat.

Const FINISH_REQUEST = 'kernel.finish_request' Dicetuskan apabila permintaan Permintaan selesai Ia boleh menetapkan semula keadaan global dan persekitaran aplikasi apabila aplikasi ditukar semasa permintaan.

Selain acara teras ini, setiap pendengar dalam drupal juga menghantar acaranya sendiri. Lokasi fail ini terletak dalam folder yang sepadan di bawah direktori corelibDrupalCore. Kesemuanya berakhir dengan events.php, dan pembolehubah acara statik yang sepadan ditakrifkan dalam fail.

Mari kita lihat proses permintaan teras drupal:

Mulakan permintaan---》Kupas permintaan untuk mendapatkan pengawal dan betulkan-------》Hilangkan parameter pengawal-- --》Panggil kaedah mengikut pengawal-----》Perhatikan situasi pulangan pengawal: kembalikan respons objek tindak balas atau teruskan rendering------》Hantar respons. Jika pengecualian berlaku di tengah-tengah keseluruhan proses, peristiwa pengecualian akan dicetuskan secara langsung untuk pengedaran pengecualian. Dalam keseluruhan proses, selain bertindak balas kepada peristiwa permintaan teras, objek permintaan juga akan memasuki cawangan yang bertindak balas kepada peristiwa modul biasa yang lain mengikut situasi sebenar Walau bagaimanapun, tidak kira betapa bergeloranya proses itu, ia akhirnya akan kembali ke proses utama dan mengembalikan respons objek tindak balas.

Seterusnya, amati tingkah laku khusus di atas daripada kod sumber:

Teruskan membuat susulan daripada index.php dan masukkan fail drupalkernel.php Mari kita lihat operasi yang dilakukan.

Langkah seterusnya ialah satu siri rantaian panggilan fungsi pengendali Kita hanya boleh mengikut fungsi pemegang, supaya kita boleh terus mengikut handleraw fungsi teras

Di sini kami terus membuat susulan pada fungsi filterResponse yang akan kembali.

Objek tindak balas di sini akan dikembalikan lapisan demi lapisan (perlu diingatkan bahawa tidak semua hasil tindak balas akan melalui proses ini), tetapi mereka akhirnya akan menjadi dikapsulkan ke dalam objek tindak balas, dikembalikan kepada pembolehubah $respons dalam fail index.php. Kemudian panggil $response->send() untuk menghantar objek respons terkapsul.

Kadang-kadang kandungan operasi permintaan yang kami hantar akan menjadi terlalu rumit, jadi apabila panggilan di atas tamat, kernel drupal kami akan melakukan pemprosesan terakhir sebelum ditutup. Proses memasuki baris terakhir fail Index.php dan memanggil $kernel->terminate($request,$response) Kami mengikuti fail httpkernel.php yang disusun mengikut rantaian panggilan

Pada ketika ini, keseluruhan kitaran telah tamat.

Kami mendapati bahawa operasi yang paling biasa dalam proses di atas adalah penghantaran peristiwa Sebenarnya, proses penghantaran adalah sama Proses penghantaran khusus adalah dalam fail ContainerAwareEventDispatcher.php .meminta peristiwa.

Terdapat 19 jumlah pendengar dalam sistem, dan setiap pendengar akan mempunyai nama perkhidmatan yang berkaitan dengannya Kami akan memadankan nama acara masuk Pendengar yang sepadan kemudian melintasi dan memanggil fungsi berfungsi sepadan dengan nama perkhidmatan satu demi satu. Apa yang kita ada di sini ialah acara kernel.request, dan kaedah panggilan ialah panggilan balik.

4 Lihat CVE-2018-7600 sekali lagi

Melalui analisis rangka kerja yang mudah di bahagian ketiga, anda mungkin hanya mempunyai konsep yang samar-samar tentang proses. Seterusnya Kami menggabungkan contoh kerentanan dan menumpukan pada kerentanan rangka kerja Drupal yang lebih klasik cve-2018-7600 untuk memerhatikan proses operasi terperinci kerentanan ini dalam rangka kerja. Versi persekitaran pencetus kerentanan yang kami gunakan di sini ialah 8.5.0 Versi pencetus kerentanan ini lebih intuitif, jadi versi kod yang digunakan dalam analisis kami yang seterusnya ialah versi ini melainkan dinyatakan sebaliknya.

Perbandingan tampalan 4.1

Oleh kerana kelemahan ini telah diperbaiki dalam versi 8.5.1, dan hanya terdapat satu subversi antara 5.0 dan 5.1, kami boleh membandingkan dengan lebih jelas perbezaan dalam kod sumber . Mari lihat cara pegawai membetulkan kerentanan ini: Dalam kod sumber versi 8.5.1, fail RequestSanitizer.php baharu ditambahkan, yang menapis bahagian permintaan Dalam kaedah stripDangerousValues, ia menapis yang bermula dengan # dan tidak lagi menyenarai putih mereka Nilai semua nama utama dalam .

Dalam kaedah prapenangan, kaedah baharu yang ditambahkan dalam fail di atas dipanggil untuk penapisan Bahagian merah di sebelah kanan rajah di bawah ialah kod penapisan yang ditambahkan 8.5.1.

Kedudukan panggilan kod penapisan di sini adalah sebelum kernel drupal memproses permintaan. Ini akan membetulkan kelemahan sepenuhnya sekali dan untuk semua.

Kemudian kami memasuki laman web rasmi drupal untuk menyemak dokumen rasmi dan mendapati bahawa api render drupal mempunyai pemprosesan khas untuk permulaan # Pautan dokumen utama adalah di bawah

https ://www.drupal.org/docs/8/api/render-api/render-arrays dan menurut pasukan keselamatan pusat pemeriksaan mengeluarkan laporan mengenai butiran teknikal kelemahan ini. Pautannya adalah seperti berikut: https://research.checkpoint.com/uncovering-drupalgeddon-2/. Didapati bahawa sumber pencetus kerentanan adalah fungsi muat naik avatar dalam fungsi pengguna berdaftar dalam versi 8.5.0.

4.2 Proses menjalankan paket data dalam rangka kerja

Sekarang setelah kita mengetahui sumber pencetus kerentanan, mula-mula muat naik gambar dan tangkap gambar biasa Semak pakej awal untuk melihat apa yang berlaku.

Kemudian dalam fail entri index.php, selepas membungkus fungsi createfromglobals, drupal merangkum semua parameter yang kami hantar ke dalam objek permintaan.

4.2.1KernelEvents::REQUEST Dispatching Events

Memandangkan proses rangka kerja telah diperkenalkan di atas, berikut ialah peringkat kernel drupal memproses permintaan kami . , di sini kami terus menetapkan titik putus pada handleRaw, dan masukkan acara penghantaran KernelEvents::REQUEST yang pertama untuk melihat perkara yang dilakukan oleh pendengar terhadap permintaan ini.

Pertama drupal cuba memproses permintaan Option Malangnya, permintaan kami adalah POST, jadi kami tidak memproses itu dan biarkan ia pergi terus.

Kemudian ia akan menangani masalah garis miring pada laluan URL, dan akan menukar laluan yang bermula dengan berbilang garis miring kepada satu garis miring

Kemudian identiti akan disahkan mengikut permintaan Kami tidak log masuk di sini, kami adalah pelancong, jadi tiada layanan istimewa di sini.

Seterusnya, parameter sasaran yang mengandungi $_GET['destination'] dan $_REQUEST ['destination'] akan dibersihkan untuk mengelakkan serangan ubah hala.

Ia kemudiannya akan dinilai berdasarkan parameter _drupal_ajax dalam permintaan POST sama ada permintaan itu adalah permintaan AJAX dan atribut yang berkaitan akan ditetapkan.

Langkah seterusnya ialah memadankan laluan yang sepadan mengikut bahagian URL dalam permintaan Di sini drupal akan terlebih dahulu mencari padanan yang sepadan dalam cache laluan, dan jika tidak , kemudian teruskan semua operasi carian jadual penghalaan. (Disebabkan jumlah kod yang banyak, kami tidak akan memintas semua kod di sini, tetapi hanya sebahagian daripada kod tersebut). fail yml.

Laluan ditemui, langkah seterusnya adalah untuk menyemak sama ada laluan itu tersedia

Langkah seterusnya ialah untuk menyemak sama ada tapak berada dalam mod Penyelenggaraan, jika ia adalah mod penyelenggaraan, log keluar daripada akaun, semak sama ada tapak itu di luar talian, semak cache halaman dinamik, pra-proses tetapan bukan penghalaan dan lihat sama ada untuk melumpuhkan replika pelayan mengikut parameter. Fungsi berkaitan operasi ini ialah tangkapan skrin di bawah.

Pada ketika ini, semua pendengar KernelEvents::REQUEST Selepas analisis tingkah laku selesai, kami dapat melihat bahawa operasi di atas terutamanya mengambil beberapa langkah tambahan Kami boleh mengabaikannya, tetapi kami juga mengekstrak beberapa maklumat berharga daripadanya dan memadankan maklumat penghalaan yang berkaitan melalui objek permintaan.

4.2.2 KernelEvents::CONTROLLER dan KernelEvents::CONTROLLER_ARGUMENTS acara

Seterusnya, dalam fungsi handleraw, drupal mencari pengawal permintaan sebenar dan parameter yang sepadan melalui maklumat penghalaan yang baru dipadankan .

Mari kita lihat dahulu operasi yang akan dilakukan oleh pendengar KernelEvents::CONTROLLER.

Pertama, untuk mengelakkan konflik pada masa hadapan, KEY kunci ditetapkan pada pengurus yang sepadan

Kemudian, untuk memastikan integriti pemprosesan data seterusnya , di sini kami menggunakan penutupan untuk menyimpan fungsi pengawal pemprosesan panggil balik ke dalam objek $event

Kerana KernelEvents::CONTROLLER_ARGUMENTS tidak mempunyai pendengarnya sendiri, jadi di sini Agihan akan dikeluarkan terus.

4.2.3 Memanggil pengawal

Selepas memproses penghantaran acara berkaitan permintaan dalam handleRaw dan mencari pengawal yang sepadan daripada permintaan, tiba masanya untuk mencari fungsi pemprosesan yang sepadan berdasarkan pengawal. Pengawal dalam fungsi panggilan_pengguna di bawah telah digantikan dengan fungsi panggil balik penutupan dalam rajah di atas.

Dalam drupal, pengawal akan ditambahkan pada konteks rendering untuk memastikan bahawa jika terdapat tempat yang memerlukan rendering semasa pemprosesan setiap pengawal, operasi rendering akan dilakukan secara langsung.

Menurut pengawal yang memasuki kaedah panggilan sebenar, iaitu getContenResult, pembinaan borang secara rasmi bermula.

4.2.4 Pembinaan borang

Selepas memasuki fungsi buildForm, kami akan mula-mula mendapatkan maklumat POST dan menyimpannya dalam form_state.

Dalam fungsi retrieveForm fungsi buildForm, borang borang mula dipasang pada mulanya Jika terdapat elemen yang perlu diberikan, kebanyakan drupal akan menggunakan Drupal secara langsung: :service('renderer' )->renderPlain(); Perkhidmatan rendering ini menjalankan operasi rendering pada elemen, dan operasi utama fungsi rendering akhir adalah dalam fungsi doRender.

Selepas borang yang dihimpun mengikut rquest dihimpun, permintaan borang akan diproses serta-merta Fungsi processForm di sini menjalankan operasi ini , gunakan rekursif operasi untuk memproses tingkah laku. Kemudian semak dan sahkan setiap elemen dan token, dan akhirnya bina semula keseluruhan Borang berdasarkan keputusan.

Jika anda ingin menjejaki proses pemprosesan imej dalam processForm, anda boleh terus menetapkan titik putus pada fungsi di bawah dan mencari operasi yang anda minati berdasarkan surih balik tindanan.

Selepas menjalankan fungsi processForm, berikut ialah tangkapan skrin sebahagian daripada borang FORM selepas membina semula

Berikut ialah keseluruhan borang Operasi pemprosesan telah selesai.

4.2.5 Taburan tidak normal.

Selepas melengkapkan operasi borang dalam langkah sebelumnya, objek permintaan telah ditukar menjadi objek tindak balas tanpa mengetahuinya. Ia akan mengembalikan lapisan demi lapisan dan melaksanakan operasi penghantaran, tetapi dalam proses seterusnya drupal mendapati bahawa ini adalah permintaan ajax, jadi ia secara proaktif memintas operasi dan melemparkan pengecualian AJAX untuk melaksanakan pemprosesan tambahan pada permintaan itu.

Selepas menangkap pengecualian, kendalikan pengecualian dan hantar pengecualian.

Penghantaran di sini sebenarnya adalah proses merentasi dan memadankan pengecualian Terdapat banyak situasi apabila pengecualian berlaku. Jika tiada jodoh, biarkan sahaja. Kami telah memadankan pengecualian AJAX di sini Jika anda lebih mengambil berat tentang proses pengendalian pengecualian lain, cari sahaja dalam tatasusunan kernel.exception.

Kami selanjutnya membuat susulan dan mendapati terdapat kaedah khusus untuk mengendalikan AJAX dalam fungsi buildResponse onException.

Dalam fungsi uploadAjaxCallback, kami mendapat nilai parameter element_parents daripada URL paket data, dan gunakan ini sebagai kunci untuk mendapatkan hasil daripada borang FORM yang akhirnya kami proses, dan kemudian memaparkan hasilnya dan membentangkannya pada halaman HTML yang lebih tinggi.

Berdasarkan parameter URL dalam pakej POST kami, kami mengeluarkan item pertama dalam tatasusunan widget di bawah user_picture dalam borang FORM.

Objek akhir yang akan diberikan dalam doRender ialah elemen yang baru dikeluarkan.

Selepas rendering, keseluruhan proses pemprosesan akan berakhir, dan respons mula dibina dan dikembalikan lapisan demi lapisan.

Acara kernel.response 4.2.6

Sekarang kita telah mencapai peringkat tindak balas, kita mesti mula mencetuskan respons Seterusnya, mari kita lihat apa yang dimiliki oleh pendengar

Dalam fungsi penghantaran respons, ia pada asasnya menambah pada objek tindak balas dan melakukan beberapa operasi pengembangan yang sepadan. Contohnya, tentukan sama ada halaman dinamik perlu dicache, sama ada perlu untuk menambah konteks cache, mengendalikan ruang letak, menetapkan pengepala tambahan dalam respons yang berjaya, dsb. Semua operasi di atas akan berada dalam tatasusunan kernel.response di bawah pendengar, dan tidak akan diperkenalkan secara terperinci di sini.

4.2.7 kernel.finish_request

Apabila operasi permintaan dan tindak balas selesai, kernel drupal akan diberitahu bahawa semuanya telah selesai dan akan acara finish_request dihantar, hanya ada satu pendengar untuk acara ini: Untuk penjana URL berjalan dalam konteks yang betul, kami perlu menetapkan permintaan semasa sebagai permintaan induk.

4.2.8 kernel.terminate event

Selepas menyelesaikan operasi di atas, permintaan permintaan muncul dari timbunan permintaan dan dikembalikan ke lapisan Index.php mengikut lapisan. Jawapan dihantar pada halaman masuk utama. Akhir sekali, bersihkan kerja, cetuskan acara kernel.terminate, dan tentukan sama ada perubahan yang berkaitan perlu ditulis pada fail. Akhirnya teras drupal ditutup. Seluruh proses telah berakhir.

4.3 Ringkasan keseluruhan proses

Keseluruhan proses telah diuraikan melalui bahagian sebelumnya Mari ringkaskan secara ringkas di bawah:

Hantar paket data-->Mengikut bahagian. URL Padankan laluan berkaitan --> Cari pengawal yang sepadan berdasarkan laluan --> Memproses permintaan borang- -> Selepas memproses borang, tentukan sama ada ia adalah operasi AJAX --> pembinaan sepadan objek tindak balas --> Hantar respons -- >Tamat sapuan.

5. Pembinaan POC Kerentanan

Mula membina POC berdasarkan analisis dan pemahaman rangka kerja di atas. Pasukan keselamatan pusat pemeriksaan mengeluarkan laporan mengenai butiran teknikal kelemahan ini (dipautkan di atas dapat dilihat bahawa titik pencetus kelemahan adalah untuk mencetuskan pengecualian AJAX selepas borang dibina, mengekstrak objek yang akan diberikan daripada). DARI borang, dan menjadikannya Dicetuskan apabila, iaitu, dalam fungsi doRender akhir. Kami menemui perkara yang boleh dieksploitasi berikut dalam doRender:

Berdasarkan analisis kami tentang proses pakej muat naik biasa yang dijalankan dalam rangka kerja dalam Bahagian 4, kami tahu bahawa kami mahu Kandungan yang dibina berjaya mencetuskan kelemahan dalam doRender Pertama, anda perlu mengawal proses dan biarkan ia memasuki bahagian panggil balik AJAX. Dalam penghakiman if di bawah, kita tahu bahawa tiga syarat perlu dipenuhi pada masa yang sama, $ajax_form_request, $form_state->isProcessingInput() dan $request->request->get('form_id')== $ borang_id. Seperti yang dapat dilihat daripada rajah di bawah, nilai $ajax_form_request dikawal oleh pembolehubah ajax_form, dan form_id ialah id borang.

Seterusnya, gunakan nilai parameter element_parents dalam url untuk mendapatkan nilai dalam tatasusunan borang. Ia diterangkan dalam Bahagian 4.2.5 Bahagian 4 dan tidak akan diulang di sini. Akhir sekali, bina pembolehubah yang sepadan dan gunakan call_user_func_array dalam fungsi doRender untuk mencetuskan kelemahan.

Berdasarkan penerangan di atas, kami menggunakan parameter mel untuk membina pakej POC berikut

Selain parameter mel boleh dikawal di atas, parameter form_build_id juga ditemui semasa proses analisis Juga boleh dikawal, POC lain adalah seperti berikut.

Atas ialah kandungan terperinci Cara menjalankan analisis mendalam tentang rangka kerja drupal8 dan penyahpepijatan dinamik kelemahan. Untuk maklumat lanjut, sila ikut artikel berkaitan lain di laman web China PHP!