1.Shiro的简介
2.反序列化漏洞原理详解
3.Shiro源码分析---FilterChain创建过程
4.Shiro的Subject创建的内部流程
5.求shop++的源代码
6.shiro反序列化漏洞原理分析以及漏洞复现（Shiro-550/Shiro-721漏洞复现）

Shiro的简介

       在之前的学习中，我未记录Shiro的相关笔记，现在决定补全这部分内容。虽然之前写过一篇基础介绍，但感觉总结不够全面。

       Shiro作为当前热门的星王合击版本源码安全框架，其实质是权限管理工具，主要负责用户对系统资源的访问控制。例如，访问路径"/Admin/UserList"如果没有权限管理，任何人都能访问，这就构成未授权访问。

       Shiro的核心架构可以参考官网提供的架构图，主要包括Subject（代表用户或应用）、SecurityManager（负责认证和授权的中介）、Authenticator（身份认证）、Authorizer（授权决策）、Realm（数据源，获取用户信息）、SessionManager（会话管理）和SessionDAO（会话存储）等组件。

       认证过程中，用户通过身份信息（Principal，如用户名）和凭据信息（Credential，如密码）进行登录。Shiro将这些信息封装成Token，通过安全管理器，调用Authenticator进行身份验证。Realm从数据库获取用户信息进行比对，验证通过后进入授权环节。

       配置方面，shiro.ini文件定义了初始的用户名和密码，与其他框架集成时会用到ShiroConfig。测试代码演示了认证流程的各个环节。

       Shiro的认证源码分析深入到了各个方法，包括认证、授权、以及如何从Token中提取用户名和密码进行比对。在Springboot整合Shiro时，涉及创建ShiroFilter、码垛机器源码安全管理器、自定义Realm以及配置权限访问规则。

       绕过机制方面，Springboot版本和Shiro版本的搭配会影响绕过漏洞的复现。在Shiro配置中，绕过行为通过路径匹配进行控制。在绕过漏洞的分析中，可以看到Spring和Shiro在处理请求路径时的差异，导致权限控制的失效。

       关于更多Shiro绕过漏洞的详细内容，可以参考nice0e3师傅的文章，链接在这里：[tttang.com/archive/...]

反序列化漏洞原理详解

       Apache Shiro 是一款强大且易用的 Java 安全框架，专用于执行身份验证、授权、密码和会话管理。在本文中，我们将深入剖析 Shiro 的认证和授权流程，特别关注 rememberme 字段如何引发反序列化漏洞。

       首先，让我们探讨 Shiro 的认证过程。当用户尝试登录时，Shiro 通过验证用户名和密码来确认用户身份。这一过程在源码中清晰可见，主要通过 UsernamePasswordToken 对象和 Subject.login()方法实现。Subject 对象是 Shiro 中的核心概念，负责存储用户信息。在认证过程中，Shiro 通过调用 Realm 的 doGetAuthenticationInfo()方法来验证用户信息。该方法从数据库查询用户信息并进行比对，最终确认用户身份。

       接下来，我们关注 Shiro 的授权机制。授权过程围绕着生成的 Subject 对象进行，确保用户具备访问特定资源所需的权限。在 Shiro 的配置文件中，权限规则被明确指定。通过调用 doGetAuthorizationInfo()方法，Shiro 能够为用户授权。python源码面试这一过程中，Shiro 比较用户权限与资源所需权限，以确定用户是否具有访问权限。

       然而，Rememberme 字段是引发反序列化漏洞的关键。在登录时选择 Rememberme 选项，Cookie 中会存储序列化数据，允许用户在无需重新登录的情况下访问特定资源。Shiro 通过 DefaultSecurityManager 类生成 rememberme，并将其存储在浏览器中。当用户关闭浏览器时，与服务端的会话通常会结束。但若选择 Rememberme，即使关闭浏览器，数据依然存储，用户下次访问指定资源时，浏览器会携带 rememberme，实现无须登录的访问。

       反序列化漏洞的根源在于 rememberme 字段中存储的序列化数据。Shiro 在生成 rememberme 时，会将用户信息序列化为 PrincipalCollection 对象，并使用 AES 加密。密钥被硬编码在代码中。通过解密和反序列化这一序列化数据，攻击者可以获取用户的敏感信息，从而触发反序列化漏洞。

       总结，Apache Shiro 是一款功能强大的安全框架，但在配置和使用中需谨慎处理 Rememberme 字段，以避免潜在的安全风险。理解 Shiro 的认证和授权流程，以及反序列化漏洞的机制，有助于提升系统安全性。

