欢迎来到皮皮网官网
1.Shiro的码分简介
2.技术干货CodeQL从0到1（内附Shiro检测演示）
3.shiro反序列化漏洞原理分析以及漏洞复现（Shiro-550/Shiro-721漏洞复现）
4.Shiro的Subject创建的内部流程
5.Shiro源码分析---FilterChain创建过程
6.Shiro权限管理框架（二）：Shiro结合Redis实现分布式环境下的Session共享
Shiro的简介
在之前的学习中，我未记录Shiro的码分相关笔记，现在决定补全这部分内容。码分虽然之前写过一篇基础介绍，码分但感觉总结不够全面。码分
Shiro作为当前热门的码分kvm 源码分析安全框架，其实质是码分权限管理工具，主要负责用户对系统资源的码分访问控制。例如，码分访问路径"/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以及配置权限访问规则。
绕过机制方面，android app框架源码Springboot版本和Shiro版本的搭配会影响绕过漏洞的复现。在Shiro配置中，绕过行为通过路径匹配进行控制。在绕过漏洞的分析中，可以看到Spring和Shiro在处理请求路径时的差异，导致权限控制的失效。
关于更多Shiro绕过漏洞的详细内容，可以参考nice0e3师傅的文章，链接在这里：[tttang.com/archive/...]
技术干货CodeQL从0到1（内附Shiro检测演示）
CodeQL是一种由Semmle公司开发，GitHub收购的代码分析平台。它能够从代码中提取信息并构建数据库，通过编写查询消息获取所需信息，尤其在安全代码审计中，CodeQL可识别已知漏洞并生成查询规则，从而发现代码中类似的潜在漏洞。
CodeQL支持多种编程语言和框架，详细信息可以在官方文档中查看。安装过程包括下载核心解析引擎和开源库，引擎部分不开源，主要用于解析数据库执行操作，而库部分则允许用户编写自定义规则。CodeQL提供命令行工具和VSCode插件两种方式，插件提供图形界面，封装了一些功能，使用起来更为便捷。
CodeQL的工作流程分为提取数据库和执行查询两部分。解释型语言如Python，数据库提取使用特定工具，编译型语言如Java，则需要在编译过程中获取所需信息，最终获得源码的抽象语法树（AST）以及源码，一并打包为数据库。查询过程包括编译和执行阶段，与库文件一起提交给编译器进行编译，之后在数据库中提取数据。
CodeQL的基本语法、数据类型、结构、函数、类等概念可以在官方文档中找到详细介绍。函数在CodeQL中被称为谓语，打赏平台 源码用于封装逻辑，使代码更加简洁明了。每个类都必须继承一个父类，父类的值成为子类的初始值集，自定义类通常需要继承库提供的类。污点追踪功能是CodeQL的重要特性之一，它通过建立代码有向图来追踪参数和表达式的流向，帮助发现潜在的漏洞。
在使用CodeQL编写规则时，会遇到环境搭建、数据库获取等问题。例如，获取shiro1.2.4版本的数据库需要maven编译，可能涉及环境配置。污点追踪在连接特定节点时，如`cookie.getvalue()`，CodeQL可能无法识别两者之间的关系，这时可以使用`isAdditionalTaintStep()`方法将节点连接起来。此外，CodeQL可能无法识别所有变量传递关系，需要通过额外分析和逻辑判断进行连接。
最终，通过正确使用CodeQL，可以有效识别和预防代码中的安全漏洞，提高代码质量和安全性。开发者可以参考官方文档、教学视频等资源深入学习CodeQL的使用方法。如果遇到特定问题，可以关注“星阑科技”微信公众号，获取更多安全干货和解决方案。
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，才可以进行下一步攻击。php 源码后门查杀
漏洞指纹
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的Subject创建的内部流程
在使用Shiro框架进行编程时，我们通常会调用Subject对象的login()方法来实现认证过程。然而，当我们查看Subject接口的定义时，会发现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在认证和授权方面的高效和灵活。
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权限管理框架（二）：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，为开发者提供了高效解决问题的工具。这一过程不仅提高了开发效率，还促进了对框架核心机制的深入理解，为未来的项目开发和维护打下了坚实的基础。
