陪着小组复习解析漏洞 这里再做次笔记吧。
常见的解析漏洞类型
IIS6两个解析漏洞
很老很老的东西了，还是再次记录一次，偶尔会遇到。
1、当WEB目录下，文件名以 xxx.asp;xxx.xxx 来进行命名的时候，此文件将送交asp.dll解析(也就是执行脚本)
2、当WEB目录下，在访问以 xxx.asp 命名的目录下的任意文件时，此文件将送交asp.dll解析(也就是执行脚本)
IIS 6.0在处理含有特殊符号的文件路径时会出现逻辑错误，从而造成文件解析漏洞。这一漏洞有两种完全不同的利用方式：
/test.asp/test.jpg
test.asp;.jpg
第一种是新建一个名为“test.asp”的目录，该目录中的任何文件都被IIS当做asp程序执行（特殊符号是“/”）；第二种是上传名为“test.asp;.jpg”的文件，虽然该文件真正的后缀名是“.jpg”，但由于含有特殊符号“;”，仍会被IIS当做asp程序执行。
原理大抵是IIS 5.x/6.0在从文件路径中读取文件后缀时，遇到一个“.”后，便进入了一种截断状态，在该状态下遇到特殊符号——“/”和“;”，都会进行截断，只保留特殊符号前的部分，即：“.asp”，从而认为文件后缀为“.asp”。
第一种情况
截断 发现保存文件的路径在请求包中 如下构造upfile/1.asp/
访问:
第二种情况
上传1.php;.jpg
IIS7畸形解析漏洞
准确说下范围 IIS 7.0/IIS 7.5/ Nginx <8.03畸形解析漏洞
在默认Fast-CGI开启状况下,上传一个名字为1.jpg，访问时候1.jpg/.php会以php来解析
IIS和Nginx在这一点上是一样的，一看到URL中文件后缀是.php，便无论该文件是否存在，都直接交给php处理，而php又默认开启“cgi.fix_pathinfo”，会对文件路径进行“修理”，何谓“修理”？举个例子，当php遇到文件路径“/aaa.xxx/bbb.yyy/ccc.zzz”时，若“/aaa.xxx/bbb.yyy/ccc.zzz”不存在，则会去掉最后的“/ccc.zzz”，然后判断“/aaa.xxx/bbb.yyy”是否存在，若存在，则把“/aaa.xxx/bbb.yyy”当做文件“/aaa.xxx/bbb.yyy/ccc.zzz”，若“/aaa.xxx/bbb.yyy”仍不存在，则继续去掉“/bbb.yyy”，以此类推。
若有文件test.jpg，访问时在其后加/.php，便可以让IIS把“test.jpg/.php”交给php，php“修理”文件路径“test.jpg/.php”得到“test.jpg”，该文件存在，便把该文件作为php程序执行了。下图所示
asp没有“cgi.fix_pathinfo”，所以不存在这一问题。
apache两个解析漏洞
首先是CVE-2017-15715
Apache版本在2.4.0到2.4.29
在默认配置下, “上传”一个带“换号符”的php文件上去，使用http://ip/test.php%0a访问，可直接解析PHP内容。
对上传包进行以下修改：在1.php后添加x0a,成功上传
比如上传一个“6.php换行符”文件。（上传过程后文有记载，在linux可使用如下方法发现文件名后面有换行符：“cat 文件名前部分+Tab键”，如cat 6.p+Tab键）
第二个是未知文件名后缀解析
在Apache 1.x和Apache 2.x中1.php.rar会被当作php文件执行。
Apache在解析文件时有一个原则：当碰到不认识的扩展名时，将会从后面向前解析，直到碰到认识的扩展名为止。
例 上传文件：
1.php.aa.bb
后缀名bb 不认识,向前解析
1.php.aa
后缀名aa 不认识 向前解析
1.php 最终解析结果为PHP文件
这种方法可以绕过基于黑名单的检查。（如网站限制,不允许上传后缀名为PHP的文件）
Apache认识的扩展名保存在安装目录下"/conf/mime.types"文件中。
nginx三个解析漏洞
第一个是错误配置导致解析漏洞
该解析漏洞和php、Nginx版本无关。
这其中涉及到php的一个选项：cgi.fix_pathinfo，该值默认为1，表示开启。
Nginx解析漏洞利用方式：
上传free.jpg，访问:
/free.jpg/free.php
这样就会以php去解析这个free.jpg文件的内容
为何是Nginx中的php才会有这一问题呢？因为Nginx只要一看URL中路径名以.php结尾，便不管该文件是否存在，直接交给php处理。而如Apache等，会先看该文件是否存在，若存在则再决定该如何处理。cgi.fix_pathinfo是php具有的，若在php前便已正确判断了文件是否存在，cgi.fix_pathinfo便派不上用场了，这一问题自然也就不存在了。（IIS在这一点和Nginx是一样的，同样存在这一问题）
Nginx 00截断解析漏洞
Nginx如下版本：
0.5.*, 0.6.*, 0.7 <= 0.7.65, 0.8 <= 0.8.37
在使用PHP-FastCGI执行php的时候，URL里面在遇到%00空字节时与FastCGI处理不一致，导致可在非php文件中嵌入php代码，通过访问url+%00.php来执行其中的php代码。如：http://local/robots.txt%00.php会把robots.txt当php解析
利用方式：
/test.jpg%00.php
CVE-2013-4547 nginx解析漏洞
影响范围也比较大：
0.8.41～1.4.3， 1.5 <= 1.5.7这一漏洞的原理是非法字符空格和截止符（ ）会导致Nginx解析URI时的有限状态机混乱，危害是允许攻击者通过一个非编码空格绕过后缀名限制。是什么意思呢？举个例子，假设服务器上存在文件：“file.aaa ”，注意文件名的最后一个字符是空格。则可以通过访问：
http://127.0.0.1/file.aaa 0.bbb
让Nginx认为文件“file.aaa ”的后缀为“.bbb”。
来测试下，这次测试在Nginx/1.0.15中进行。首先准备一张图片，命名为“test.html ”，注意，文件名含有空格。然后在浏览器中访问该文件，会得到一个404，因为浏览器自动将空格编码为%20，服务器中不存在文件“test.html%20”。
测试目标是要让Nginx认为该文件是图片文件并正确地在浏览器中显示出来。我们想要的是未经编码的空格和截止符（ ），怎么办呢？使用Burp Suite抓取浏览器发出的请求包，修改为我们想要的样子，原本的URL是：http://192.168.56.101/test.htmlAAAphp ,将第一个“A”改成“20”（空格符号的ASCII码），将第二个“A”改成“00”（截止符），将第三个“A”改成“2e”（“.”的ASCII码），如下图所示：
修改完毕后Forward该请求，在浏览器中看到：
当security.limit_extensions没有设置时候会当做php执行。
总结中很多图是截图的其他师傅的博客，附上链接:
https://cloud.tencent.com/developer/news/338482
https://blog.csdn.net/wn314/article/details/77388337
https://blog.csdn.net/wn314/article/details/77388289/