Shiro源码分析---FilterChain创建过程

       在Shiro框架中，无论是进行认证还是权限控制，都依赖于过滤器的配置与应用。在实际开发中，可能需要配置多个过滤器，大盘波浪源码但每个请求所经过的过滤器组合却因请求不同而异。因此，理解一个请求会通过哪些过滤器，对于熟练使用Shiro至关重要。本文将详细解析请求通过的过滤器创建过程。

       Shiro框架通过`org.apache.shiro.web.filter.mgt.FilterChainResolver`接口定义了如何确定一个请求应经过哪些过滤器。接口中的唯一方法`getChain`负责查找并组装一个过滤器链（FilterChain），该链包含了请求处理过程中所应用的所有过滤器。`FilterChain`是一个熟知的概念，尤其是对于Servlet开发人员来说，它在日常工作中常见。而`FilterChainResolver`仅是一个接口，Shiro提供了默认实现类`org.apache.shiro.web.filter.mgt.PathMatchingFilterChainResolver`，该实现类利用请求路径来匹配相应的过滤器。

       在深入理解PathMatchingFilterChainResolver的源码前，先来看看FilterChainManager是如何管理和创建FilterChain的。Shiro提供了一个默认的FilterChainManager实现类`org.apache.shiro.web.filter.mgt.DefaultFilterChainManager`。其关键方法`createChain`在系统启动时被调用，用于创建各个FilterChain。以配置示例`/static/**、/formfilterlogin，/role`为例，`chainName`与`chainDefinition`分别代表了需要管理的FilterChain名称与定义。

       了解了FilterChainManager的创建与管理机制后，接下来关注FilterChainResolver如何确定请求所需过滤器链。在`DefaultFilterChainManager.proxy`方法中，`NamedFilterList`的实现类`org.apache.shiro.web.filter.mgt.SimpleNamedFilterList`被调用，此步骤是确定过滤器链的关键环节。

       至此，Shiro框架中FilterChain创建过程已全面解析完成。如有任何错误或需要进一步讨论的问题，欢迎指正。感谢阅读，期待更多的技术交流。

