攻防世界 (Django @宽字节注入)Cat

这道题进来首先是让你输入域名,我输入了一个baidu.com发现无响应,输入127.0.0.1后发现执行了一个ping命令

我首先想到的就是命令注入,然而输入127.0.0.1||id 127.0.0.1&&id 127.0.0.1;ls;等后均显示无效的URL,很明显过滤了

不死心再拿Linux命令注入字典fuzzing一下OK,死心了

不能命令注入难道是SQL注入?

直接sql fuzzing一下现出来了一大段html代码,%df之前学过,是数据库使用gbk编码导致的宽字节注入,没学过的自己去了解一下

这html代码太多了,我找到个表单发现了很多东西

表单提交的地址我搜了一下发现还能访问但是不知道是干嘛的,ai搜了一下原来是个协作写代码的平台

带着上面的疑问不知道该怎么办,看了一一篇别人的wp才发现脑子瓦特了,直接全复制html代码找个在线运行html网站跑一下发现是Django的报错页面,这么看就方便多了,看数据大多是刚才那个表单提交的

文章地址:https://www.cnblogs.com/meng-han/p/16735284.html

往下翻找到META字段。在Django中,报错页面META字段通常用于提供有关错误页面的元数据信息。这些信息可以包括错误类型、原因、请求的URL、响应状态码等。这些信息可以帮助开发者更好地理解和调试错误。

这个content-type是在表单中上传文件时才用的,有点奇怪

POST方式说明这里数据提交的逻辑是:客户端将get数据提交给PHP,php使用post方式给Djanjo写的api,在报错页面中可以看到应该是/api/ping。Django对php传进的POST参数进行GBK编码,编码后执行ping命令。

这里太坑了,原题目上其实是有提示的,意思就是用@可以读取文件。

解题思路:@也能导致宽字节注入进而使Django报错再从报错页面中读取到我们想要的信息

网页ping的相对路径是api/ping,结合报错信息看出项目绝对地址是/opt/api

报错页面往下反找到数据库信息发现数据库的绝对路径

构建payload:@/opt/api/database.sqlite3

在HTML页面快捷搜索到flag为

WHCTF{yoooo_Such_A_G00D_@}

相关推荐

  1. 字节注入漏洞原理以及修复方法

    2024-07-11 06:14:05       47 阅读

最近更新

  1. docker php8.1+nginx base 镜像 dockerfile 配置

    2024-07-11 06:14:05       53 阅读
  2. Could not load dynamic library ‘cudart64_100.dll‘

    2024-07-11 06:14:05       55 阅读
  3. 在Django里面运行非项目文件

    2024-07-11 06:14:05       46 阅读
  4. Python语言-面向对象

    2024-07-11 06:14:05       56 阅读

热门阅读

  1. 3.上传图片(阿里云空间,oss验证)

    2024-07-11 06:14:05       20 阅读
  2. Flutter RSA公钥转PEM

    2024-07-11 06:14:05       21 阅读
  3. CentOS 系统监控项

    2024-07-11 06:14:05       19 阅读
  4. UCOS-III 与UCOS-III主要功能差异

    2024-07-11 06:14:05       14 阅读
  5. 用 adb 来模拟手机插上电源和拔掉电源的情形

    2024-07-11 06:14:05       19 阅读
  6. OpenResty程序如何连接开启了TLS的Redis?

    2024-07-11 06:14:05       22 阅读
  7. Jitsi Meet指定用户成为主持人

    2024-07-11 06:14:05       17 阅读
  8. Rust编程-编写自动化测试

    2024-07-11 06:14:05       24 阅读
  9. 开源大势所趋

    2024-07-11 06:14:05       21 阅读
  10. Sqlmap中文使用手册 - Target模块参数使用

    2024-07-11 06:14:05       23 阅读