打开发现是一个探测主机存活的应用。
刚开始以为是命令注入，在想方设法绕过正则waf。
当输入宽字节字符时，会显示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文件内容。
同理，可以读取其他文件，在django debug页面中，可以看到数据库的目录是:
直接读取即可获得flag：
@/opt/api/database.sqlite3
WHCTF{yoooo_Such_A_G00D_@}
Comments | NOTHING