Shiro的Subject创建的内部流程

       在使用Shiro框架进行编程时，我们通常会调用Subject对象的login()方法来实现认证过程。然而，当我们查看Subject接口的eSIM终端源码定义时，会发现login()方法实际上只是声明了功能，而没有具体的实现。那么，当我们在代码中调用Subject.login()时，实际执行的是哪个类的功能呢？接下来，我们将探索Shiro Subject创建的内部流程。

       首先，我们查看SubjectUtils类中的getSubject方法，这是用于从当前线程中获取或创建Subject对象的入口。通过调用Subject内部的Builder设计模式，我们能够创建一个Subject实例。然后，我们将深入Subject内部，了解其内部结构。Subject是一个接口，而Builder类是其内部的静态类，用于构建Subject实例。

       在Subject的内部，我们可以看到Builder类与SecurityManager之间的关系。最终，SecurityManager负责创建Subject实例的工作。然而，SecurityManager接口自身也是一个接口，这意味着它只是声明了一个抽象的创建Subject的逻辑，而实际的实现取决于具体的SecurityManager类。

       如果使用的是默认的构造方法Build()，那么Subject实例的创建逻辑将依赖于SecurityUtils.getSecurityManager()方法。通过进一步分析源代码，我们可以得知SecurityManager的具体实例类型是由Shiro配置文件（如shiro.ini）中的配置决定的。如果没有自定义配置，那么Shiro将使用默认的DefaultSecurityManager类。

       SecurityManager的继承结构复杂且功能多样，其最终的实现细节在DefaultSecurityManager类中。我们可以通过分析DefaultSecurityManager.createSubject(SubjectContext subjectContext)方法的源代码，来了解Subject实例是如何被创建的。在实现该方法的过程中，DefaultSecurityManager会调用其内部的SubjectFactory类来创建Subject实例。

       在DefaultSecurityManager的构造方法中，我们可以看到SubjectFactory的类型是DefaultSubjectFactory。接下来，我们继续追踪到DefaultSecurityManager的doCreateSubject()方法，以及其中的createSubject()方法所在的DelegatingSubject类。最终，Subject实例被构建为DelegatingSubject，其中Delegate表示委托的概念。

       至此，我们已经清晰地了解了Subject实例的创建过程。现在，让我们继续探索Subject.login()方法的实现。在实际执行中，Subject.login()方法最终会调用DelegatingSubject.login()方法来完成认证过程。

       综上所述，Shiro的Subject创建内部流程涉及从当前线程获取或创建Subject，通过Builder设计模式构建实例，由SecurityManager实现创建逻辑，最终在DefaultSecurityManager类中完成Subject实例的创建，以及通过DelegatingSubject类实现认证功能。这一系列过程确保了Shiro在认证和授权方面的高效和灵活。

求shop++的源代码

       主要库

       spring-aop-4.0.9.RELEASE

       spring-beans-4.0.9.RELEASE

       spring-context-4.0.9.RELEASE

       spring-context-support-4.0.9.RELEASE

       spring-core-4.0.9.RELEASE

       spring-expression-4.0.9.RELEASE

       spring-jdbc-4.0.9.RELEASE

       spring-orm-4.0.9.RELEASE

       spring-test-4.0.9.RELEASE

       spring-tx-4.0.9.RELEASE

       spring-web-4.0.9.RELEASE

       spring-webmvc-4.0.9.RELEASE

       hibernate-core-4.3.9.Final

       hibernate-jpa-2.1-api-1.0.0.Final

       hibernate-entitymanager-4.3.9.Final

       hibernate-validator-5.1.3.Final

       hibernate-search-orm-4.5.3.Final

       lucene-core-3.6.2

       freemarker-2.3.

       ehcache-core-2.6.

       ehcache-web-2.0.4

       shiro-core-1.2.3

       shiro-web-1.2.3

       c3p0-0.9.2.1

       commons-lang-2.6

       commons-beanutils-1.9.2

       commons-collections-3.2.1

       commons-io-2.4

       commons-net-3.3

       commons-fileupload-1.3.1

       commons-codec-1.

       commons-email-1.3.3

       commons-compress-1.9

       junit-4.

       httpclient-4.3.5

       httpcore-4.3.2

       slf4j-api-1.7.7

       jcl-over-slf4j-1.7.7

       logback-core-1.1.2

       logback-classic-1.1.2

       dom4j-1.6.1

       jackson-core-2.4.3

       jackson-databind-2.4.3

       jackson-annotations-2.4.3

       IKAnalyzer_u6

