Apache和PHP三种结合方法、三种MPM模式及解析漏洞

浅浅的花香味﹌ 2023-03-01 10:52 40阅读 0赞

### 目录 ###

*   *  apache的三种MPM模式
     *   *   *  a、prefork
             *   *   *  优点
                     *  缺点
             *  b、worker
             *   *   *  优点
                     *  缺点
             *  c、event
     *  Apache和PHP三种结合方法
     *   *   *  a、模块化模式：
             *  b、CGI模式\[CGI：Common Gateway Interface\]
             *  c、fastCGI模式
     *  解析漏洞

## apache的三种MPM模式 ##

#### a、prefork ####

为了减少频繁创建和销毁进程的开销，apache在启动之初，就预先fork一些子进程，然后等待请求进来。每个子进程只有一个线程，在一个时间点内，只能处理一个请求。

###### 优点 ######

成熟稳定，兼容所有新老模块。同时，不需要担心线程安全的问题。

###### 缺点 ######

一个进程相对占用更多的系统资源，消耗更多的内存。而且，它并不擅长处理高并发请求，在这种场景下，它会将请求放进队列中，一直等到有可用进程，请求才会被处理。

#### b、worker ####

使用了多进程和多线程的混合模式。也预先fork了几个子进程（数量比较少），一个子进程创建很多线程，同时包括一个监听线程。每个请求过来，会被分配到1个线程来服务。线程比起进程会更轻量，因此，内存的占用会减少一些。在高并发的场景下，比起prefork有更多的可用线程，表现会更优秀一些。

至于为什么不使用单进程多线程，还要引入多进程。

是考虑稳定性，如果一个线程异常挂了，会导致父进程及父进程下的其他的正常子线程都挂了。为了防止全盘崩溃，就使用多进程多线程，这样如果某个线程出现异常，受影响的只有它父进程下的线程

###### 优点 ######

占据更少的内存，高并发下表现更优秀。

###### 缺点 ######

必须考虑线程安全的问题，因为多个子线程是共享父进程的内存地址的。如果使用keep-alive的长连接方式，某个线程会一直被占据，也许中间几乎没有请求，需要一直等待到超时才会被释放。如果过多的线程，被这样占据，也会导致在高并发场景下的无服务线程可用。（该问题在prefork模式下，同样会发生）

#### c、event ####

这个模式是Apache中最新的模式，在现在版本里已经稳定可用了。它和worker模式很像。

但是，它解决了keep-alive场景下，长期被占用的线程的资源浪费问题（某些线程因为被keep-alive，空挂在哪里等待，中间几乎没有请求过来，甚至等到超时）。

在event MPM中，会有一个专门的线程来管理这些keep-alive类型的线程，当有真实请求过来的时候，将请求传递给服务线程，执行完毕后，又允许它释放。这样增强了高并发场景下的请求处理能力。

event MPM在遇到某些不兼容的模块时，会失效，将会回退到worker模式，一个工作线程处理一个请求。官方自带的模块，全部是支持event MPM的。

注意一点，event MPM需要Linux系统（Linux2.6+）对EPoll的支持，才能启用。

## Apache和PHP三种结合方法 ##

#### a、模块化模式： ####

apache和php安装在同一台服务器中，把PHP编译为Apache模块，也是用的最多的一种方法

#### b、CGI模式\[CGI：Common Gateway Interface\] ####

以一种CGI模式， 将apache服务递交给PHP服务器，共同网关接口，是HTTP服务器与机器上其他程序进行通信的一个接口，让WEb服务器必要时启动额外的程序处理动态内容。

#### c、fastCGI模式 ####

动态服务器和静态服务器分离，让CGI解释器得意更快实现，可以提供良好的性能、伸缩性、Fail-Over特性等

## 解析漏洞 ##

在apache/conf目录下有个mime.types文件，这里记录了大量的文件后缀和mime类型，当客户端请求一个文件时，如果后缀在这个列表里，那么Apache就返回对应的content-type给浏览器。如果不在列表，Apache不会返回content-type给浏览器，而是直接返回文件内容。  
很多web服务器使用默认的 application/octet-stream 来发送未知类型  
![在这里插入图片描述][20200725184450937.png]

Apache文件解析漏洞涉及到一个文件解析的特性：Apache默认一个文件可以有多个以点分割的后缀，从右往左识别，当最右边的后缀无法识别（即不在mime.types内），就继续向左识别，直到全部识别完毕。

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80NTY2MzkwNQ_size_16_color_FFFFFF_t_70]

举个例子，如果有这么一个文件1.php.txt.abc.xyz，最末尾的.xyz无法识别，向左移；.abc还是无法识别，向左移；.txt可以识别，于是就把它当做txt文档。虽然.php也同样可以识别，但是因为.txt在它前面，所以还轮不到它  
![在这里插入图片描述][20200725164522323.png]

使用module模式与php结合的所有版本 apache存在未知扩展名解析漏洞，使用fastcig模式与php结合的所有版本apache不存在此漏洞。

所以，想利用此漏洞必须保证文件扩展名中 至少带有一个“.php”，否则有可能被当作默认的txt/html文档处理。

解析漏洞部分参考来源：[https://www.cnblogs.com/milantgh/p/5116955.html][https_www.cnblogs.com_milantgh_p_5116955.html]

[20200725184450937.png]: /images/20230208/c3e7c43486184172a1886eed7c7ea6df.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80NTY2MzkwNQ_size_16_color_FFFFFF_t_70]: https://img-blog.csdnimg.cn/20200725165754556.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80NTY2MzkwNQ==,size_16,color_FFFFFF,t_70
[20200725164522323.png]: https://img-blog.csdnimg.cn/20200725164522323.png
[https_www.cnblogs.com_milantgh_p_5116955.html]: https://www.cnblogs.com/milantgh/p/5116955.html