重新理解apache解析漏洞

漏洞成因非容器本身造成

参考链接：https://blog.csdn.net/qq_33020901/article/details/78952684

apache的文件解析漏洞

一直模糊的认为是apache本身的问题：Apache 解析文件的规则是从右到左开始判断解析,如果后缀名为不可识别文件解析,就再往左判断。

所以我以为apache后来已经修复了这个bug了，不会再出现文件解析漏洞了。

经过比对，我发现我本地上的php5.conf是这样写的：

 

➜cat /private/etc/apache2/other/php5.conf 

<IfModule php5_module> AddType application/x-httpd-php .php AddType application/x-httpd-php-source .php <IfModule dir_module> DirectoryIndex index.html index.php </IfModule> </IfModule>

 

而ubuntu上的php5.conf是这样的：

 

<FilesMatch ".+.ph(p[345]?|t|tml)$"> SetHandler application/x-httpd-php </FilesMatch> <FilesMatch ".+.phps$"> SetHandler application/x-httpd-php-source Order Deny,Allow Deny from all </FilesMatch> # Deny access to files without filename (e.g. '.php') <FilesMatch "^.ph(p[345]?|t|tml|ps)$"> Order Deny,Allow Deny from all </FilesMatch>

 

看ubuntu的配置

<FilesMatch ".+.ph(p[345]?|t|tml)$" >

这个正则和题目中的正则是一样的，很容易明白，当文件名和这个正则匹配上之后，就交给mod_php处理。

这就解释了为什么233%0a.php不会被解析的。

还有下面这段,也禁止解析以.开头的php文件执行的：

 

<FilesMatch "^.ph(p[345]?|t|tml|ps)$"> Order Deny,Allow Deny from all </FilesMatch>

 

所以我觉得产生文件解析漏洞的根源是这句话：

AddType application /x-httpd-php .php

为了验证我的想法，我把这句修改为下面这样，然后重启apache

AddType application /x-httpd-php .phtml

在这种情况下.php后缀已经不再被解析了，而被解析的是.phtml和.phtml.xxxxxxx

所以这样的错误配置才是引起apache 解析漏洞的关键。

最后感悟：无论是apache文件解析漏洞还是nginx文件解析漏洞，本来都不应该是apache，nginx 或者php的锅，它们有的只是功能，而且开发这些功能也是为了方便使用者，而恰好这些功能恰好被一个管理员用在了不恰当的时候，所以才造成了漏洞。