Comment effectuer une analyse approfondie du framework Drupal8 et un débogage dynamique des vulnérabilités

Avant-propos

Dans le framework Drupal, la plus classique et la plus proche de nous est la vulnérabilité CVE-2018-7600 en 2018. Cependant, en lisant et en étudiant cet article d'analyse de vulnérabilité, j'ai constaté qu'il s'agissait tous d'une analyse détaillée de ce point de vulnérabilité. Les personnes qui ne connaissent pas très bien le fonctionnement de ce framework peuvent avoir des difficultés à le comprendre après l'avoir lu.

Ce qui suit est principalement divisé en deux parties :

La première partie est une introduction au processus du framework Drupal (ici principalement pour la série 8.x), nous faisant savoir comment fonctionne le framework Drupal basé sur le framework open source symfony utilise le modèle d'écoute. Il prend en charge l'ensemble du processus de traitement complexe et nous donne une compréhension de base de la façon dont le framework gère une requête.

La deuxième partie est une interprétation détaillée du processus en cours d'exécution de la vulnérabilité CVE-2018-7600 basée sur le framework. Au point de départ du déclenchement de la vulnérabilité, d'abord en déboguant dynamiquement les paquets de données normaux pour comprendre le flux de traitement du Drupal. framework, et ainsi en utilisant les paquets normaux. Les variables contrôlables dans le package POC sont construites. Non seulement nous pouvons comprendre le début et la fin, mais nous pouvons également rendre transparent le processus intermédiaire. Être capable de faire des parallèles.

1. Introduction générale

Drupal est un framework de gestion de contenu (CMF) open source écrit en langage PHP. Il est composé d'un système de gestion de contenu (CMS) et d'un framework de développement PHP (Framework). Il a remporté le prix du meilleur CMS au monde pendant de nombreuses années consécutives et est l'application WEB la plus connue basée sur le langage PHP.

L'architecture Drupal se compose de trois parties : le noyau, les modules et les thèmes. Les trois sont étroitement liés grâce au mécanisme Hook. Parmi eux, la partie centrale est développée et maintenue par une équipe composée de nombreux experts en développement WEB de renommée mondiale.

Drupal intègre des fonctions puissantes et librement configurables, et peut prendre en charge des projets de sites Web avec diverses applications, des blogs personnels (PersonalWeblog) aux grands sites Web communautaires (Community-Driven). Drupal était à l'origine un ensemble de logiciels de discussion communautaire développé par DriesBuytaert. Plus tard, grâce à son architecture flexible, son extension pratique et ses autres fonctionnalités, des milliers de programmeurs du monde entier ont rejoint le développement et l'application de Drupal. Aujourd'hui, il est devenu un système puissant et de nombreuses grandes organisations utilisent des frameworks basés sur Drupal pour créer des sites Web, notamment The Onion, Ain't ItCool News, SpreadFirefox, Ourmedia, KernelTrap, NewsBusters, etc. C’est particulièrement courant sur les sites Web communautaires.

2. Préparation

2.1 Téléchargement du code source

Tout d'abord, vous pouvez télécharger la dernière version directement via la page de téléchargement du site officiel https://www.drupal.org/download ou via https://www.drupal.org /project/drupal /releases/xxx xxx représente le numéro de version que vous souhaitez télécharger pour télécharger le fichier de code source de la version correspondante. Vous pouvez également utiliser le compositeur de l'outil de gestion de packages PHP pour le télécharger.

Installation Drupal 2.2

Environnement d'installation : WIN7 32 bits

Environnement intégré : PHPSTUDY

Environnement de débogage : PHPSTORM

Problèmes possibles et solutions lors de l'installation :

1. Problème de version PHP : PH est le meilleur P7 0 ou. ci-dessus

2. Problème datetime

Solution : Définissez

dans

php.ini 3. Avertissement d'installation

Ces deux problèmes (avertissement) ne peuvent pas être résolus.

Solution au problème 1 : Mettez à niveau la version php vers la version 7.1 et supérieure.

Solution au problème 2 :