shiro反序列化漏洞原理分析以及漏洞复现（Shiro-/Shiro-漏洞复现）

       shiro-反序列化漏洞（CVE--）漏洞简介

       shiro-主要是由shiro的rememberMe内容反序列化导致的命令执行漏洞，造成的原因是默认加密密钥是硬编码在shiro源码中，任何有权访问源代码的人都可以知道默认加密密钥。于是攻击者可以创建一个恶意对象，对其进行序列化、编码，然后将其作为cookie的rememberMe字段内容发送，Shiro 将对其解码和反序列化，导致服务器运行一些恶意代码。

       特征：cookie中含有rememberMe字段

       修复建议：

       更新shiro到1.2.4以上的版本。

       不使用默认的加密密钥，改为随机生成密钥。

       漏洞原理

       一、Shiro简介

       Apache Shiro 是一个强大易用的 Java 安全框架，提供了认证、授权、加密和会话管理等功能，对于任何一个应用程序，Shiro 都可以提供全面的安全管理服务。

       在ApacheShiro<=1.2.4版本中AES加密时采用的key是硬编码在代码中的，于是我们就可以构造Remembe Me的值，然后让其反序列化执行。

       二、Shiro服务器识别身份加解密处理的流程

       （1）加密

       1.用户使用账号密码进行登录，并勾选"Remember Me"。

       2、Shiro验证用户登录信息，通过后，查看用户是否勾选了”Remember Me“。

       3、若勾选，则将用户身份序列化，并将序列化后的内容进行AES加密，再使用base编码。

       4、最后将处理好的内容放于cookie中的rememberMe字段。

       （2）解密

       1、当服务端收到来自未经身份验证的用户的请求时，会在客户端发送请求中的cookie中获取rememberMe字段内容。

       2、将获取到的rememberMe字段进行base解码，再使用AES解密。

       3、最后将解密的内容进行反序列化，获取到用户身份。

       三、Key

       AES加密的密钥Key被硬编码在代码里

       于是可得到Payload的构造流程：

       恶意命令-->序列化-->AES加密-->base编码-->发送Cookie

       Shiro-反序列化漏洞（CVE--）Shiro和Shiro的区别是什么

       Shiro只需要通过碰撞key，爆破出来密钥，就可以进行利用 Shiro的ase加密的key一般情况下猜不到，是系统随机生成的，并且当存在有效的用户信息时才会进入下一阶段的流程所以我们需要使用登录后的rememberMe Cookie，才可以进行下一步攻击。

       漏洞指纹

       URL中含有Shiro字段

       cookie中含有rememberMe字段

       返回包中含有rememberMe

       漏洞介绍

       在Shiro中，Shiro通过AES--CBC对cookie中的rememberMe字段进行加密，所以用户可以通过PaddingOracle加密生成的攻击代码来构造恶意的rememberMe字段，进行反序列化攻击，需要执行的命令越复杂，生成payload需要的时间就越长。

       漏洞原理

       由于Apache Shiro cookie中通过 AES--CBC 模式加密的rememberMe字段存在问题，用户可通过Padding Oracle 加密生成的攻击代码来构造恶意的rememberMe字段，用有效的RememberMe cookie作为Padding Oracle Attack 的前缀，然后制作精心制作的RememberMe来执行Java反序列化攻击

       攻击流程

       登录网站，并从cookie中获取RememberMe。使用RememberMe cookie作为Padding Oracle Attack的前缀。加密syserial的序列化有效负载，以通过Padding Oracle Attack制作精心制作的RememberMe。请求带有新的RememberMe cookie的网站，以执行反序列化攻击。攻击者无需知道RememberMe加密的密码密钥。

       加密方式：AES--CBC 属于AES加密算法的CBC模式，使用位数据块为一组进行加密解密，即字节明文，对应字节密文，，明文加密时，如果数据不够字节，则会将数据补全剩余字节

       若最后剩余的明文不够字节，需要进行填充，通常采用PKCS7进行填充。比如最后缺3个字节，则填充3个字节的0x;若最后缺个字节，则填充个字节的0;

       若明文正好是个字节的整数倍，最后要再加入一个字节0x的组再进行加密

       Padding Oracle Attack原理 Padding Oracle攻击可以在没有密钥的情况下加密或解密密文

       Shiro Padding Oracle Attack（Shiro填充Oracle攻击）是一种针对Apache Shiro身份验证框架的安全漏洞攻击。Apache Shiro是Java应用程序中广泛使用的身份验证和授权框架，用于管理用户会话、权限验证等功能。

       Padding Oracle Attack（填充Oracle攻击）是一种针对加密算法使用填充的安全漏洞攻击。在加密通信中，填充用于将明文数据扩展到加密算法块大小的倍数。在此攻击中，攻击者利用填充的响应信息来推断出加密算法中的秘密信息。

       Shiro Padding Oracle Attack利用了Shiro框架中的身份验证过程中的一个漏洞，该漏洞允许攻击者通过填充信息的不同响应时间来确定身份验证过程中的错误。通过不断尝试不同的填充方式，攻击者可以逐步推断出加密秘钥，并最终获取访问权限。

       这种攻击利用了填充错误的身份验证响应来获取关于秘密信息的信息泄漏，然后根据这些信息进行进一步的攻击。为了防止Shiro Padding Oracle Attack，建议及时更新Apache Shiro版本，确保已修复该漏洞，并采取其他安全措施，如使用安全的加密算法和密钥管理策略。

       漏洞复现：CVE--

       环境：kali linux

       靶场使用：vulhub/shiro/CVE--

       访问地址：

       抓包分析一下：

       在返回包当中发现存在rememberMe=deleteMe 字样，可以大概确定有配置shiro，可以进行下一步。因为shiro本身功能就是一个身份验证管理，所以一般都在登录口可以看到。

       UI一键利用工具

       使用工具再进行检测确认:

       输入目标的url地址，根据关键字进行爆破秘钥

       接下来爆破利用链以及回显方式：

       接下来可进行命令执行：

       反弹shell：

       可使用工具进行检测：

       检测完成后可进行命令执行，反弹shell等操作：

       使用工具进行简单的反弹：

       设置监听端口

       window：

       linux：

       还有使用ysoserial监听模块JRMP来进行反弹shell，具体可看参考文档，操作都差不多。

       正是因为利用简单，所以危害比较大。

       工具地址

       漏洞复现：CVE--

       环境：kali linux

       docker进行搭建启动

       访问：

       利用过程和shiro差不多，shiro需要登录网站，并从cookie中获取RememberMe。

       进行登录，使用正确的账号和密码：

       先使用正确的账号密码登录后，在抓包获取合法 Cookie（勾选Remember Me）

       如果认证失败则只能得到 rememberMe=deleteMe

       将登录后获取的set-cookie值当中的rememberMe值，将值复制下来，放到工具当中

       选择shiro，输入目标url，设置rememberMe值，点击下一步，等待即可

       选择检测方式：

       等待即可：

       使用shiro综合工具：

       输入url后：进行爆破秘钥，爆破利用链以及回显

       命令执行：

       工具地址

