1.Shiro的授授权Subject创建的内部流程
2.Shiro的简介
3.shiro反序列化漏洞原理分析以及漏洞复现（Shiro-550/Shiro-721漏洞复现）
4.Shiro权限管理框架（二）：Shiro结合Redis实现分布式环境下的Session共享
5.反序列化漏洞原理详解
6.Shiro源码分析---FilterChain创建过程
Shiro的Subject创建的内部流程
在使用Shiro框架进行编程时，我们通常会调用Subject对象的权流login()方法来实现认证过程。然而，程源当我们查看Subject接口的码分定义时，会发现login()方法实际上只是原理声明了功能，而没有具体的流程暗黑hackmap 源码实现。那么，授授权当我们在代码中调用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在认证和授权方面的高效和灵活。
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/...]
shiro反序列化漏洞原理分析以及漏洞复现（Shiro-/Shiro-漏洞复现）
shiro-反序列化漏洞（CVE--）漏洞简介
shiro-主要是由shiro的rememberMe内容反序列化导致的命令执行漏洞，造成的原因是默认加密密钥是硬编码在shiro源码中，任何有权访问源代码的人都可以知道默认加密密钥。于是攻击者可以创建一个恶意对象，对其进行序列化、编码，然后将其作为cookie的rememberMe字段内容发送，Shiro 将对其解码和反序列化，导致服务器运行一些恶意代码。webrtc源码书籍
特征：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的Vue显示源码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结合Redis实现分布式环境下的Session共享
Shiro权限管理框架第二篇深入讲解了如何结合Redis实现分布式环境下的Session共享。在集群环境中，单台服务器已无法满足高并发访问的需求，需要部署集群服务器以分担压力。然而，随着集群服务器的引入，如何在不同服务器间保持用户会话状态成为了一个挑战。
在无状态的HTTP协议下，通过Session和Cookie机制可以实现用户状态的持久化。用户在首次访问服务器时，服务器为其创建Session，并将唯一SessionId存储在Cookie中，以便在后续请求中识别用户。但随着集群环境的使用，同一用户在不同服务器间的Session无法共享，导致用户需要在每个服务器重新登录，这显然无法提供良好的用户体验。
为了解决这个问题，通常有两种方式：一是将用户请求固定到某一台服务器，通过IP算法或其他机制实现负载均衡。二是将所有服务器的Session进行共享，使得任何一台服务器都能访问到其他服务器的Session，确保用户在不同服务器间的连续性。Shiro结合Redis实现分布式Session共享，正是基于后一种策略。
通过继承Shiro的AbstractSessionDAO类，开发者可以轻松实现Session的增删改查操作，结合Redis作为分布式存储，可以高效地实现Session的分布式共享。Shiro框架本身已经封装了大部分流程，开发者只需关注具体的业务实现和配置，从而简化了复杂性。
实现过程包括自定义RedisSessionDAO、注入SessionManager、配置Shiro安全管理器等步骤，确保所有服务器间Session的一致性和可访问性。测试环节验证了分布式Session共享的正确性，确保了用户在不同服务器间登录状态的一致性。
基于Redis实现的Session共享，不仅简化了开发过程，而且提高了系统的扩展性和可用性。Shiro框架的使用，使得在不深入源码的情况下，即可实现强大的功能，这体现了框架设计的优秀性和实用性。然而，对于深入理解框架内部工作原理和机制，以提升开发者的编程能力和系统理解，同样重要。因此，深入Shiro源码的探索，将有助于开发者更全面地掌握这一框架的精髓。
通过Shiro结合Redis实现的分布式Session共享，不仅解决了集群环境下的用户会话一致性问题，还展示了框架设计如何通过抽象和封装，将复杂的系统设计简化为易于理解和使用的API，为开发者提供了高效解决问题的工具。这一过程不仅提高了开发效率，还促进了对框架核心机制的深入理解，为未来的项目开发和维护打下了坚实的基础。
反序列化漏洞原理详解
Apache Shiro 是一款强大且易用的 Java 安全框架，专用于执行身份验证、授权、密码和会话管理。在本文中，我们将深入剖析 Shiro 的认证和授权流程，特别关注 rememberme 字段如何引发反序列化漏洞。
首先，让我们探讨 Shiro 的认证过程。当用户尝试登录时，Shiro 通过验证用户名和密码来确认用户身份。这一过程在源码中清晰可见，主要通过 UsernamePasswordToken 对象和 Subject.login()方法实现。Subject 对象是 Shiro 中的核心概念，负责存储用户信息。在认证过程中，Shiro 通过调用 Realm 的 doGetAuthenticationInfo()方法来验证用户信息。该方法从数据库查询用户信息并进行比对，最终确认用户身份。
接下来，我们关注 Shiro 的授权机制。授权过程围绕着生成的 Subject 对象进行，确保用户具备访问特定资源所需的权限。在 Shiro 的配置文件中，权限规则被明确指定。通过调用 doGetAuthorizationInfo()方法，Shiro 能够为用户授权。这一过程中，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创建过程已全面解析完成。如有任何错误或需要进一步讨论的问题，欢迎指正。感谢阅读，期待更多的技术交流。
