CVE-2013-4547是Nginx中间件的一个文件名解析漏洞
漏洞原理
【注：下文中[]表示字节】
以vulnhub提供的漏洞环境为例，我们首先看一下前端页面
再看一下后端的过滤
目前的情况看来我们不能传后缀名为php这一类的文件，那么我们就把文件后缀名改为jpg吧，然后上传
我们尝试访问下
看来上传成功了，我们得想办法执行，nginx不是把所有后缀名为php的文件交给fastcgi处理吗？尝试把文件名改为abc.jpg.php然后访问下，看看有什么效果
嗯。。。。不对，上述响应信息说明nginx已经把abc.jpg.php交给fastcgi处理了但是它发现没有这个文件（这时候cgi.fix_pathinfo可发挥不了作用啊）。我们接下来使用零截断试试，这样nginx同样会把abc.jpg[00].php交给fastcgi，在fastcgi里截断然后文件就可以编程abc.jpg了，下面看一下结果：
看一下响应好像并没有我们想象中那样，响应信息什么也没有！通过调试我们可以发现nginx发现文件名中存在\0截断符时会返回错误信息代码如下所示，这也就是为什么我们上面没有接收到任何的响应信息原因：
case '\0':
return NGX_HTTP_PARSE_INVALID_REQUEST;
在仔细调试代码发现但如果nginx发现URI中存在空格会跳到如下代码，这时ch=\0
【注：代码参考https://blog.werner.wiki/file-resolution-vulnerability-nginx/】
上面代码执行完后state='sw_check_uri’然后继续处理URI中的剩余部分，这说明了如果空格和零截断符相邻的话ngin就不会检测到零截断并放回错误了，这时一个逻辑漏洞，所以通过这种方式我们就可以在URI中开心的使用零截断的，这就是CVE-2013-4547。
利用方式
了解完上述漏洞后那么我们可以构造如下的URI触发漏洞
http://127.0.0.1/uploads/abc.jpg[20][00].php
nginx对上面的URI处理后将abc.jpg[20][00].php交给fastcgi处理，由于零截断fastcgi实际处理的文件为abc.jpg[00]，这个文件需要存在fastcgi才能正常处理。在Windows环境下由于命名文件时不允许文件后缀末尾存在空格所以自动将其修复为abc.jpg，这种情况下我们只需要上传一张包含代码的名字为abc.jpg的文件就可以利用漏洞了。但是在Linux情况下情况就不一样了。在Linux环境中由于允许文件后缀名最后存在空格所以我们需要确保我们传过去的文件名为abc.jpg[20]，我们可以在文件上传时使用Burpsuit在后缀名后加一个空格从而实现利用，如下图所示：
接下来我们就可以通过访问来执行文件里的代码了：
此漏洞可以还可以用于越权访问，但是我并没有复现成功所以就不做，具体参考漏洞详情。
条件限制
还是过不了security.limit_extensions这一关。