Dans php.ini, recherchez [opcache] et ajoutez ici le contenu suivant.

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. Étant donné que Drupal traite certaines requêtes trop lentement, cela peut provoquer des exceptions de délai d'attente. Définissez simplement l'option max_execution_time dans Php.ini sur une valeur plus grande.

3. Brève analyse du framework

3.1 Structure des répertoires

Ce qui suit est le répertoire après décompression du code source de Drupal 8.5.7 :

/core Dossier principal de Drupal, veuillez consulter les instructions ci-dessous pour plus de détails.

/modules. Modules personnalisés ou téléchargés

/profils stocke les fichiers de configuration personnalisés téléchargés et installés

.

Le dossier/sites, dans Drupal 7 ou versions antérieures, stocke principalement les thèmes et modules utilisés par le site et d'autres fichiers du site.

/themses stocke des thèmes personnalisés ou téléchargés

/vendor stocke les bibliothèques de dépendances de code

Ensuite, regardons la structure des répertoires sous le dossier core core

/core/assets - utilisé par Drupal Diverses bibliothèques d'extensions, telles que comme jquery, ckeditor, backbone, normalizeCSS, etc.

/core/config - le fichier de configuration de base dans Drupal

/core/includes - les fonctions fonctionnelles sous-jacentes modulaires, telles que le système modulaire lui-même

/ core/lib - le classe de base originale fournie par Drupal

/core/misc – les divers fichiers frontaux requis par le noyau, tels que JS, CSS, images, etc.

/core/modules – modules de base, environ 80 éléments

/core/profiles – fichiers de configuration d'installation intégrés

/core/scripts – divers scripts hit utilisés par les développeurs

/tests – utilisés pour tester les fichiers

/core/themes – Thème du noyau

Framework 3.2 exécutant la logique

Drupal est construit sur le framework open source symfony. Sur le site officiel de symfony, on peut voir que sysmfony est un ensemble de composants php réutilisables qui peuvent être utilisés pour convertir n'importe quel. Les composants sont utilisés indépendamment dans leurs propres applications. Chaque composant a une documentation indépendante sur le site officiel de symfony. Certains de ces composants sont directement utilisés par Drupal, et certains sont modifiés selon les propres caractéristiques de Drupal.

Jetons d'abord un coup d'œil au processus d'exécution de symfony

Drupal et symfony utilisent également le même concept dans la conception. Ils croient tous deux que tout système de site Web est en fait un système qui convertit les requêtes en réponses.

Dans le système de routage de Drupal, nous pouvons voir la relation entre les différents composants :

Sur cette base, Drupal a affiné le processus de traitement symfony, formant l'énorme processus de réponse de traitement Drupal actuel.

L'adresse du lien de l'image est https://www.drupal.org/docs/8/api/render-api/the-drupal-8-render-pipeline Si nécessaire, vous pouvez télécharger vous-même la version haute définition.

3.3 À en juger par le fichier d'entrée

Le fichier d'entrée est très concis, avec seulement 6 lignes de code, mais il traverse tout Drupal. Puisque le système de base de Drupal est trop volumineux, l'analyse. ne peut pas être exhaustif. Nous partirons de l’entrée Examinez le fichier ligne par ligne et analysez son processus en cours.

Premièrement, $autoloader =require_once 'autoload.php'; En apparence, il ne contient qu'un fichier autoload.php. En fait, Drupal utilisera le mécanisme de chargement automatique PHP pour créer un autoloader et obtenir un objet autoloader.

Jetons un bref aperçu du processus du point de vue du code : le processus de base consiste à appeler la fonction getLoader dans supplier/autoload.php.

Ensuite, nous entrons dans la fonction pour voir ce qu'elle fait :

L'objet ClassLoader utilise la correspondance de base définie à l'intérieur pour trouver les fichiers de définition de fonction et de classe.

La fonction renvoie enfin le chargeur d'instanciation. Maintenant, la première étape est terminée. Drupal n'aura plus besoin d'inclure manuellement beaucoup de fichiers, ce qui économisera beaucoup de travail.

