So führen Sie eine eingehende Analyse des Drupal8-Frameworks und ein dynamisches Debugging von Schwachstellen durch

Vorwort

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.

1. Hintergrundeinführung

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.

2. Vorbereitung

2.1 Quellcode-Download

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.

3. Kurze Analyse des Frameworks

3.1 Verzeichnisstruktur

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

3.2-Framework, das die Logik ausführt

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.

3.3 Der Eintragsdatei nach zu urteilen

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

Durch den dritten Teil der einfachen Rahmenanalyse kann es nur sein Als Nächstes werfen wir einen Blick auf die eher klassische Schwachstelle cve-2018-7600 im Drupal-Framework, um den detaillierten Funktionsweisesprozess dieser Schwachstelle im Framework sorgfältig zu beobachten. Die Version der Schwachstellen-Trigger-Umgebung, die wir hier verwenden, ist 8.5.0. Diese Version des Schwachstellen-Triggers ist intuitiver, daher wird in unserer nachfolgenden Analyse diese Version verwendet, sofern nicht anders angegeben.

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

Da wir die Auslösequelle der Schwachstelle kennen, laden wir sie hoch Nehmen Sie zunächst einmal ein Bild, nehmen Sie ein normales Originalpaket und sehen Sie sich die Situation an.

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

Da der Framework-Prozess oben vorgestellt wurde, ist das Folgende das Drupal Kernel Es ist Zeit, unsere Anfrage zu verarbeiten. Hier setzen wir den Haltepunkt direkt auf handleRaw und geben das erste KernelEvents::REQUEST-Dispatch-Ereignis ein, um zu sehen, was die Listener mit dieser Anfrage gemacht haben.

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

Als nächstes findet Drupal in der Handleraw-Funktion den echten Anforderungscontroller und die entsprechenden Parameter anhand der gerade abgeglichenen Routing-Informationen.

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

#🎜🎜 #

Zu diesem Zeitpunkt ist der gesamte Formularverarbeitungsvorgang abgeschlossen.

4.2.5 Abnormale Verteilung.

Nach Abschluss des Formularvorgangs im vorherigen Schritt wurde das Anforderungsobjekt ohne es zu wissen in ein Antwortobjekt umgewandelt. Es wollte Schicht für Schicht zurückkehren und den Sendevorgang ausführen, aber im nächsten Prozess stellte Drupal fest, dass es sich um eine Ajax-Anfrage handelte, sodass es den Vorgang proaktiv abfing und eine AJAX-Ausnahme auslöste, um eine zusätzliche Verarbeitung der Anfrage durchzuführen.

Nachdem Sie die Ausnahme abgefangen haben, behandeln Sie die Ausnahme und lösen Sie sie aus.

Der Versand hier ist eigentlich ein Prozess des Durchlaufens und Abgleichens von Ausnahmen. Es gibt viele Situationen, in denen Ausnahmen auftreten und dann bestimmte Aktionen ausführen bewältigen. Wenn es keine Übereinstimmung gibt, lassen Sie es einfach los. Wir haben die AJAX-Ausnahme hier abgeglichen. Wenn Sie sich mehr Gedanken über den Behandlungsprozess anderer Ausnahmen machen, suchen Sie einfach im Array „kernel.Exception“ danach.

Wir haben weiter nachverfolgt und festgestellt, dass es in der buildResponse-Funktion von onException eine spezielle Methode zur Behandlung von AJAX gibt.

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.

4.3 Zusammenfassung des gesamten Prozesses

Wir haben den gesamten Prozess im Folgenden kurz zusammengefasst:

Senden Sie das Datenpaket –> Finden Sie die entsprechende Route die entsprechende Route basierend auf der Route Controller--> Rufen Sie die Verarbeitungsmethode gemäß dem Controller ab (wir sind hier für formularbezogene Vorgänge)--> Erstellen und rendern Sie das Formular--> ; Bestimmen Sie nach der Verarbeitung des Formulars, ob es sich um eine AJAX-Operation handelt. Lösen Sie aktiv eine Ausnahme aus und verwenden Sie den AJAX-Callback, um den in der URL markierten FORM-Formularschlüssel erneut zu rendern. > Antwort senden --> O V. Schwachstellen-POC-Konstruktion

Basierend auf der Analyse und dem Verständnis des oben genannten Frameworks wird der POC erstellt. Das Checkpoint-Sicherheitsteam hat einen Bericht über die technischen Details dieser Sicherheitslücke veröffentlicht (siehe oben). Daraus geht hervor, dass der Auslöser der Sicherheitslücke darin besteht, nach der Erstellung des Formulars eine AJAX-Ausnahme auszulösen und das zu rendernde Objekt daraus zu extrahieren FROM-Formular und rendern Sie es, wenn, also in der endgültigen doRender-Funktion. Wir haben die folgenden ausnutzbaren Punkte in doRender gefunden:

Basierend auf unserer Analyse des Prozesses eines normalen Upload-Pakets, das im Framework in Teil 4 ausgeführt wird, wissen wir, dass wir möchten, dass der von uns erstellte Inhalt die Schwachstelle in doRender erfolgreich auslöst Zuerst müssen Sie den Prozess steuern und ihn in den AJAX-Callback-Teil eintreten lassen. Im folgenden if-Urteil wissen wir, dass drei Bedingungen gleichzeitig erfüllt sein müssen: $ajax_form_request, $form_state->isProcessingInput() und $request->request->get('form_id')== $ form_id. Wie aus der folgenden Abbildung ersichtlich ist, wird der Wert von $ajax_form_request durch die Variable ajax_form gesteuert, und form_id ist die ID des Formulars.

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!