XCTF-Web-Cat

打开题目，提示抓住那只猫

打开题目场景：

 提示输入你的域名，输入baidu.com，点击提交，并没有返回什么有用的信息。尝试输入127.0.0.1，返回信息如图：

 根据URL判断，输入的内容，赋值给url进行传入参数，并且执行的是ping的命令，测试命令注入，输入| ls 看返回信息，发现命令被过滤了，执行不成功。

进行fuzz测试，经过一轮fuzz测试，发现当url=%ff 的时候返回的信息异常。

直接在拼接url 让url等于%ff 

 返回的信息量很大，初步阅读，发现该信息应该是html编码，复制下来，保存为html文件，并打开查看

 貌似是通过一个API接口下的ping执行的上述过程，

 这里显示的请求信息，显示是以post方式提交的键值对。

CONTENT_TYPE是  multipart/form-data ，报错的许多地方都有Django

 猜测后端运行Django 框架，猜测是PHP通过curl将输入内容传输给Django。并且由于字符编码报错，post中包含的有输入的url，猜测是PHP向本机的Django发送的post请求中包含有输入的url，

 curl可以通过@使用文件路径来发送文件。

返回的报错信息很是丰富，还包含有database

database文件名：/opt/api/database.sqlite3

 总的来说，大致的报错流程是这样的，后台同时运行的php程序和python的django程序，而php程序用POST方式里的curl将GET方式获得的数据（我们输入的数据）传给django的对应的API，而传递过去之后，由于二者编码方式不同（类似于宽字节注入的逻辑），出现解码错误，即UnicodeEncodeError at /api/ping，然后因为后台django的debug没有关闭，所以会将错误信息直接返回给php程序进而给回显出来了。而存在的利用点是，curl用@来读取本地文件，我们可以使用@访问服务器后端的某些敏感文件。

构造payload：url=@/opt/api/database.sqlite3，访问数据库文件。

返回的信息仍然是html的源码。复制保存为html文件，打开查看

通过查找敏感字符串：ctf找到flag

 

 提交flag：WHCTF{yoooo_Such_A_G00D_@

这里直接提交AWHCTF{yoooo_Such_A_G00D_@}显示错误，通过多次尝试，得到flag是WHCTF{yoooo_Such_A_G00D_@}