标签：宽字节、PHP、Django、命令执行
解题过程
目录扫描没有发现任何可疑页面。
测试输入许多域名，均没有反应；输入ip地址得到回显。
猜测为命令执行，尝试使用管道符拼接命令。
测试：|、&、&&、||均报错。
说明系统对这些字符串都进行了过滤，fuzz测试查找未被过滤的字符。
发现@符号未过滤。在Fuzz过程中发现以下特殊数据，进行查看。
发现为Django的报错页面（html解码后转存）：
注意到
这里很诡异的将POST请求和FILE请求都合并在一起。
这里也很诡异的采用multipart/form-data方式传数据
需要猜测整个流程是怎么回事: 首先我们是通过一个php，get传参，然后php做中转post传get的参数至django搭的api上。而这个中转很有可能就是php-curl（结合multipart/form-data）。
结合前面没有过滤@符号，大佬提示可以使用curl的@+文件名做本地文件读取。
所以可以通过@index.php读取 index.php的代码，再交给django处理，因为index.php中存在如上不能编码为gbk的unicode编码字符，所以引发报错，同时在debug界面会输出所有post内容，即可爆出index.php文件内容。
获取php代码如下：
同理，可以读取其他文件，在django debug页面中，可以看到数据库的目录，直接读取即可发现flag。