Ensuite, $kernel =new DrupalKernel('prod', $autoloader); crée un nouvel objet noyau Drupal pour préparer le traitement de l'objet de requête à venir.

Après cette ligne de code se trouve $request= Request::createFromGlobals() dans le fichier d'entrée. Pour un système orienté objet, nous ne devons pas utiliser directement des variables globales telles que $_POST, $_GET, $_COOKIE, etc. Drupal les encapsule tous dans l'objet $request. Ce n'est pas seulement simple et pratique, mais vous permet également d'ajouter directement des fonctions supplémentaires et des attributs personnalisés à l'aide de l'objet demandé.

Enfin, les variables globales correspondantes seront ajoutées à l'objet de requête et l'objet de requête encapsulé sera renvoyé.

Si l'opération ci-dessus n'est qu'une étape préliminaire, alors la ligne de code suivante $response = $kernel->handle($request); commencera à se mettre au travail et le noyau objet du noyau Drupal traitera la requête. demande.

Le cœur du traitement de Drupal est le modèle d'écoute dans le modèle de conception. Il comprend une source d'événements, qui contient différents événements et niveaux d'événements. L'autre partie est le programme ou la fonction qui doit exécuter l'événement, nous l'appelons l'écouteur. Dans le processus de traitement des demandes, chaque fois qu'un nœud est atteint, un événement correspondant sera distribué et l'écouteur effectuera les opérations correspondantes en fonction de l'objet et du niveau d'événement obtenus.

​ Les événements principaux du système continuent d'utiliser les événements du framework symfony, situé dans kernelevents.php, qui contient huit cœurs :

​ ​ Const REQUEST = 'kernel.request' Avant d'exécuter un code dans le code du framework , le début de l'envoi de la requête est déclenché.

Const EXCEPTION = 'kernel.exception' Événement déclenché lorsqu'une exception non interceptée se produit.

Const VIEW = 'kernel.view' Déclenché lorsque la valeur de retour du contrôleur n'est pas une instance de réponse. À ce stade, le contrôleur renvoie le tableau de rendu pour un travail de rendu ultérieur.

Const CONTOLLER = 'kernel.controller' est déclenché lorsque le contrôleur correspondant est trouvé en analysant la requête request, et ce contrôleur peut être modifié.

Const CONTROLLER_ARGUMENTS = 'kernel.controller_arguments' Déclenché lors de l'analyse des paramètres du contrôleur, et les paramètres peuvent être modifiés.

Const RESPONSE = 'kernel.response' Déclenché lors de la création d'une demande de réponse, et peut modifier ou remplacer la réponse à laquelle répondre.

Const TERMINATE = 'kernel.terminate' sera déclenché une fois la réponse envoyée. Cet événement permettra de gérer des tâches lourdes après réponse.

Const FINISH_REQUEST = 'kernel.finish_request' Déclenché lorsque la requête de requête est terminée. Il peut réinitialiser l'état global et environnemental de l'application lorsque l'application est modifiée pendant la requête.

En plus de ces événements principaux, chaque auditeur dans Drupal envoie également ses propres événements. Les emplacements de ces fichiers se trouvent dans les dossiers correspondants sous le répertoire corelibDrupalCore. Ils se terminent tous par events.php et les variables d'événement statiques correspondantes sont définies dans le fichier.

  Jetons un coup d'œil au processus de requête Drupal Core :

Démarrez la requête ---》Analysez la requête pour obtenir le contrôleur et corrigez-la------》Analysez les paramètres du contrôleur----》Appelez-le selon la méthode du contrôleur -----》Observez la situation de retour du contrôleur : renvoie la réponse de l'objet de réponse ou continuez le rendu ------》Envoyez la réponse. Si une exception se produit au milieu de l'ensemble du processus, l'événement d'exception sera directement déclenché pour la distribution des exceptions. Dans l'ensemble du processus, en plus de répondre aux événements de requête principaux, l'objet de requête entrera également dans des branches qui répondent à d'autres événements de module courants en fonction de la situation réelle. Cependant, peu importe à quel point le processus est cahoteux, il finira par revenir au processus. processus principal et renvoie la réponse de l'objet de réponse.

