前言网上文章都是filter已经创建好了，然后关注创建过程中需要的关键参数。 组长的视频思路更偏向于filter的创建过程。这篇文章基于组长的思路编写。 pom.xml12345678910111213141516171819202122232425262728293031323334353637383940414243444546474849505152535455<?xml versio

前言之前博客都是通过GitHub实现图床的，但是国内访问图片的速度实在是不敢恭维；另外GitHub其实是不允许做图床的，当库超过1G以后会有人工审查，发现是图床可能会删库，甚至封帐号； 前期解决方案总体来看有几个解决方法 阿里云oss 腾讯云cos 七牛云 又拍云 七牛云有免费的额度，也可以使用不备案的域名，但是这样的话图片速度比Github还慢 又拍云需要网站备案，加入又拍云联盟才有免费额度，又

前言如果将Cobalt Strike部署在VPS上，长期使用VPS会被标记。另外，大家使用的一般是破解版，不能确保没有后门之类的东西。那可以将CS部署在虚拟机里，利用FRP转发上线。 比如现在有三个角色：公网服务器：41.24.10.40 CS服务器：192.168.73.98（虚拟机里） 靶机：192.168.112.130(可以访问公网) 实现步骤在公网服务器上frp绑定端

漏洞简介影响版本：Shiro <= 1.2.4 漏洞根本原因:固定key加密 Shiro特征：返回包中包含rememberMe=deleteMe字段。 Shiro框架提供了记住密码的功能（RememberMe），用户登录成功后会生成经过加密并编码的cookie。在服务端对rememberMe的cookie值，先base64解码然后AES解密再反序列化，就导致了反序列化RC

前言 CommonsBeanutils属于Apache Commons 工具集下的一个项目，它和Commons-Collections很像，也是对JAVA内置功能的加强，CC是对JAVA集合类的增强，CB是对JavaBean的加强。 环境搭建1234567<dependencies> <dependency> <groupId>c

前言之前在学习CC2的时候，CC2是CC3+CC4改写的。 从图中就可以看出来，CC6也能走到TemplatesImpl，然后直接加载字节码。 CC2+CC6改写，就是CC11 CC11利用链之前在Java反序列化CommonsCollections篇-CC3中提到利用ClassLoader#defineClass直接加载字节码的方式，在这里可以直接使用。 其实这样的话，直接使用CC2加载恶意字

前言CC7本质上也是对CC1的改写，走到了万恶之源LazyMap最终导致反序列化。 前置知识HashTable散列函数(哈希函数)中心思想： 不同参数返回不同哈希值 相同参数返回相同哈希值 比如我输入葡萄返回10，输入西瓜返回3，下次输入西瓜还是返回3 (传入不同参数时，哈希值一定都不相同么？事实上任何算法在理论上都不能保证。这种参数不同结果相同的情况学名叫做“Hash冲突(Hash碰撞)”

前言本质上也就是前面几条CC链改来改去，换了一个入口类。 环境搭建 JDK8u65 commons-collections 3.2.1 1234567<dependencies> <dependency> <groupId>commons-collections</groupId> <

前言CC3中我们了解到TemplatesImpl()调用Transformer()方法就可以代码执行。 CC2就在在这个基础上，结合CC4改写。CC2最大的优势就是不用Transformer 数组。 环境搭建 JDK8u65 CommonsCollections4 1234567<dependencies> <dependency> <group

前言前面几条链都是CommonsCollections3中产生的反序列化漏洞，后来Apache更新了大版本4.0，也产生了反序列化漏洞。 环境搭建 JDK8u65 CommonsCollections4 1234567<dependencies> <dependency> <groupId>org.apache.commons</gr