php 操作系统之间的一些黑魔法(绕过文件上传a.php/.)
http://wonderkun.cc/index.html/?p=626
0x00 前言
做了一个CTF题目，遇到了一些有趣的东西，所以写了这篇文章记录了一下。 但是我却不明白造成这个问题的原因在哪里，所以不知道给文章起什么标题，就姑且叫这个非常宽泛的名字吧。
0x01 CTF题目原型
在遇到的题目中，最后一步是getshell，大概可以简化为以下代码：
|
我把这个问题发到phithon的代码审计圈里征求答案，师傅们的答案都在理，但是却不是我想要的那个答案，下面就来一一的分析以下。
0x02 一些不完美的做法
我最开始的想法跟大多数师傅的想法一样
|
在我本地测试一下，一切都是那么的美好，轻松getshell:
我本地的环境是 mac默认安装的apache+php。
当我在ubuntu上测试的时候傻眼了，
ubuntu上的apache并没有把这个文件当做php文件来解析。这到底是为什么呢？这里先留个坑，一会仔细讲。
这种方法不行之后，很快就有人想到了，会不是是apache2的文件解析漏洞呢？然后我就在ubuntu上测试了一下
apache的版本是2.4.7，并不存在解析漏洞。
然后我又在本地测试了一下。
What fuck!!! 我的本地竟然存在php文件解析漏洞，这笔记本是假的吧，装的apache也是假的吧。版本都是2.4.25了怎么还会存在文件解析漏洞呢？
在我的印象中apache的文件解析漏洞是在2.3.x以下版本才会存在的啊？这到底是为什么？
之后朋友又给我发来了一张图片，我当时就炸毛了，他的版本是2.4.18，并不存在漏洞。我觉得我这apache可能是假的。
经过冷静的思考，我得出结论：Apache文件解析漏洞，可能与apache的版本并没有关系，而是与apache解析php的配置相关。
0x03 再提apache的文件解析漏洞
apache的文件解析漏洞正火的时候，我还没上大学呢，所以也没有真正的去分析产生这种漏洞的原因，一直模糊的认为这是apache本身的问题：Apache 解析文件的规则是从右到左开始判断解析,如果后缀名为不可识别文件解析,就再往左判断。
所以我以为apache后来已经修复了这个bug了，不会再出现文件解析漏洞了。
经过比对，我发现我本地mac上的php5.conf是这样写的：
|
而ubuntu上的php5.conf是这样的：
|
看ubuntu的配置
|
这个正则和题目中的正则是一样的，很容易明白，当文件名和这个正则匹配上之后，就交给mod_php处理。
这就解释了为什么233%0a.php不会被解析的。
还有下面这段,也禁止解析以.开头的php文件执行的：
|
所以我觉得产生文件解析漏洞的根源是这句话：
AddType application
/x-httpd-php
.php
|
为了验证我的想法，我把这句修改为下面这样，然后重启apache
AddType application
/x-httpd-php
.phtml
|
在这种情况下.php后缀已经不再被解析了，而被解析的是.phtml和.phtml.xxxxxxx
所以这样的错误配置才是引起apache 解析漏洞的关键。
最后感悟：无论是apache文件解析漏洞还是nginx文件解析漏洞，本来都不应该是apache，nginx 或者php的锅，它们有的只是功能，而且开发这些功能也是为了方便使用者，而恰好这些功能恰好被一个管理员用在了不恰当的时候，所以才造成了漏洞。
0x04 回到题目中
经过测试发现一个可以再windows和linux上都行得通的方法：
filename=1.php/.&content=
|
在操作系统中，都是禁止使用/作为文件名的，但是不知道为什么后面加一个.就可以成功的写入1.php了。
而且奇怪的是无论是在windows上还是linux上，每次都只可以创建新文件，不能覆盖老文件。要想知道php里面是怎么处理这个路径的，就需要看php源代码了，但是我目前并没有看明白里面的处理逻辑，等我抽个时间分析完了，再做补充吧。