Ensuite, observez les comportements spécifiques ci-dessus à partir du code source :

En continuant à suivre depuis index.php et en entrant dans le fichier drupalkernel.php, jetons un coup d'œil aux opérations qui ont été effectuées.

La prochaine étape est une série de chaînes d'appels de fonctions de traitement. Nous pouvons continuer à suivre la fonction handle, afin de pouvoir suivre directement la fonction principale handleraw

Ici, nous continuerons à suivre. et reviendra bientôt sur la fonction filterResponse.

Les objets de réponse ici seront renvoyés couche par couche (il convient de noter que tous les résultats de réponse ne passeront pas par ce processus), mais ils seront finalement encapsulés dans un objet de réponse et renvoyés au fichier index.php fichier. dans la variable $response. Appelez ensuite $response->send() pour envoyer l'objet de réponse encapsulé.

Parfois, le contenu de l'opération de requête que nous envoyons sera trop lourd, donc lorsque l'appel ci-dessus se terminera, notre noyau Drupal effectuera le traitement final avant de s'arrêter. Le processus entre dans la dernière ligne du fichier Index.php et appelle $kernel->terminate($request,$response). Nous suivons le fichier stackedhttpkernel.php selon la chaîne d'appel

À ce stade, le tout le cycle est terminé.

Nous avons constaté que l'opération la plus courante dans le processus ci-dessus est la répartition des événements. En fait, le processus de répartition est le même. Le processus spécifique de répartition se trouve dans le fichier ContainerAwareEventDispatcher.php. un exemple.

Il y a 19 auditeurs au total dans le système, et chaque auditeur aura un nom de service qui lui est associé. Nous ferons correspondre l'auditeur correspondant en fonction du nom de l'événement entrant, puis les traverserons et les appellerons un par un. fonction fonction correspondant au nom du service. Ce que nous avons ici est l'événement kernel.request, et la méthode appelante est un appel de rappel.

4. Regardez à nouveau CVE-2018-7600

Grâce à l'analyse simple du cadre dans la troisième partie, vous n'aurez peut-être qu'une vague idée du processus. Ensuite, nous combinerons des exemples de vulnérabilités pour cibler les plus classiques. vulnérabilité du framework Drupal cve-2018-7600 pour observer attentivement le processus de fonctionnement détaillé de cette vulnérabilité dans le framework. La version de l'environnement de déclenchement de vulnérabilité que nous utilisons ici est la 8.5.0. Cette version du déclencheur de vulnérabilité est plus intuitive, donc la version de code utilisée dans notre analyse ultérieure sera cette version, sauf indication contraire.

Comparaison des correctifs 4.1

Étant donné que cette vulnérabilité a été corrigée dans la version 8.5.1 et qu'il n'existe qu'une seule subversion entre 5.0 et 5.1, nous pouvons comparer plus clairement les différences dans le code source. Voyons comment le responsable corrige cette vulnérabilité : Dans le code source de la version 8.5.1, un nouveau fichier RequestSanitizer.php est ajouté, qui filtre la partie requête. Dans la méthode stripDangerousValues, il filtre celles commençant par # et non plus. les met sur liste blanche. Les valeurs de tous les noms de clés dans .

Dans la méthode prehandle, la nouvelle méthode ajoutée dans le fichier ci-dessus est appelée pour le filtrage. La partie rouge sur le côté droit de l'image ci-dessous est le code de filtrage ajouté en 8.5.1.

La position d'appel du code de filtrage ici est avant que le noyau Drupal ne traite la requête. Cela corrigera complètement la vulnérabilité une fois pour toutes.

Ensuite, nous sommes allés sur le site officiel de Drupal pour vérifier les documents officiels et avons constaté que l'API de rendu Drupal avait un traitement spécial pour le début de #. Le lien du document clé est ci-dessous

