drupal8代码结构及运行流程分析

前言

在之前分析CVE-2018-7600时，对drupal的代码不熟悉，本想完整的分析整个流程，无奈水平不够，只能在漏洞出现的位置打断点调试。对一个ajax请求为什么会由那段代码处理完全不了解。后来复现drupal其他漏洞时，看代码也很吃力，所以对drupal的代码结构和运行流程进行一次分析，消除知识盲点。

目录结构

drupal865/
|-- core/ 					#drupal核心代码
|-- modules/				#存放自定义和下载的模块
|-- profiles/				#存放自定义配置文件
|-- sites/					#存放数据库配置等站点相关文件
|-- themes/					#存放自定义和下载的主题
|-- vendor/					#代码依赖库
|-- example.gitignore
|-- index.php				#入口文件
|-- INSTALL.txt
|-- LICENSE.txt
|-- autoload.php
|-- update.php
|-- composer.json
|-- composer.lock
|-- README.txt
|-- robots.txt
`-- web.config

其中core目录下存放了drupal的核心代码，看一下core目录的结构：

drupal865/core/
|-- assets		#存放第三方js，css等文件
|-- config		#存放核心配置文件
|-- includes    #功能性函数库
|-- lib			#drupal原生核心类
|-- misc		#drupal运行所需的前端文件
|-- modules		#drupal自带的模块，应用逻辑大部分在这里面
|	|-- example
|   |   |   `-- example.info.yml 	#模块详细信息
|   |   |   `-- example.route.yml	#模块路由信息 
|-- profiles	#配置文件
|-- scripts		#开发人员使用的命令行脚本
|-- tests		#测试文件
`-- themes		#drupal自带主题

每个模块的目录中都会有一个module_name.route.yml，用来记录该模块所有的路由信息，可以通过阅读这个文件迅速建立url与代码的对应关系。

这是文档：https://www.drupal.org/docs/8/api/routing-system/structure-of-routes

运行流程

drupal官方提供了一个非常详细的运行流程图，由于图太大，这里附上链接：

https://www.drupal.org/files/d8_render_pipeline_0.pdf

接下来我们在代码层面看一下drupal到底是如何运行的。

index.php

<?php

use Drupal\Core\DrupalKernel;
use Symfony\Component\HttpFoundation\Request;

$autoloader = require_once 'autoload.php'; //类自动加载

$kernel = new DrupalKernel('prod', $autoloader); //实例化一个drupal内核对象用于处理请求

$request = Request::createFromGlobals(); //将发送来的请求封装成Request对象
$response = $kernel->handle($request); //**将请求转化为响应**
$response->send(); //将响应返回给用户

$kernel->terminate($request, $response); //结束整个过程

如果了解过symfony的http-kernel组件，就会发现drupal入口文件的内容与http-kernel官方文档给出的demo非常像，文档在这：https://symfony.com/doc/2.7/components/http_kernel.html。

drupal处理请求是以symfony的http-kernel组件为基础的，并对处理流程进行了细化。

阅读文档，我们可以得知symfony的http-kernel的设计理念是将请求转化为响应。它是以事件来驱动运行的，会创建一个event dispatcher用来分发各种event，再由event listener来处理event，所有的操作都通过这种形式来完成。

请求预处理

下面跟进handle方法：

core/lib/Drupal/Core/StackMiddleware/KernelPreHandle.php

在处理之前会进入preHandle方法进行过滤。

core/lib/Drupal/Core/DrupalKernel.php

将request对象传入RequestSanitizer类进行过滤。

core/lib/Drupal/Core/Security/RequestSanitizer.php

对用户传入的信息进行解析，并在processParameterBag方法中调用了stripDangerousValues方法。

该方法对输入进行递归过滤，将#开头的参数全部过滤。这正是CVE-2018-7600的修补方法，在正式开始处理请求之前，就对传入的参数进行了过滤。

core/lib/Drupal/Core/DrupalKernel.php

在过滤完之后，又进行一系列的准备工作，下面就正式开始处理请求。

请求处理

vendor/symfony/http-kernel/HttpKernel.php

这里派发了一个REQUEST事件，开始处理请求。

首先根据event_name获取到对应的event_listener，然后遍历listener中对event的操作，开始处理event。

这里的操作包括处理OPTION请求、处理url中/的问题、权限认证等等，由于篇幅问题，没办法一一展示，有兴趣的可以每个跟进去看一下。这里想着重看一下根据url匹配路由的过程，因为在个人看来，理清一个框架很重要的一步就是了解它的路由，这样才能在代码与页面之间建立一种对应关系。

vendor/symfony/http-kernel/EventListener/RouterListener.php

这里对request对象进行解析，获取到了路由相关的信息，跟进去看一下：

经过一系列调用来到core/lib/Drupal/Core/Routing/RouteProvider.php：

首先获取路由信息对应的缓存id，如果信息已经缓存，就直接取出返回。如果没有缓存，就继续查找路由信息，并在得到路由信息后存入缓存，减少查询次数提高效率。继续跟进getRoutesByPath方法：

可以看到路由信息是存在数据库中的，详细信息经过序列化。

调用对应的控制器

vendor/symfony/http-kernel/HttpKernel.php

回到HttpKernel.php，REQUEST事件处理完之后，分发CONTROLLER事件找到对应的controller，分发CONTROLLER_ARGUMENTS事件获取controller函数。处理完之后，调用controller，完成request到response的转化。跟进去看一下：

core/lib/Drupal/Core/EventSubscriber/EarlyRenderingControllerWrapperSubscriber.php

这里用闭包调用的方式对controller进行了一次包装，继续跟进：

这里才真正调用了路由对应的控制器，在控制器中有多种情况，大致处理流程如下：

controller的返回值有两种：a renderable array或者一个Symfony\Component\HttpFoundation\Response类型的对象。

请求转化为响应

这里我们选择一种较为复杂的情况进行分析，以CVE-2018-7600中的图片上传流程为例进行分析：

core/lib/Drupal/Core/Controller/FormController.php

首先根据路由和form参数生成一个form对象，接着实例化一个FormState对象，用于存储表单的各种状态。

这里介绍一下drupal的form api，使用它可以方便的创建和管理表单。一个form对象由这么几个基本方法：

getFormId: 必须定义的方法，返回表单机器名。
buildForm: 必须定义的，它返回一个渲染数组，类似 hook_form。
validateForm: 是可选的，进行校验，类似 hook_form_validate。
submitForm: 执行提交处理，类似 hook_form_submit。

文档在这：https://www.drupal.org/docs/8/api/form-api/introduction-to-form-api