Shiro反序列化漏洞原理详解及复现

       要进行Shiro反序列化漏洞的探究，首先需要搭建一个vulhub提供的Shiro环境，通过访问端口进行测试确认。

       Shiro是个开源的安全框架，核心功能包括身份验证、授权和会话管理。当我们尝试登录并勾选"Remember me"选项，Burp抓包会发现响应包中的set-cookie字段包含'rememberMe'。如果不勾选，set-cookie则会设置为'rememberMe=deleteMe'，这成为判断网站是否使用Shiro和是否存在漏洞的线索。

       虽然不深入分析源码，但服务端在处理cookie时，会经历一系列操作，包括读取、处理和存储。这个过程中的一个环节，URLDNS链可以被利用，从HashMap的readObject方法开始，通过一系列转换最终发送DNS解析请求。利用ysoserial工具生成URLDNS链，然后对特定payload进行加密和编码，隐藏JSESSIONID并修改rememberMe字段。

       通过这种方式发送请求，DNS日志会显示成功，表明存在可利用的漏洞。进一步，可以尝试生成CC链，利用它执行反弹shell攻击，但需要注意，vulhub靶机可能缺少nc工具，需要先进行上传。

       关于Shiro的不同版本，1.4.2版本之前的使用CBC加密，虽然密钥不再硬编码，可以通过padding oracle攻击，但1.4.2及以后的版本切换到了GCM加密，这为防御带来了变化，需要在实际环境中考虑相应的防护措施。