文件解析漏洞，是指中间件（Apache、nginx、iis等）在解析文件时出现了漏洞，从而，黑客可以利用该漏洞实现非法文件的解析。
需要注意的是解析漏洞与上传漏洞是两码事，文件解析漏洞是基于文件上传之后而言的。
比如，Apache中间件，是c、c++混合写成的，当Apache中间件出现了解析漏洞，即：c、c++编程出现了漏洞，无论我们php代码层面如何的安全，都没办法抵挡黑客的攻击，因为现在的漏洞已经与php代码层无关了，已经是底层的安全问题了，文件解析漏洞就是因为Apache中间件c、c++编程出现了漏洞，导致黑客可以利用该漏洞解析非法文件。
所以，底层安全比任何安全都要重要，至少我们从现在起，要开始重视底层安全了。
Apache解析php文件原理：
Apache（httpd.exe）运行之后，然后开始监听web浏览器发送的php请求，拦截php请求，简单处理之后，再将该请求告知php解析器（Apache module 或者 fast-CGI）解析特定的php文件，php解析器解析文件完成之后，返回html页面给Apache，Apache再将html页面响应到web浏览器，就这样如此循环。
Apache有两种方式解析php文件：
1、 module方式
2、 fast-cgi方式
任何一种方式都可以在httpd.conf文件中设置
1、CGI方式
PHP 在 Apache 2.0 中的 CGI 方式
ScriptAlias /php/ "c:/php/"
AddType application/x-httpd-php .php
# 对 PHP 4 用这行
Action application/x-httpd-php "/php/php.exe"
# 对 PHP 5 用这行
Action application/x-httpd-php "/php/php-cgi.exe"
2、APACHE Module方式
PHP 在 Apache 2.0 中的模块方式
# 对 PHP 4 用这两行：
LoadModule php4_module "c:/php/php4apache2.dll"
# 别忘了从 sapi 目录中把 php4apache2.dll 拷贝出来！
AddType application/x-httpd-php .php
# 对 PHP 5 用这两行：
LoadModule php5_module "c:/php/php5apache2.dll"
AddType application/x-httpd-php .php
# 配置 php.ini 的路径
PHPIniDir "C:/php"
这两种解析方式的区别：
在CGI模式下，如果客户机请求一个php文件，Web服务器就调用php.exe去解释这个文件，然后再把解释的结果以网页的形式返回给客户机。而在模块化(DLL)中，PHP是与Web服务器一起启动并运行的。所以从某种角度上来说，以apache模块方式安装的PHP4有着比CGI模式更好的安全性以及更好的执行效率和速度。
Fast-CGI是什么？
FastCGI是语言无关的、可伸缩架构的CGI开放扩展，其主要行为是将CGI解释器进程保持在内存中并因此获得较高的性能。众所周知，CGI解释器的反复加载是CGI性能低下的主要原因，如果CGI解释器保持在内存中并接受FastCGI进程管理器调度，则可以提供良好的性能、伸缩性、Fail-Over特性等等。
Fast-CGI的工作原理：
1、 Web Server 启动时载入FastCGI进程管理器（IIS ISAPI或Apache Module）
2、FastCGI进程管理器自身初始化，启动多个CGI解释器进程 (在任务管理器中可见多个php-cgi.exe)并等待来自Web Server的连接。
3、当客户端请求到达Web Server时，FastCGI进程管理器选择并连接到一个CGI解释器。Web server将CGI环境变量和标准输入发送到FastCGI子进程php-cgi.exe。
4、FastCGI子进程完成处理后将标准输出和错误信息从同一连接返回Web Server。当FastCGI子进程关闭连接时，请求便告处理完成。FastCGI子进程接着等待并处理来自FastCGI进程管理器（运行在 WebServer中）的下一个连接。 在正常的CGI模式中，php-cgi.exe在此便退出了。
在上述情况中，你可以想象 CGI通常有多慢。每一个Web请求PHP都必须重新解析php.ini、重新载入全部dll扩展并重初始化全部数据结构。使用FastCGI，所有这些都只在进程启动时发生一次。一个额外的好处是，持续数据库连接(Persistent database connection)可以工作。
接下里，回到正题
在Apache解析正常php文件的时候，当然是没有什么大问题的，但是，当出现畸形文件的时候，Apache又该如何处理呢？
其实，在httpd.conf文件中，有个设置：DefaultType text/plain
这个设置告诉我们，Apache在遇到无法识别的文件时，他会做出怎么的反应
DefaultType text/plain
在这样的设置前提下，当Apache遇到无法识别的文件时，就会将这些无法识别的文件通通作为文本文件来解析。
在此，无法识别是什么意思呢？
原来，在Apache的conf目录下面有个mime.types文件（Linux在etc/mime.types），这个文件的内容就是Apache预定义的一些可以正常解析的文件。
比如，图片文件：
image/g3fax g3
image/gif gif
image/ief ief
# image/jp2
image/jpeg jpeg jpg jpe
# image/jpm
# image/jpx
# image/naplps
image/png png
当Apache遇到正常文件，却无法解析的时候，你可以在这里面手动添加解析类型
比如，你想下载一个word文档，但是，webserver（Apache）却把word文档以rar文件的形式返回给你，这种情况，就是因为Apache没有在mime.types文件（或是httpd.conf文件）中识别到word文档，那么，他只能通过分析该文档的本身内容，认为他是一个压缩文件，最后，就返回给你一个压缩文件了，至于是什么格式的压缩文件，只有Apache才知道了。
此时，如果我们要Apache能正常识别word文档，就需要在mime.types文件中加上以下三句话：
application/vnd.ms-word.document.macroEnabled.12 docm
application/vnd.openxmlformats-officedocument.wordprocessingml.document docx
application/vnd.openxmlformats-officedocument.wordprocessingml.template dotx
这样，Apache就可以正常给你返回word文档了。
其实，也可以在http.conf文件中设置文件解析类型
使用Apache的AddType 指令设置：
AddType application/vnd.ms-word.document.macroEnabled.12 docm
AddType application/vnd.openxmlformats-officedocument.wordprocessingml.document docx
AddType application/vnd.openxmlformats-officedocument.wordprocessingml.template dotx
建议不要去修改mime.types文件，添加文件解析类型推荐使用Apache的AddType指令。
因此，在mime.types文件或者httpd.conf文件中都无法识别的文件解析类型，Apache就会默认按照DefaultType text/plain这个字段给出的值来解析这个无法识别的文件，也许在使用这个值之前，还有一段解析验证，比如，下载word文档而返回rar文件，这个还有待考证。
有兴趣的可以研究下Apache的源代码
|-- build 安装脚本
| |-- pkg
| |-- rpm
| `-- win32
|-- docs 文档
| |-- cgi-examples
| |-- conf
| |-- docroot
| |-- error
| |-- icons
| |-- man
| `-- manual
|-- include 头文件
|-- modules apache模块
| |-- aaa 各种auth,都是a开头的，所以叫aaa?
| |-- arch 和系统相关的mod
| |-- cache 缓存相关。disk/file/mem cache
| |-- database mod_dbd是用来连接关系数据库的
| |-- dav mod_dav
| |-- debug 几个调试相关的mod mod_dumpio mod_bucketeer
| |-- echo 代码很短。这个mod应该是mod开发参考用的吧
| |-- experimental mod_example是一个注释很详细的mod，果然是mod——example
| |-- filters 过滤器：mod_filter
| |-- generators 处理器mod： asis info cgi(d) status autoindex suexec
| |-- http mod_mine : 根据文件扩展名决定应答的行为和内容
| |-- ldap mod_ldap : 提供ldap连接
| |-- loggers 各种日志 ：mod_logconfig mod_log_forensic mod_logio
| |-- mappers 在客户端到generator过程中进行重定向的许多mod
| |-- metadata 感觉像Miscellaneous，许多东西，不知道为什么放在一起
| |-- proxy 自然是mod_proxy,将请求proxy到其他程序
| |-- ssl 提供ssl连接
| `-- test
|-- os 操作系统相关的东西，各个不同的操作系统需要定义各自的宏，还有少量特别的函数
| |-- beos
| |-- bs2000
| |-- netware
| |-- os2
| |-- tpf
| |-- unix
| `-- win32
|-- server apache核心程序httpd就是这里来的
| `-- mpm
|-- srclib
| |-- apr apr和apr-util是apache的底层库，强调的是Portable
| |-- apr-util
| `-- pcre PCRE是一个Perl库，包含了perl兼容的正规表达式库
|-- support apache运行的一些工具，bin里面除了httpd几乎都在这里了
| |-- SHA1
| `-- win32
`-- test
这是Apache的源代码结构
那么，我们的文件解析漏洞是发生在那个分支上呢？
这个问题就留给大家去解决了。
接下里，说一下filefuzz技术
文件解析漏洞的挖掘，推荐两款框架/工具：Sulley Fuzz、Peach Fuzz
其实，这两款框架/工具学起来还是比较费时的，我再推荐一款简单的fuzz插件
Fuzzdb：fuzzdb是一个应用程序模糊测试(fuzzing)数据库，fuzzdb聚集到最全面的恶意软件和恶意的输入测试用例的开放源码数据库的攻击模式。
该数据库收集了大量已知的攻击模式，如XSS，Xpath注入，SQL注入，XML攻击，本地文件包含，路径遍历，远程文件包含，ldap攻击，格式化字符串，http协议攻击等。
该插件与burpsuite的intruder功能结合，十分强大，可与AWVS、sqlmap、pangolin等工具匹敌了！