https://www.drupal. .org/docs/8/api/render -api/render-arrays et a publié un rapport sur les détails techniques de cette vulnérabilité selon l'équipe de sécurité du point de contrôle. Le lien est le suivant : https://research.checkpoint.com/uncovering-drupalgeddon-2/. Il a été constaté que la source du déclencheur de vulnérabilité est la fonction de téléchargement d'avatar dans la fonction utilisateur enregistré dans la version 8.5.0.

4.2 Le processus d'exécution des paquets de données dans le framework

Puisque nous connaissons la source de déclenchement de la vulnérabilité, nous téléchargeons d'abord une image et récupérons un package initial normal pour voir la situation.

Ensuite, dans le fichier d'entrée index.php, après avoir empaqueté la fonction createfromglobals, Drupal encapsule tous les paramètres que nous avons transmis dans l'objet de requête.

4.2.1KernelEvents::REQUEST événement de répartition

Depuis que le processus du framework a été introduit ci-dessus, voici l'étape du noyau Drupal traitant notre demande Ici, nous définissons directement le point d'arrêt sur handleRaw et entrons dans les premiers KernelEvents. ::REQUEST distribue un événement pour voir ce que les auditeurs ont fait avec cette demande.

Tout d'abord, Drupal essaie de traiter la demande d'option. Malheureusement, la nôtre est une demande POST, nous ne la traitons donc pas et la laissons passer directement.

Ensuite nous traiterons le problème des slash sur le chemin de l'URL, et convertirons le chemin commençant par plusieurs slash en un seul slash

Ensuite nous vérifierons l'identité en fonction de la demande, ce que nous n'avons pas fait ici. Vous vous connectez en tant que touriste, il n'y a donc pas de traitement spécial ici.

Ensuite, les paramètres cibles contenant $_GET['destination'] et $_REQUEST ['destination'] seront nettoyés pour empêcher les attaques de redirection.

Il sera ensuite jugé si la requête est une requête AJAX basée sur le paramètre _drupal_ajax dans la requête POST, et les attributs pertinents seront définis.

