Im Drupal-Framework ist die Sicherheitslücke CVE-2018-7600 im Jahr 2018 die klassischste und uns am nächsten liegende. Beim Lesen und Studieren dieses Artikels zur Schwachstellenanalyse habe ich jedoch festgestellt, dass es sich bei allen um eine detaillierte Analyse dieses Schwachstellenpunkts handelt. Personen, die mit dem laufenden Prozess dieses Frameworks nicht sehr vertraut sind, können nach dem Lesen Schwierigkeiten haben, es zu verstehen.
Das Folgende ist hauptsächlich in zwei Teile unterteilt:
Der erste Teil ist eine Einführung in den Drupal-Framework-Prozess (hier hauptsächlich für die 8.x-Serie) und zeigt uns, wie das Drupal-Framework auf dem Symfony Open Source Framework basiert verwendet das Listener-Muster. Es unterstützt den gesamten komplexen Verarbeitungsprozess und vermittelt uns ein grundlegendes Verständnis dafür, wie das Framework eine Anfrage verarbeitet.
Der zweite Teil ist eine detaillierte Interpretation des laufenden Prozesses der Schwachstelle CVE-2018-7600 basierend auf dem Framework. Am Ausgangspunkt der Auslösung der Schwachstelle wird zunächst das dynamische Debuggen normaler Datenpakete durchgeführt, um den Verarbeitungsfluss von Drupal zu verstehen Rahmen, und dabei die normalen Pakete verwenden Die steuerbaren Variablen im POC-Paket werden erstellt. Wir können nicht nur den Anfang und das Ende verstehen, sondern auch den mittleren Prozess transparent machen. In der Lage sein, Parallelen zu ziehen.
Drupal ist ein Open-Source-Content-Management-Framework (CMF), das in der PHP-Sprache geschrieben ist. Es besteht aus einem Content-Management-System (CMS) und einem PHP-Entwicklungsframework (Framework). Es hat viele Jahre in Folge den Preis für das beste CMS der Welt gewonnen und ist die bekannteste WEB-Anwendung, die auf der PHP-Sprache basiert.
Drupal-Architektur besteht aus drei Teilen: Kern, Modulen und Themen. Die drei sind durch den Hook-Mechanismus eng miteinander verbunden. Unter ihnen wird der Kernteil von einem Team entwickelt und gepflegt, das aus vielen berühmten WEB-Entwicklungsexperten auf der Welt besteht.
Drupal integriert leistungsstarke und frei konfigurierbare Funktionen und kann Website-Projekte mit verschiedenen Anwendungen unterstützen, von persönlichen Blogs (PersonalWeblog) bis hin zu großen Community-gesteuerten Websites (Community-Driven). Drupal war ursprünglich eine von DriesBuytaert entwickelte Community-Diskussionssoftware. Aufgrund seiner flexiblen Architektur, der praktischen Erweiterung und anderer Funktionen schlossen sich später Tausende von Programmierern auf der ganzen Welt der Entwicklung und Anwendung von Drupal an. Heute hat es sich zu einem leistungsstarken System entwickelt und viele große Organisationen verwenden Drupal-basierte Frameworks zum Erstellen von Websites, darunter The Onion, Ain't ItCool News, SpreadFirefox, Ourmedia, KernelTrap, NewsBusters usw. Dies kommt besonders häufig auf von der Community geführten Websites vor.
Zunächst können Sie die neueste Version direkt über die offizielle Website-Downloadseite https://www.drupal.org/download oder über https://www.drupal.org herunterladen /project/drupal /releases/xxx xxx stellt die Versionsnummer dar, die Sie herunterladen möchten, um die Quellcodedatei der entsprechenden Version herunterzuladen. Sie können zum Herunterladen auch das PHP-Paketverwaltungstool Composer verwenden.
2.2 Drupal-Installation
Installationsumgebung: WIN7 32-Bit
Integrierte Umgebung: PHPSTUDY
Debugging-Umgebung: PHPSTORM
Mögliche Probleme und Lösungen während der Installation:
1. PHP-Versionsproblem: PH ist am besten P7 oben
2. Datetime-Problem
Lösung:
php.ini-Einstellungen
3. Installationswarnung
Diese beiden Probleme (Warnung) können nicht gelöst werden.
Lösung für Problem 1: Aktualisieren Sie die PHP-Version auf 7.1 und höher.
Lösung für Problem 2:
Suchen Sie in php.ini nach [opcache] und fügen Sie hier den folgenden Inhalt hinzu.
zend_extension="C:xxxxxxphpphp-7.0.12-ntsextphp_opcache.dll"
opcache.memory_consumption=128
opcache.interned_strings_buffer=8
opcache.max_accelerated_files=4000
opcache.revalidate_freq=60
opcache.fast_shutdown=1
opcache.enable_cli=1
4. Da Drupal einige Anfragen zu langsam verarbeitet, kann es zu Timeout-Ausnahmen kommen. Setzen Sie einfach die Option max_execution_time in PHP.ini auf einen größeren Wert.
Das Folgende ist das Verzeichnis nach der Dekomprimierung des Drupal 8.5.7-Quellcodes:
/core Der Kernordner von Drupal, siehe Anweisungen Weitere Informationen finden Sie weiter unten
/modules. Angepasste oder heruntergeladene Module
/profiles speichert heruntergeladene und installierte benutzerdefinierte Konfigurationsdateien
Der Ordner/sites speichert in Drupal 7 oder früheren Versionen hauptsächlich Themen und Module, die von der Site und anderen Site-Dateien verwendet werden.
/themses speichert angepasste oder heruntergeladene Themes
/vendor speichert Code-Abhängigkeitsbibliotheken
Schauen wir uns als Nächstes die Verzeichnisstruktur unter dem Kernordner core an
/core/assets – wird von Drupal verwendet. Verschiedene Erweiterungsbibliotheken, z B. jquery, ckeditor, backbone, normalizeCSS usw.
/core/config – die Kernkonfigurationsdatei in Drupal
/core/includes – modulare zugrunde liegende Funktionsfunktionen, wie das modulare System selbst
/ core/lib – die Original-Kernklasse, bereitgestellt von Drupal
/core/misc – die verschiedenen Front-End-Dateien, die der Kern benötigt, wie JS, CSS, Bilder usw.
/core/modules – Kernmodule, etwa 80 Elemente
/core/profiles – integrierte Installationskonfigurationsdateien
/core/scripts – verschiedene von Entwicklern verwendete Hit-Skripte
/tests – zum Testen verwendete Datei
/core/themes – Kernel-Theme
Drupal basiert auf dem Symfony-Open-Source-Framework. Auf der offiziellen Symfony-Website ist ersichtlich, dass sysmfony ein wiederverwendbarer PHP-Komponentensatz ist, der zum Konvertieren beliebiger verwendet werden kann Komponenten werden unabhängig voneinander in ihren eigenen Anwendungen verwendet. Einige dieser Komponenten werden direkt von Drupal verwendet, andere werden entsprechend den eigenen Eigenschaften von Drupal geändert.
Werfen wir zunächst einen Blick auf den Ausführungsprozess von Symfony
Drupal und Symfony verwenden im Design dasselbe Konzept. Sie glauben beide, dass jedes Website-System tatsächlich ein System ist, das Anfragen in Antworten umwandelt.
Im Routing-System von Drupal können wir die Beziehung zwischen den verschiedenen Komponenten sehen:
Auf dieser Grundlage hat Drupal den Symfony-Verarbeitungsprozess verfeinert und den aktuellen riesigen Antwortprozess für die Drupal-Verarbeitung gebildet.
Die Bildlinkadresse lautet https://www.drupal.org/docs/8/api/render-api/the-drupal-8-render-pipeline. Bei Bedarf können Sie die hochauflösende Version selbst herunterladen.
Die Eintragsdatei ist mit nur 6 Zeilen Code sehr prägnant, läuft aber durch das gesamte Drupal-Kernsystem, die Analyse kann nicht umfassend sein. Wir beginnen mit dem Eintrag. Schauen Sie sich die Datei Zeile für Zeile an und analysieren Sie den laufenden Prozess.
Erstens: $autoloader =require_once 'autoload.php'; Oberflächlich betrachtet verwendet Drupal nur den PHP-Autoloader-Mechanismus, um einen Autoloader zu erstellen und ein Autoloader-Objekt zu erhalten.
Werfen wir einen kurzen Blick auf den Prozess aus der Code-Perspektive: Der grundlegende Prozess besteht darin, die getLoader-Funktion in Vendor/autoload.php aufzurufen.
Dann geben wir die Funktion ein, um zu sehen, was sie tut:
Das ClassLoader-Objekt verwendet die darin definierte grundlegende Korrespondenz, um Funktions- und Klassendefinitionsdateien zu finden.
Die Funktion gibt den Instanziierungslader nun endlich zurück. Drupal muss in Zukunft nicht mehr viele Dateien manuell einbinden, was eine Menge Arbeit spart.
Dann erstellt $kernel =new DrupalKernel('prod', $autoloader); drupal ein neues Drupal-Kernel-Objekt, um die Verarbeitung des bevorstehenden Anforderungsobjekts vorzubereiten.
Dieser Codezeile folgt $request= Request::createFromGlobals() in der Eintragsdatei. Für ein objektorientiertes System sollten wir globale Variablen wie $_POST, $_GET, $_COOKIE usw. nicht direkt verwenden. Drupal kapselt sie alle im $request-Objekt. Dies ist nicht nur einfach und bequem, sondern ermöglicht Ihnen auch das direkte Hinzufügen einiger zusätzlicher Funktionen und benutzerdefinierter Attribute mithilfe des angeforderten Objekts.
Abschließend werden die entsprechenden globalen Variablen zum Anforderungsobjekt hinzugefügt und das gekapselte Anforderungsobjekt zurückgegeben.
Wenn es sich bei der obigen Operation nur um eine Vorstufe handelt, beginnt die nächste Codezeile $response = $kernel->handle($request); mit der Verarbeitung durch die Kernel-Anforderungsanfrage des Drupal-Kernelobjekts.
Der Kern der Drupal-Verarbeitung ist die Verwendung des Listener-Musters im Entwurfsmuster. Es enthält eine Ereignisquelle, die verschiedene Ereignisse und Ereignisebenen enthält. Der andere Teil ist das Programm oder die Funktion, die das Ereignis ausführen muss. Wir nennen es den Listener. Während des Anforderungsverarbeitungsprozesses wird jedes Mal, wenn ein Knoten erreicht wird, ein entsprechendes Ereignis gesendet, und der Listener führt entsprechende Vorgänge basierend auf dem erhaltenen Ereignisobjekt und der erhaltenen Ereignisebene aus.
Die Kernereignisse des Systems verwenden weiterhin die Ereignisse im Symfony-Framework, das sich in kernelevents.php befindet und acht Kerne enthält:
Const REQUEST = 'kernel.request ' Ausführungsframework Wird ausgelöst, bevor ein Code im Code mit der Anforderungsverteilung beginnt.
Const EXCEPTION = ‚kernel.Exception‘ Ereignis wird ausgelöst, wenn eine nicht erfasste Ausnahme auftritt.
Const VIEW = ‚kernel.view‘ Wird ausgelöst, wenn der Rückgabewert des Controllers keine Antwortinstanz ist. Zu diesem Zeitpunkt gibt der Controller das Rendering-Array für weitere Rendering-Arbeiten zurück.
Const CONTOLLER = „kernel.controller“ wird ausgelöst, wenn der entsprechende Controller durch Parsen der Anforderungsanforderung gefunden wird und dieser Controller geändert werden kann.
Const CONTROLLER_ARGUMENTS = ‚kernel.controller_arguments‘ Wird beim Parsen der Parameter des Controllers ausgelöst und die Parameter können geändert werden.
Const RESPONSE = ‚kernel.response‘ Wird beim Erstellen einer Antwortanforderung ausgelöst und kann die zu beantwortende Antwort ändern oder ersetzen.
Const TERMINATE = ‚kernel.terminate‘ Wird ausgelöst, sobald die Antwort gesendet wird. Dieses Ereignis ermöglicht die Bearbeitung schwerer Post-Response-Aufgaben.
Const FINISH_REQUEST = „kernel.finish_request“ Wird ausgelöst, wenn die Anforderungsanforderung abgeschlossen ist. Es kann den globalen und Umgebungsstatus der Anwendung zurücksetzen, wenn die Anwendung während der Anforderung geändert wird.
Zusätzlich zu diesen Kernereignissen sendet jeder Listener in Drupal auch seine eigenen Ereignisse. Die Speicherorte dieser Dateien befinden sich in den entsprechenden Ordnern im Verzeichnis corelibDrupalCore. Sie enden alle mit events.php und die entsprechenden statischen Ereignisvariablen sind in der Datei definiert.
Werfen wir einen Blick auf den Drupal-Kernanforderungsprozess:
Starten Sie die Anforderung ---》 Analysieren Sie die Anforderung, holen Sie sich den Controller und korrigieren Sie ihn ------ 》Parse-Steuerung Controller-Parameter----》Rufen Sie die Methode entsprechend dem Controller auf -----》Beobachten Sie die Rückgabesituation des Controllers: Geben Sie die Antwort des Antwortobjekts zurück oder fahren Sie mit dem Rendern fort ------》Senden Sie die Antwort. Wenn während des gesamten Prozesses eine Ausnahme auftritt, wird das Ausnahmeereignis direkt zur Ausnahmeverteilung ausgelöst. Während des gesamten Prozesses wird das Anforderungsobjekt nicht nur auf Kernanforderungsereignisse reagieren, sondern auch auf andere allgemeine Modulereignisse reagieren. Unabhängig davon, wie holprig der Prozess ist, wird es jedoch irgendwann zurückkehren Hauptprozess und gibt die Antwort des Antwortobjekts zurück.
Beobachten Sie als Nächstes das obige spezifische Verhalten aus dem Quellcode:
Folgen Sie weiter von index.php und geben Sie die Datei drupalkernel.php ein. Schauen wir uns das an es.
Der nächste Schritt ist eine Reihe von Verarbeitungsfunktionsaufrufketten. Wir können einfach der Handle-Funktion folgen, sodass wir direkt dem Kernfunktions-Handleraw folgen können
Hier verfolgen wir weiterhin die Funktion filterResponse, die bald zurückkehren wird.
Die Antwortobjekte werden hier Schicht für Schicht zurückgegeben (es ist zu beachten, dass nicht alle Antwortergebnisse diesem Prozess folgen), aber es wird schließlich in ein Antwortobjekt gekapselt und an die Variable $response in der Datei index.php zurückgegeben. Rufen Sie dann $response->send() auf, um das gekapselte Antwortobjekt zu senden.
Manchmal ist der Inhalt der von uns gesendeten Anforderungsoperation zu umständlich. Wenn der obige Aufruf endet, führt unser Drupal-Kernel die letzte Verarbeitung durch, bevor er heruntergefahren wird. Der Prozess gibt die letzte Zeile der Datei Index.php ein und ruft $kernel->terminate($request,$response) auf. Wir folgen der Datei stackedhttpkernel.php gemäß der Aufrufkette
#🎜 🎜##🎜🎜 #
An diesem Punkt ist der gesamte Zyklus beendet.
Wir haben festgestellt, dass der häufigste Vorgang im oben genannten Prozess das Versenden von Ereignissen ist. Tatsächlich sind alle Versandprozesse gleich. Der spezifische Versandprozess befindet sich in der Datei „ContainerAwareEventDispatcher.php“. Ereignisse zu veranschaulichen.
Es gibt insgesamt 19 Listener im System, und jeder Listener verfügt über einen zugehörigen Dienstnamen. Der Name des eingehenden Ereignisses stimmt mit dem entsprechenden überein Listener, und dann werden die den Dienstnamen entsprechenden Funktionsfunktionen nacheinander aufgerufen. Was wir hier haben, ist das Ereignis kernel.request, und die aufrufende Methode ist ein Rückrufaufruf.
Viertens, schauen Sie sich CVE-2018-7600 an
4.1 Patch-Vergleich
Da diese Schwachstelle in Version 8.5.1 behoben wurde und es zwischen 5.0 und 5.1 nur eine Subversion gibt, können wir sie in der Quelle besser vergleichen Code Finden Sie den Unterschied heraus. Schauen wir uns an, wie der Beamte diese Schwachstelle behebt: Im Quellcode der Version 8.5.1 wurde eine neue RequestSanitizer.php-Datei hinzugefügt, die den Anforderungsteil in der Methode „stripDangerousValues“ filtert, der mit # beginnt und nicht mehr setzt sie auf die Whitelist. Die Werte aller Schlüsselnamen in .
In der Prehandle-Methode wird die in der obigen Datei hinzugefügte neue Methode zum Filtern aufgerufen. Der rote Teil auf der rechten Seite der Abbildung unten ist der neue Filtercode, der in 8.5.1 hinzugefügt wurde.
Die Aufrufposition des Filtercodes liegt hier, bevor der Drupal-Kernel die Anfrage verarbeitet. Dadurch wird die Schwachstelle ein für alle Mal vollständig behoben.
Dann haben wir die offizielle Drupal-Website aufgerufen, um die offiziellen Dokumente anzuzeigen, und festgestellt, dass die Drupal-Render-API eine spezielle Verarbeitung für den Anfang von # hat Der Link zum Dokument ist unten
https://www.drupal.org/docs/8/api/render-api/render-arrays und laut dem Checkpoint-Sicherheitsteam wurde ein Bericht darüber veröffentlicht die technischen Details dieser Schwachstelle. Der Link lautet wie folgt: https://research.checkpoint.com/uncovering-drupalgeddon-2/. Es wurde festgestellt, dass die Quelle des Schwachstellenauslösers die Avatar-Upload-Funktion in der registrierten Benutzerfunktion in Version 8.5.0 ist.
4.2 Der laufende Prozess von Datenpaketen im Framework 
Anschließend kapselt Drupal in der Eintragsdatei index.php nach dem Packen der Funktion „createfromglobals“ alle Parameter, die wir an das Anforderungsobjekt übergeben haben. 
4.2.1KernelEvents::REQUEST Dispatching Events 
Zuerst versucht Drupal, die Optionsanfrage zu verarbeiten, aber leider haben wir eine POST-Anfrage hier, daher wird sie nicht direkt verarbeitet und freigegeben.
Dann werden wir uns mit dem Schrägstrichproblem im URL-Pfad befassen und den Pfad, der mit mehreren Schrägstrichen beginnt, in einen einzelnen Schrägstrich umwandeln
Dann überprüfen wir die Identität gemäß der Anfrage. was wir hier nicht getan haben. Sie melden sich als Tourist an, daher gibt es hier keine Sonderbehandlung.
Als nächstes werden die Zielparameter, die $_GET['destination'] und $_REQUEST ['destination'] enthalten, bereinigt, um Umleitungsangriffe zu verhindern.
Anschließend wird anhand des Parameters _drupal_ajax in der POST-Anfrage beurteilt, ob es sich bei der Anfrage um eine AJAX-Anfrage handelt, und relevante Attribute werden festgelegt.
Der nächste Schritt besteht darin, die entsprechende Route entsprechend dem URL-Teil in der Anfrage abzugleichen. Hier sucht Drupal zunächst nach der entsprechenden Übereinstimmung im Routen-Cache und führt dann alle Suchvorgänge in der Routing-Tabelle durch. (Aufgrund der großen Codemenge werden wir hier nicht den gesamten Code abfangen, sondern nur einen Teil des Codes.) Die Verarbeitungsfunktion befindet sich in onKernelRequest. Gleichzeitig finden wir relevante Informationen im user.routing. yml-Datei.
Die Route wurde gefunden. Im nächsten Schritt wird überprüft, ob die Route verfügbar ist Überprüfen Sie das Konto, prüfen Sie, ob die Site offline ist, überprüfen Sie den dynamischen Seiten-Cache, verarbeiten Sie Nicht-Routing-Einstellungen vor und prüfen Sie, ob Replikatserver basierend auf Parametern deaktiviert werden sollen. Die zugehörigen Funktionen dieser Vorgänge sind unten in Screenshots dargestellt.
Zu diesem Zeitpunkt ist die Verhaltensanalyse aller KernelEvents::REQUEST-Listener abgeschlossen. Wir können sehen, dass die oben genannten Vorgänge hauptsächlich einige zusätzliche Maßnahmen erfordern, die wir ignorieren können. Aber wir haben daraus auch einige wertvolle Informationen extrahiert und die relevanten Routing-Informationen über das Anforderungsobjekt abgeglichen.
4.2.2KernelEvents::CONTROLLER- und KernelEvents::CONTROLLER_ARGUMENTS-Ereignisse
Schauen wir uns zunächst an, welche Operationen die Listener von KernelEvents::CONTROLLER ausführen werden.
Geben Sie das $event-Objekt ein 
Da KernelEvents::CONTROLLER_ARGUMENTS keinen eigenen Listener hat, wird es hier gesendet und direkt freigegeben.
4.2.3 Aufruf des Controllers
Nachdem Sie den anforderungsbezogenen Ereignisversand in handleRaw verarbeitet und den entsprechenden Controller aus der Anforderung gefunden haben, ist es an der Zeit, die entsprechende Verarbeitungsfunktion basierend auf dem Controller zu finden. Der Controller in call_user_function unten wurde durch die Abschluss-Callback-Funktion in der obigen Abbildung ersetzt. Der Aufruf des Controllers entspricht hier der direkten Eingabe der Abschlussfunktion in der obigen Abbildung.
In Drupal werden Controller zum Rendering-Kontext hinzugefügt, um sicherzustellen, dass jeder Controller direkt gerendert wird, wenn es eine Stelle gibt, die während der Verarbeitung gerendert werden muss. arbeiten.
Gemäß der Eingabe der eigentlichen Aufrufmethode durch den Controller, nämlich getContenResult, beginnt offiziell die Erstellung des Formulars.
4.2.4 Formularkonstruktion
Nach Eingabe der buildForm-Funktion erhalten wir zunächst die POST-Informationen Und in form_state gespeichert.
In der Funktion „retrieForm“ der Funktion „buildForm“ wird zunächst mit der Zusammenstellung des Formulars begonnen, wenn Elemente vorhanden sind, die gerendert werden müssen, am häufigsten in Drupal verwendet direkt Drupal::service('renderer')->renderPlain(); Dieser Rendering-Dienst führt Rendering-Vorgänge für Elemente aus. Die Hauptoperation der endgültigen Rendering-Funktion liegt in der doRender-Funktion.
Nachdem das gemäß der Anfrage zusammengestellte Formular zusammengestellt wurde, wird die Formularanforderung sofort verarbeitet. Hier führt die Funktion „processForm“ diesen Vorgang aus In dieser Funktion werden rekursive Operationen verwendet, um das Verhalten zu verarbeiten. Bei uns handelt es sich um einen Bild-Upload-Vorgang, bei dem das Verhalten ebenfalls verarbeitet wird. Überprüfen und verifizieren Sie dann jedes Element und jedes Token und erstellen Sie schließlich das gesamte Formular basierend auf den Ergebnissen neu.
Wenn Sie den Bildverarbeitungsprozess in ProcessForm verfolgen möchten, können Sie Haltepunkte direkt in der folgenden Funktion festlegen und den Stack-Traceback verwenden, um herauszufinden, was Ihnen liegt der Betrieb am Herzen.
Nachdem die Funktion „processForm“ ausgeführt wurde, ist hier ein Screenshot eines Teils des FORM-Formulars nach der Neuerstellung
#🎜🎜 #
In der Funktion „uploadAjaxCallback“ erhalten wir den Wert des Parameters „element_parents“ aus der URL des Datenpakets und verwenden diesen als Schlüssel, um das Ergebnis aus dem FORM-Formular abzurufen, das wir schließlich verarbeitet haben. Anschließend rendern wir das Ergebnis und präsentieren es auf dem HTML-Seite.
Basierend auf den Parametern der URL in unserem POST-Paket entnehmen wir das erste Element im Widget-Array unter user_picture im FORM-Formular.
Das letzte in doRender zu rendernde Objekt ist das gerade herausgenommene Element.
Nach dem Rendern geht der gesamte Verarbeitungsprozess zu Ende und die Antwort beginnt Schicht für Schicht aufzubauen und zurückzugeben.
4.2.6 kernel.response-Ereignis
Nachdem wir nun die Antwortphase erreicht haben, müssen wir mit dem Auslösen der Antwort beginnen. Schauen wir uns als Nächstes an, welche Zuhörer die Antwort hat Die Funktion besteht im Wesentlichen darin, dem Antwortobjekt Ziegel und Kacheln hinzuzufügen und einige entsprechende Erweiterungsvorgänge durchzuführen. Bestimmen Sie beispielsweise, ob eine dynamische Seite zwischengespeichert werden muss, ob es erforderlich ist, einen Cache-Kontext hinzuzufügen, Platzhalter zu verarbeiten, zusätzliche Header in einer erfolgreichen Antwort festzulegen usw. Alle oben genannten Vorgänge befinden sich im Array kernel.response unter den Listenern und werden hier nicht im Detail vorgestellt.
4.2.7 kernel.finish_request
Wenn die Anforderungs- und Antwortvorgänge abgeschlossen sind, wird dem Drupal-Kernel mitgeteilt, dass alles abgeschlossen wurde, und das Ereignis „finish_request“ wird gesendet. Es gibt nur einen Listener für dieses Ereignis: Damit die URL des Generators im richtigen Kontext ausgeführt werden kann, müssen wir die aktuelle Anfrage als übergeordnete Anfrage festlegen. 
4.2.8 kernel.terminate-Ereignis
Nach Abschluss der oben genannten Vorgänge wird die Anforderungsanforderung aus dem Anforderungsstapel entfernt und zum Senden der Antwort Schicht für Schicht an die Haupteintragsseite von Index.php zurückgegeben. Bereinigen Sie abschließend die Arbeit, lösen Sie das Ereignis kernel.terminate aus und bestimmen Sie, ob die relevanten Änderungen in die Datei geschrieben werden müssen. Schließlich wird der Drupal-Kern heruntergefahren. Der ganze Prozess ist beendet. 
Als nächstes verwenden Sie den Parameterwert element_parents in der URL, um den Wert im Formulararray abzurufen. Es wird in Abschnitt 4.2.5 von Teil 4 beschrieben und wird hier nicht wiederholt. Erstellen Sie abschließend die entsprechenden Variablen und verwenden Sie call_user_func_array in der doRender-Funktion, um die Sicherheitsanfälligkeit auszulösen.
Basierend auf der obigen Beschreibung haben wir die Mail-Parameter verwendet, um das folgende POC-Paket zu erstellen
Zusätzlich zur Steuerbarkeit der oben genannten Mail-Parameter wurde während des Analyseprozesses auch festgestellt, dass dies auch der Parameter form_build_id war Ein weiterer POC ist wie folgt.
Das obige ist der detaillierte Inhalt vonSo führen Sie eine eingehende Analyse des Drupal8-Frameworks und ein dynamisches Debugging von Schwachstellen durch. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!
