<?xml version="1.0" encoding="utf-8" ?><rss version="2.0"><channel><title><![CDATA[Go_change的博客]]></title><description><![CDATA[]]></description><link>https://blog.youkuaiyun.com/Go_change</link><language>zh-cn</language><generator>https://blog.youkuaiyun.com/</generator><copyright><![CDATA[Copyright &copy; Go_change]]></copyright><item><title><![CDATA[JNDI 高版本绕过：本地 ObjectFactory 利用链]]></title><link>https://blog.youkuaiyun.com/Go_change/article/details/163481669</link><guid>https://blog.youkuaiyun.com/Go_change/article/details/163481669</guid><author>Go_change</author><pubDate>Sun, 09 Aug 2026 21:09:46 +0800</pubDate><description><![CDATA[摘要 本文深入分析了高版本JDK中JNDI注入的本地ObjectFactory绕过技术。核心利用Tomcat的BeanFactory配合目标类（如ELProcessor、GroovyShell）的forceString机制，将属性设置转换为代码执行。文章指出，由于本地ObjectFactory优先于远程加载，且不依赖反序列化，使得8u191+版本的限制被绕过。]]></description><category></category></item><item><title><![CDATA[JNDI 反序列化路径：JEP 290 过滤与绕过]]></title><link>https://blog.youkuaiyun.com/Go_change/article/details/163481650</link><guid>https://blog.youkuaiyun.com/Go_change/article/details/163481650</guid><author>Go_change</author><pubDate>Sun, 09 Aug 2026 21:09:26 +0800</pubDate><description><![CDATA[本文分析了JEP 290对JNDI反序列化攻击的影响。]]></description><category></category></item><item><title><![CDATA[JNDI 注入详解：四种协议的选择与绕过]]></title><link>https://blog.youkuaiyun.com/Go_change/article/details/163481528</link><guid>https://blog.youkuaiyun.com/Go_change/article/details/163481528</guid><author>Go_change</author><pubDate>Sat, 08 Aug 2026 01:33:41 +0800</pubDate><description><![CDATA[文章摘要 本文深入分析了JNDI注入攻击中四种协议（RMI、LDAP、IIOP、DNS）的工作原理、选择条件和绕过方式。JNDI注入的核心是利用InitialContext.lookup()方法加载攻击者控制的远程对象，通过不同协议实现远程类加载或反序列化攻击。文章详细比较了各协议的触发机制（如RMI的Reference远程加载、LDAP的entry解析）和JDK版本限制（如8u121禁用RMI远程加载、8u191禁用LDAP远程加载）。针对高版本JDK，还探讨了序列化对象利用本地gadget等绕过技术。]]></description><category></category></item><item><title><![CDATA[JNDI Reference 类加载完整机制]]></title><link>https://blog.youkuaiyun.com/Go_change/article/details/163481631</link><guid>https://blog.youkuaiyun.com/Go_change/article/details/163481631</guid><author>Go_change</author><pubDate>Sat, 08 Aug 2026 01:33:10 +0800</pubDate><description><![CDATA[这篇文章深入分析了JNDI Reference的类加载机制，主要包含以下要点： Reference结构：包含className、classFactory、classFactoryLocation和addrs四个关键字段，攻击者可控制这些字段。 getObjectInstance流程：先找factory类，加载后调用其getObjectInstance方法；若无factory则尝试直接实例化className。]]></description><category></category></item><item><title><![CDATA[Fastjson autoType 防御演进：从 checkAutoType 到 safeMode]]></title><link>https://blog.youkuaiyun.com/Go_change/article/details/163480850</link><guid>https://blog.youkuaiyun.com/Go_change/article/details/163480850</guid><author>Go_change</author><pubDate>Thu, 06 Aug 2026 04:15:00 +0800</pubDate><description><![CDATA[本文梳理了Fastjson从1.2.25到1.2.68版本中autoType防御机制的演进历程。1.2.24版本因autoType完全开放导致严重漏洞后，官方通过黑名单、哈希黑名单、修复缓存投毒等方案层层防御，但始终未能彻底解决问题。1.2.68版本引入safeMode作为终极解决方案，直接禁用autoType功能，从根本上阻断了攻击面。文章揭示了黑名单机制的固有缺陷，指出安全设计应遵循"默认禁止"原则，并建议用户开启safeMode或升级至更安全的fastjson2版本。整个演进过程体现了从被动防御到主动]]></description><category></category></item><item><title><![CDATA[Fastjson 1.2.80 autoType Throwable 异常类绕过分析]]></title><link>https://blog.youkuaiyun.com/Go_change/article/details/163480832</link><guid>https://blog.youkuaiyun.com/Go_change/article/details/163480832</guid><author>Go_change</author><pubDate>Thu, 06 Aug 2026 04:14:29 +0800</pubDate><description><![CDATA[摘要： Fastjson 1.2.80版本存在autoType黑名单绕过漏洞，攻击者可通过Throwable异常类结合expectClass机制，在未开启safeMode时实现反序列化RCE。该漏洞利用fastjson对Throwable类反序列化的特殊处理，通过构造嵌套@type的JSON数据，以expectClass=Throwable.class绕过黑名单检查，加载任意Throwable子类。虽然实际利用需要依赖特定Throwable子类的gadget，但该绕过方式暴露了expectClass校验不足]]></description><category></category></item><item><title><![CDATA[Fastjson 1.2.47 autoType 缓存绕过分析]]></title><link>https://blog.youkuaiyun.com/Go_change/article/details/163480818</link><guid>https://blog.youkuaiyun.com/Go_change/article/details/163480818</guid><author>Go_change</author><pubDate>Wed, 05 Aug 2026 19:27:06 +0800</pubDate><description><![CDATA[漏洞组件影响版本漏洞类型：autoType 黑名单绕过导致反序列化 RCECVE：无（官方未分配 CVE；fastjson 1.2.25 后的绕过漏洞均未申请 CVE）修复版本：1.2.48特点无需开启 autoType（默认配置即可利用），比 1.2.24 时代的“需开 autoType”更隐蔽根因先查缓存、后查黑名单；而MiscCodec处理时会以cache=true把任意类名塞进缓存。]]></description><category></category></item><item><title><![CDATA[Fastjson 1.2.41-1.2.43 autoType 黑名单前后缀绕过分析]]></title><link>https://blog.youkuaiyun.com/Go_change/article/details/163480785</link><guid>https://blog.youkuaiyun.com/Go_change/article/details/163480785</guid><author>Go_change</author><pubDate>Wed, 05 Aug 2026 19:26:37 +0800</pubDate><description><![CDATA[摘要：本文分析了Fastjson 1.2.41-1.2.43版本中autoType黑名单的前后缀绕过漏洞。核心问题在于校验逻辑与加载逻辑不一致：checkAutoType使用原始类名匹配黑名单，而TypeUtils.loadClass会剥离JNI签名前后缀（如L和;）再加载类。攻击者通过添加L前缀或双写LL绕过黑名单检测（如Lcom.sun.rowset.JdbcRowSetImpl;），导致危险类被加载并触发RCE。]]></description><category></category></item><item><title><![CDATA[Fastjson 1.2.47 autoType 缓存绕过分析（CVE-2017-18349）]]></title><link>https://blog.youkuaiyun.com/Go_change/article/details/163478577</link><guid>https://blog.youkuaiyun.com/Go_change/article/details/163478577</guid><author>Go_change</author><pubDate>Tue, 04 Aug 2026 17:56:31 +0800</pubDate><description><![CDATA[checkAutoType 的黑名单逻辑、MiscCodec 处理 java.lang.Class 的副作用、TypeUtils.loadClass 的缓存机制，一行行拆开看，搞清楚“写入缓存”和“命中缓存”到底发生在代码的哪一步。]]></description><category></category></item><item><title><![CDATA[Fastjson 1.2.24 autoType 反序列化漏洞分析（CVE-2017-18349）]]></title><link>https://blog.youkuaiyun.com/Go_change/article/details/163478389</link><guid>https://blog.youkuaiyun.com/Go_change/article/details/163478389</guid><author>Go_change</author><pubDate>Tue, 04 Aug 2026 17:26:28 +0800</pubDate><description><![CDATA[摘要 本文深入分析了Fastjson 1.2.24版本（CVE-2017-18349）的autoType反序列化漏洞机制。该漏洞源于未对@type指定的类名进行过滤，导致攻击者可实例化任意类并触发其setter/getter方法。文章通过源码解析展示了autoType的三步流程：识别@type→加载类→委托反序列化器，重点剖析了TypeUtils.loadClass直接加载任意类和JavaBeanDeserializer自动调用setter的危险机制。]]></description><category></category></item><item><title><![CDATA[Shiro 路径绕过四连：1957 -＞ 11989 -＞ 13933 -＞ 17523]]></title><link>https://blog.youkuaiyun.com/Go_change/article/details/163416536</link><guid>https://blog.youkuaiyun.com/Go_change/article/details/163416536</guid><author>Go_change</author><pubDate>Mon, 03 Aug 2026 09:52:38 +0800</pubDate><description><![CDATA[Shiro 路径绕过演进链分析 本文分析了Apache Shiro权限绕过的经典演进链，从CVE-2020-1957到CVE-2021-17523，揭示了同一方法WebUtils.getPathWithinApplication的反复绕过过程。文章包含实测复现和源码分析： CVE-2020-1957（1.5.1版本）： 根因：getRequestURI()获取原始URI后，Shiro自行进行;截断+解码+归一化，与容器处理不一致 绕过方式]]></description><category></category></item><item><title><![CDATA[Shiro 权限绕过系列概述]]></title><link>https://blog.youkuaiyun.com/Go_change/article/details/163416480</link><guid>https://blog.youkuaiyun.com/Go_change/article/details/163416480</guid><author>Go_change</author><pubDate>Mon, 03 Aug 2026 09:51:45 +0800</pubDate><description><![CDATA[摘要：Shiro权限绕过漏洞系列分析 Shiro权限绕过漏洞与反序列化RCE不同，攻击者通过路径解析差异使Shiro误判请求无需鉴权。核心问题在于Shiro的路径处理逻辑（WebUtils.getPathWithinApplication）与容器/Spring不一致，导致受保护接口被绕过。本系列分析5个CVE，包括CVE-2020-1957（;截断+路径归一化差异）和CVE-2022-32532（正则匹配缺陷）的可复现案例，其余通过源码分析展示演进过程]]></description><category></category></item><item><title><![CDATA[Shiro-721 反序列化复现（CVE-2019-12422）]]></title><link>https://blog.youkuaiyun.com/Go_change/article/details/163412135</link><guid>https://blog.youkuaiyun.com/Go_change/article/details/163412135</guid><author>Go_change</author><pubDate>Sun, 02 Aug 2026 11:08:04 +0800</pubDate><description><![CDATA[Shiro-721 (CVE-2019-12422) 漏洞复现摘要 Apache Shiro 1.2.5-1.4.1版本中，RememberMe功能采用AES-CBC加密模式，存在Padding Oracle漏洞。攻击者可通过合法Cookie，利用Padding Oracle攻击（无需密钥）构造恶意反序列化payload。与Shiro-550不同，721漏洞要求先获取合法账号Cookie，攻击需数十万次请求。复现过程包括：搭建靶场环境（Shiro 1.2.6+Oracle端点）、验证单块算法、构造完整CB1]]></description><category></category></item><item><title><![CDATA[Shiro-550 反序列化复现（CVE-2016-4437）]]></title><link>https://blog.youkuaiyun.com/Go_change/article/details/163387386</link><guid>https://blog.youkuaiyun.com/Go_change/article/details/163387386</guid><author>Go_change</author><pubDate>Sun, 02 Aug 2026 11:02:47 +0800</pubDate><description><![CDATA[Shiro-550反序列化漏洞复现（CVE-2016-4437） 漏洞概述：Apache Shiro ≤1.2.4版本中存在硬编码AES密钥漏洞（默认密钥kPH+bIxk5D2deZiIxcaaaA==），攻击者可利用RememberMe功能构造恶意序列化数据，解密后触发Java反序列化实现RCE。 攻击原理： RememberMe机制对用户身份进行序列化→AES加密→Base64编码存储为Cookie 默认密钥泄露导致攻击者可伪造任意加密数据 服务端解密后调用readObject触发反序列化漏洞 利用链选]]></description><category></category></item><item><title><![CDATA[Apache Shiro 基础与 RememberMe 机制]]></title><link>https://blog.youkuaiyun.com/Go_change/article/details/163386990</link><guid>https://blog.youkuaiyun.com/Go_change/article/details/163386990</guid><author>Go_change</author><pubDate>Sat, 01 Aug 2026 10:28:25 +0800</pubDate><description><![CDATA[摘要 Apache Shiro是一个Java安全框架，提供认证、授权、加密和会话管理功能。其"记住我"（RememberMe）机制存在两个经典漏洞：Shiro-550（CVE-2016-4437）因硬编码AES密钥导致反序列化漏洞，攻击者可构造恶意Cookie触发RCE；Shiro-721（CVE-2019-12422）则利用AES-CBC的Padding Oracle漏洞篡改合法Cookie实现反序列化攻击。此外，Shiro与Spring对URL路径解析的差异导致权限绕过漏洞。]]></description><category></category></item><item><title><![CDATA[Java RMI 反序列化漏洞_CVE-2017-3241分析]]></title><link>https://blog.youkuaiyun.com/Go_change/article/details/163386510</link><guid>https://blog.youkuaiyun.com/Go_change/article/details/163386510</guid><author>Go_change</author><pubDate>Sat, 01 Aug 2026 10:24:19 +0800</pubDate><description><![CDATA[本文深入剖析了 Java RMI（远程方法调用）作为反序列化攻击载体的机制，通过原理分析与环境对比（JDK 8u65 vs 8u181）系统性地阐述了 RMI 反序列化漏洞的攻防演进。]]></description><category></category></item><item><title><![CDATA[java反序列化之CC6 利用链分析：hashCode 触发链]]></title><link>https://blog.youkuaiyun.com/Go_change/article/details/163297941</link><guid>https://blog.youkuaiyun.com/Go_change/article/details/163297941</guid><author>Go_change</author><pubDate>Fri, 31 Jul 2026 09:32:45 +0800</pubDate><description><![CDATA[CC6 反序列化链分析：通用性最强的实战首选 CC6 是 CommonsCollections 反序列化链中最通用的攻击方式： 特点：不依赖特定 JDK 版本]]></description><category></category></item><item><title><![CDATA[java反序列化之CC1-CC6 六条链总结]]></title><link>https://blog.youkuaiyun.com/Go_change/article/details/163298030</link><guid>https://blog.youkuaiyun.com/Go_change/article/details/163298030</guid><author>Go_change</author><pubDate>Fri, 31 Jul 2026 09:31:57 +0800</pubDate><description><![CDATA[文章摘要 本文系统总结了Java反序列化漏洞中Commons Collections(CC)1-CC6六条利用链，通过两个核心维度（入口线和执行体线）构建了2×3矩阵模型，清晰展示了六条链的内在关联。文章分析了各链的依赖条件与限制（如JDK版本、CC库版本），梳理出两条演进主线]]></description><category></category></item><item><title><![CDATA[java反序列化之CC5 利用链分析：toString 触发链]]></title><link>https://blog.youkuaiyun.com/Go_change/article/details/163297799</link><guid>https://blog.youkuaiyun.com/Go_change/article/details/163297799</guid><author>Go_change</author><pubDate>Thu, 30 Jul 2026 09:29:52 +0800</pubDate><description><![CDATA[摘要 CC5 利用链通过 BadAttributeValueExpException 作为入口，摆脱了对 AnnotationInvocationHandler 和 CC4 库的依赖。]]></description><category></category></item><item><title><![CDATA[java反序列化之CC4 利用链分析]]></title><link>https://blog.youkuaiyun.com/Go_change/article/details/163297436</link><guid>https://blog.youkuaiyun.com/Go_change/article/details/163297436</guid><author>Go_change</author><pubDate>Thu, 30 Jul 2026 09:28:35 +0800</pubDate><description><![CDATA[摘要：CC4反序列化漏洞分析 CC4是Commons Collections反序列化利用链的优化版本，结合了CC2和CC3的优点： 入口采用CC2的PriorityQueue+TransformingComparator，不依赖AnnotationInvocationHandler，突破JDK 8u71限制 执行体使用CC3的InstantiateTransformer+TrAXFilter组合，规避InvokerTransformer黑名单检测 完整利用链通过PriorityQueue反序列化触发比较操作]]></description><category></category></item></channel></rss>