L'étape suivante consiste à faire correspondre la route correspondante en fonction de la partie URL de la requête. Ici, Drupal recherchera d'abord la correspondance correspondante dans le cache de route, et sinon, effectuera toutes les opérations de recherche de table de routage. (En raison de la grande quantité de code, nous n'intercepterons pas tout le code ici, mais seulement une partie du code). La fonction de traitement est dans onKernelRequest. En même temps, nous pouvons également trouver des informations pertinentes dans le user.routing. fichier yml.

L'itinéraire est trouvé, l'étape suivante est de vérifier si l'itinéraire est disponible

L'étape suivante est de vérifier si le site est en mode maintenance, s'il est en mode maintenance, déconnectez-vous de le compte, vérifiez si le site est hors ligne et vérifiez le cache de la page dynamique, prétraitez les paramètres de non-routage et voyez s'il convient de désactiver les serveurs de réplique en fonction des paramètres. Les fonctions associées à ces opérations sont des captures d'écran ci-dessous.

À ce stade, le comportement de tous les auditeurs de KernelEvents::REQUEST a été analysé que les opérations ci-dessus prennent principalement des mesures supplémentaires, que nous pouvons ignorer. nous en avons également extrait des informations précieuses et avons fait correspondre les informations de routage pertinentes via l'objet de requête.

4.2.2 Événements KernelEvents::CONTROLLER et KernelEvents::CONTROLLER_ARGUMENTS

Ensuite, dans la fonction handleraw, Drupal trouve le véritable contrôleur de requête et les paramètres correspondants grâce aux informations de routage qui viennent de correspondre.

Voyons d'abord quelles opérations les auditeurs de KernelEvents::CONTROLLER feront. ?                                                                                       OUT out out out of which conflict Entrez l'objet $event

.

Parce que KernelEvents::CONTROLLER_ARGUMENTS n'a pas son propre écouteur, il est donc distribué ici et publié directement.

4.2.3 Appel du contrôleur

Après avoir traité l'envoi d'événements liés à la requête dans handleRaw et trouvé le contrôleur correspondant à partir de la requête, il est temps de trouver la fonction de traitement correspondante basée sur le contrôleur. Le contrôleur dans call_user_function ci-dessous a été remplacé par la fonction de rappel de fermeture dans la figure ci-dessus. L'appel au contrôleur ici équivaut à saisir directement la fonction de fermeture dans la figure ci-dessus.

Dans Drupal, les contrôleurs seront ajoutés au contexte de rendu pour garantir que chaque contrôleur est rendu directement s'il y a un endroit qui nécessite un rendu pendant le traitement. fonctionner.

Selon le contrôleur saisissant la véritable méthode d'appel, qui est getContenResult, la construction du formulaire commence officiellement.

4.2.4 Construction du formulaire

Après avoir entré la fonction buildForm, nous obtiendrons d'abord les informations POST Et stocké dans form_state.

Dans la fonction retrieveForm de la fonction buildForm, le formulaire commence à être initialement assemblé S'il y a des éléments qui doivent être rendus, la plupart du temps Drupal. utilisera directement Drupal :: service('renderer')->renderPlain(); Ce service de rendu effectue des opérations de rendu sur les éléments, et l'opération principale de la fonction de rendu finale est dans la fonction doRender.

Une fois le formulaire assemblé selon la demande, la demande de formulaire sera traitée immédiatement. Ici, la fonction processForm effectue cette opération. , dans cette fonction, des opérations récursives sont utilisées pour traiter le comportement. La nôtre est une opération de téléchargement d'image, dans laquelle le comportement sera également traité, et l'image sera déplacée. Ensuite, vérifiez et vérifiez chaque élément et jeton, et enfin reconstruisez l'intégralité du formulaire en fonction des résultats.

Si vous souhaitez suivre le processus de traitement d'image dans processForm, vous pouvez définir des points d'arrêt directement sur la fonction ci-dessous et utiliser le traçage de la pile pour trouver ce vous vous souciez du fonctionnement.

 

Après avoir exécuté la fonction processForm, voici une capture d'écran d'une partie du formulaire FORM après reconstruction

#🎜🎜 #

À ce stade, toute l'opération de traitement du formulaire est terminée.

4.2.5 Répartition anormale.

Après avoir terminé l'opération de formulaire à l'étape précédente, l'objet requête a été converti en objet réponse sans le savoir. Il était sur le point de revenir couche par couche et d'effectuer l'opération d'envoi, mais lors du processus suivant, Drupal a découvert qu'il s'agissait d'une requête ajax, il a donc intercepté l'opération de manière proactive et a lancé une exception AJAX pour effectuer un traitement supplémentaire sur la requête.

Après avoir détecté l'exception, gérez l'exception et envoyez-la.

La répartition ici est en fait un processus de traversée et de mise en correspondance des exceptions. Il existe de nombreuses situations dans lesquelles des exceptions se produisent. Faites correspondre l'exception correcte, puis effectuez des actions spécifiques. traiter avec. S’il n’y a pas de correspondance, laissez tomber. Nous avons fait correspondre l'exception AJAX ici. Si vous êtes plus préoccupé par le processus de gestion d'autres exceptions, recherchez-la simplement dans le tableau kernel.exception.

Nous avons suivi et découvert qu'il existe une méthode spécifique pour gérer AJAX dans la fonction buildResponse de onException.

Dans la fonction uploadAjaxCallback, nous obtenons la valeur du paramètre element_parents à partir de l'URL du paquet de données, et l'utilisons comme clé pour obtenir le résultat du formulaire FORM que nous avons finalement traité, puis restituons le résultat et le présentons sur le Page HTML.

Sur la base des paramètres de l'URL dans notre package POST, nous retirons le premier élément du tableau de widgets sous user_picture dans le formulaire FORM.

      L'objet final à rendre dans doRender est l'élément qui vient d'être retiré.

Après le rendu, l'ensemble du processus de traitement touche à sa fin et la réponse commence à être construite et renvoyée couche par couche.

4.2.6 Événement kernel.response

Maintenant que nous avons atteint l'étape de réponse, nous devons commencer à déclencher la réponse. Ensuite, jetons un œil aux auditeurs de la réponse

Dans la répartition de la réponse. fonction, il s'agit essentiellement d'ajouter des briques et des tuiles à l'objet de réponse et d'effectuer certaines opérations d'expansion correspondantes. Par exemple, déterminez si une page dynamique doit être mise en cache, s'il est nécessaire d'ajouter un contexte de cache, de gérer des espaces réservés, de définir des en-têtes supplémentaires dans une réponse réussie, etc. Toutes les opérations ci-dessus seront dans le tableau kernel.response sous les écouteurs et ne seront pas présentées en détail ici.

4.2.7 kernel.finish_request

Lorsque les opérations de requête et de réponse sont terminées, le noyau Drupal sera informé que tout a été terminé et l'événement finish_request sera envoyé. Il n'y a qu'un seul écouteur pour cet événement : afin de permettre à l'URL du générateur de s'exécuter dans le bon contexte, nous devons définir la requête actuelle comme requête parent.

4.2.8 Événement kernel.terminate

Après avoir terminé l'opération ci-dessus, la requête de requête est extraite de la pile de requêtes et renvoyée à la page d'entrée principale Index.php couche par couche pour envoyer la réponse. Enfin, nettoyez le travail, déclenchez l'événement kernel.terminate et déterminez si les modifications pertinentes doivent être écrites dans le fichier. Finalement, le noyau Drupal s'arrête. Tout le processus est terminé.

4.3 Résumé de l'ensemble du processus

Nous avons décomposé l'ensemble du processus dans la section précédente. Résumons-le brièvement ci-dessous :

Envoyez le paquet de données --> Faites correspondre l'itinéraire concerné en fonction de l'URL --> l'itinéraire correspondant basé sur l'itinéraire Contrôleur --> Obtenir la méthode de traitement en fonction du contrôleur (nous effectuons ici des opérations liées au formulaire) --> Créer et afficher le formulaire --> ; Déterminer s'il s'agit d'une opération AJAX après le traitement du formulaire --> Lancer activement une exception et utiliser le rappel AJAX pour restituer la clé du formulaire FORM marquée dans l'URL --> > Envoyer la réponse ---> O V. Construction du POC de vulnérabilité

Sur la base de l'analyse et de la compréhension du cadre ci-dessus, le POC est construit. L'équipe de sécurité de Checkpoint a publié un rapport sur les détails techniques de cette vulnérabilité (lien ci-dessus). On peut voir que le point de déclenchement de la vulnérabilité est de déclencher une exception AJAX après la construction du formulaire, d'extraire l'objet à restituer du formulaire. FROM et le restituer Déclenché quand, c'est-à-dire dans la fonction doRender finale. Nous avons trouvé les points exploitables suivants dans doRender :

Sur la base de notre analyse du processus d'un package de téléchargement normal exécuté dans le framework dans la partie 4, nous savons que nous voulons que le contenu que nous avons construit déclenche avec succès la vulnérabilité dans doRender. . Tout d'abord, vous devez contrôler le processus et le laisser entrer dans la partie de rappel AJAX. Dans le jugement if ci-dessous, nous savons que trois conditions doivent être remplies en même temps, $ajax_form_request, $form_state->isProcessingInput() et $request->request->get('form_id')== $ form_id. Comme le montre la figure ci-dessous, la valeur de $ajax_form_request est contrôlée par la variable ajax_form et form_id est l'identifiant du formulaire.

Ensuite, utilisez la valeur du paramètre element_parents dans l'URL pour obtenir la valeur dans le tableau du formulaire. Il est décrit à la section 4.2.5 de la partie 4 et ne sera pas répété ici. Enfin, construisez les variables correspondantes et utilisez call_user_func_array dans la fonction doRender pour déclencher la vulnérabilité.

Sur la base de la description ci-dessus, nous avons utilisé les paramètres de courrier pour construire le package POC suivant

En plus du fait que les paramètres de courrier mentionnés ci-dessus sont contrôlables, il a également été constaté au cours du processus d'analyse que le paramètre form_build_id était également contrôlable. Un autre POC est le suivant.

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!