/opt/api/database.sqlite3 php的curl+@绝对路径文件名

文件名"/>

/opt/api/database.sqlite3 php的curl+@绝对路径文件名

学习知识点
1.php的curl+@绝对路径文件名 当 CURLOPT_SAFE_UPLOAD 为 true 时，如果在请求前面加上@的话phpcurl组件是会把后面的当作绝对路径请求，来读取文件。当且仅当文件中存在中文字符的时候，Django 才会报错导致获取文件内容CURLOPT_SAFE_UPLOAD选项配置不当结合其他情况可造成任意文件读取。详情参见PHP libcurl 安全之 CURLOPT_SAFE_UPLOAD
2./opt/api/database.sqlite3

3.url编码采用16进制范围为0-127 ，%79为最大127
4.命令执行

将道理，看到表单避免不了的要输入试一试
先输入例子，loil.clud，没有反应
尝试127.0.0.1，出现变化！

欸嘿嘿，似乎有东西，那我们来尝试下系统命令执行规则来输入命令：

command1 & command2 ：先执行command2后执行command1
command1 && command2 ：先执行command1后执行command2
command1 | command2 ：只执行command2
command1 || command2 ：command1执行失败，再执行command2(若command1执行成功，就不再执行command2)

所以我们开始尝试输入127.0.0.1 & ls
127.0.0.1||ls
127.0.0.1&&ls
127.0.0.1|ls
尝试一波 &，| 等管道符号和ls dir等命令均报错了

我们发现他的url处存在编码，url编码我们进行尝试；细看url可以直接发现 空格直接被url编码为了+，考虑报错回显，输入url=%80,出现报错信息

随便输入不同的url编码值，编码大佬的一篇博文中有提供：

在URL的传参处?url=这里，我们传递个%79发现传递之后变成了?url=w，看来是可以传递url编码，系统会接受并进行解析，于是我们传递%80会出现报错，url编码使用的是16进制，80也就是128，ASCII码是从0-127，所以这个时候会报错。

看别人的WP ：

1.然后查询之后在settings里面找到了basedata：

答：django项目下一般有个settings.py文件是设置网站数据库路径且django项目生成时settings.py会存放在以项目目录下再以项目名称命名的文件夹下面，查看settings.py

2.然后找到了重要路径：/opt/api/database.sqlite3

答：复制大佬的说法：
因为后台同时运行的php程序和python的dijango程序（看大佬 WP，大佬猜的），通过暴露给我们的php程序获得上传的数据，而php程序用POST方式里的curl将GET方式获得的数据传给django的对应的API，而传递过去之后，由于二者编码方式不同（类似于宽字节注入的逻辑），出现解码错误，即UnicodeEncodeError at /api/ping，然后又因为后台dijango的debug没有关闭，所以会将错误信息直接返回给php程序进而给回显出来了。漏洞的逻辑大概就是这样，而利用点就是，curl用@来读取本地文件，在报错文本里，查找关键字，如database、ctf、flag、cat、database、XCTF等关键词

3 php的curl+@绝对路径文件名

输入@/opt/api/database.sqlite3提取信息 @+绝对路径

这样直接看费眼力，将报错的文本放在浏览器里加载来看的话，如下：

所以根据Django的目录，我们使用@进行文件传递，对文件进行读取之后还会把内容传给url参数，如果像上面一样有超出解析范围的编码的时候就会得到错误信息。

我们的目标首先是数据库文件，看从错误信息中能不能拿到flag，可以从配置文件settings.py的报错中看看有没有database的相关信息

继续查询url=@/opt/api/database.sqlite3

第三步：答案
继续搜索关键词找到类似于flag的形式

经过数次尝试最终锁定答案。
至此最终flag为：WHCTF{yoooo_Such_A_G00D_@}