企业官网建设流程全解析

做Java Web方向的安全评估这几年，Shiro这条线几乎每年都会碰上一次，而且大多数时候它不是测试目标里的主角，而是"顺手发现"的那一类——甲方让你看一个后台越权，结果抓包时一个rememberMe的Cookie把你直接带到了反序列化这条路上。Apache Shiro这套权限框架在国内后台系统里的铺开程度很高，它的"记住我"功能默认走AES-CBC加密后再反序列化还原身份对象，一旦密钥停留在框架自带的默认值上，理论上就等于把一条命令执行通道挂在了对外服务上。这篇就围绕Shiro漏洞工具的实际使用场景来聊：怎么确认目标真的是Shiro、怎么判断密钥对不对、gadget链怎么挑、工具跑不通时该顺着哪条线往下查，以及修复侧真正能落地的做法。内容全部基于授权测试和自建靶场的经验，所有操作请只在你有明确书面授权的资产范围内进行，未经授权的探测和利用本身就已经越线了。

1. 把rememberMe这条链路讲透：漏洞到底出在哪一环

1.1 一个Cookie背后其实有三段独立处理

很多人第一次接触这个话题，是看到别人发一个请求包，Cookie里塞一大串Base64，然后服务端就执行命令了。看起来很神奇，但如果把这条链路拆开，它其实是三段再普通不过的处理流程串在一起，任何一段补上校验，整条链就断了。

第一段是凭证序列化。用户勾选"记住我"登录成功后，Shiro会把当前的身份信息对象（通常是SimplePrincipalCollection）通过Java原生的ObjectOutputStream序列化成字节数组。第二段是加密包装。序列化后的字节数组交给JcaCipherService做AES-CBC加密，加密结果再Base64编码，写进名为rememberMe的Cookie返回给浏览器。第三段是还原。用户下次带着这个Cookie访问，Shiro从Cookie里取出Base64串，Base64解码、AES解密、再ObjectInputStream.readObject()反序列化，还原出身份对象完成自动登录。

问题的根子就在第三段。readObject()本身不检查你反序列化出来的到底是不是一个身份对象，它会老老实实按照字节流里的类描述去构造对象、执行readObject相关逻辑。只要你能控制解密后的明文，就能让服务端构造出任意一个存在于其classpath上的类——这就是反序列化漏洞的经典模型，Shiro只是给它套了一层"看起来像Cookie"的外壳。

而这里有个特别关键的点：无法执行的先决条件是"能构造出合法密文"，也就是你得知道AES密钥。这就是为什么整个Shiro漏洞话题始终绕不开"密钥"两个字——它不是一个纯粹的代码缺陷，而是"弱默认配置"和"危险反序列化"两个问题的叠加。

1.2 AES-CBC的细节：IV放在哪、密钥怎么用

具体到加解密参数，Shiro默认用的是AES/CBC/PKCS5Padding，密钥长度16字节（AES-128），密钥来源是配置里那个Base64字符串解码后的结果。默认实现在加密时，会随机生成一个16字节的IV，然后把IV直接拼在密文前面，最终结构是：

Cookie值 = Base64( IV(16字节) || AES-CBC密文 )

服务端解密时先Base64解码，取前16字节当IV，剩下的当密文。这个细节决定了我们自己构造payload时应该怎么拼：生成随机IV、用密钥加密、把IV拼回去、再整体Base64。如果顺序搞反了或者忘了拼IV，服务端解密出来就是一坨随机字节，反序列化直接抛异常，你会看到响应里回了一个rememberMe=deleteMe——很多人以为这是"密钥不对"，其实有可能只是拼装格式错了，这点后面还会细说。

用Python快速搭一个构造脚本，逻辑非常短：

import base64, os from Crypto.Cipher import AES from Crypto.Util.Padding import pad def build_remember_me(payload_bytes: bytes, key_b64: str) -> str: key = base64.b64decode(key_b64) # 16字节 assert len(key) == 16 iv = os.urandom(16) # 每次都要随机 ct = AES.new(key, AES.MODE_CBC, iv).encrypt(pad(payload_bytes, 16)) return base64.b64encode(iv + ct).decode() # payload_bytes 来自 ysoserial 等工具生成的序列化流

这段代码值得你自己手敲一遍，因为它把"密钥、IV、填充、拼接"这四件事都摆在了明面上。理解了它，你再看任何一款GUI工具，就知道它内部无非是在做什么。

1.3 硬编码密钥是怎么遗留在生产环境的

默认密钥这个东西，其实官方在1.2.5版本就已经从代码里移除了，1.4.2又修掉了Padding Oracle那条链。按理说不该有大规模存量问题，但现实是：大量项目的依赖版本锁死在1.2.4，或者虽然升了版本，却在配置文件里手工写了一串固定的、从网上抄来的密钥。

我在实际项目里见过的遗留原因大致有三类。一类是脚手架和二次开发框架——某些快速开发框架在示例配置里写死了密钥，使用者照抄上线，这类系统的密钥往往高度集中，字典里命中率极高。一类是运维为了"统一管理"，把所有环境配成同一个密钥，导致测试环境的密钥泄露等于生产环境失守。还有一类更隐蔽：升级了Shiro版本，但业务代码自己实现了一个RememberMeManager，在构造时用常量设了密钥，升级依赖反而没解决问题。

所以判断一个目标值不值得深入研究，第一步不是急着上工具，而是先想清楚：这个系统是什么时候上线的、用的什么框架、有没有可能沿用默认配置。经验上，2016到2019年间上线的Java后台系统，遇到默认密钥的概率明显偏高。

2. 搭一个属于自己的复现靶场：依赖与配置的那些坑

2.1 用最小工程复刻1.2.4的环境

工具用得再熟，不如自己搭一遍环境理解得深。搭靶场的最小组合是Spring Boot加shiro-spring，Maven依赖就两个核心坐标：

<dependency> <groupId>org.apache.shiro</groupId> <artifactId>shiro-spring</artifactId> <version>1.2.4</version> </dependency> <dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-web</artifactId> <version>2.3.4.RELEASE</version> </dependency>

这里第一个坑就来了：不同大版本的shiro-spring坐标不一样。1.2.x到1.6.x用的是shiro-spring，1.7之后主推shiro-spring-boot-web-starter，两者的自动装配逻辑完全不同。如果你的靶场引了starter但配置类还是照抄老教程写的ShiroFilterFactoryBean那套XML风格，很可能Bean冲突或者过滤器根本没生效，最后你会得到一个"能登录、有rememberMe、但Cookie一看就是没加密"的假靶场。

第二个坑是Spring Boot版本和Shiro版本的兼容性。Spring Boot 2.6以上对循环依赖做了更严格的限制，老版本Shiro的一些Bean装配方式会直接起不来；Spring Boot 3.x基于Jakarta EE，而绝大多数老版本Shiro还在用javax.servlet，两者硬凑会得到一堆ClassNotFoundException。稳妥的做法是把靶场和真实目标的环境对齐——你想测什么版本，靶场就用什么版本，别图省事拿最新版糊弄。

2.2 配置文件里那几个决定"能不能被利用"的开关

环境搭起来之后，真正决定靶场是不是"可被打"的，是SecurityManager那几行配置。核心是给DefaultWebSecurityManager设一个带密钥的CookieRememberMeManager：

@Bean public SecurityManager securityManager() { DefaultWebSecurityManager sm = new DefaultWebSecurityManager(); sm.setRealm(myRealm()); CookieRememberMeManager rmm = new CookieRememberMeManager(); // 想复现默认密钥场景，这行什么都不要设，1.2.4内部会用内置默认值 // 想复现"自定义弱密钥"场景，用下面这行 // rmm.setCipherKey(Base64.decode("kPH+bIxk5D2deZiIxcaaaA==")); rmm.setCookie(new SimpleCookie("rememberMe")); sm.setRememberMeManager(rmm); return sm; }

有几个容易忽略的开关值得单独说。rmm.setCookie()里的Cookie名默认就是rememberMe，但有些系统会改名字（比如改成token或remember），这时候你用默认名去探测是探测不到的，需要先从前端JS或响应头里确认真实名字。另一个是**setCipherKey的调用时机**——如果在@PostConstruct里设或者依赖注入顺序不对，可能出现"配置写了但没生效"，自己搭靶场时建议直接用默认值复现一次，再改成自定义密钥复现一次，两边都跑通，你对整个链路的把控才算完整。

如果是用application.yml风格的配置（新版starter支持），关键项大概是shiro.rememberMe.cookie.name、shiro.rememberMe.cipherKey这种，名字看着简单，但不同小版本之间键名有过调整，写错了不会报错，只会静默不生效。判断是否生效的办法很简单：登录勾选记住我，看返回Cookie的解码长度，如果只有几十字节且不像是密文，多半就是没加密。

2.3 自检：靶场到底可不可复现

靶场搭完，别急着上工具，先做一次自检。第一步，用curl带一个明显非法的rememberMe值请求受保护路径：

curl -i http://127.0.0.1:8080/admin \ -H "Cookie: rememberMe=deleteMe"

如果响应头里出现了Set-Cookie: rememberMe=deleteMe，说明Shiro确实在处理这个Cookie，识别环节通了。第二步，用Python脚本按1.2节的方式，把默认密钥加密一段随便什么字节塞进去，观察响应：如果服务端返回500或者跟正常响应明显不同，说明密钥有效、解密成功、在反序列化阶段炸了，这条链就具备复现基础了。第三步，换成ysoserial生成的URLDNS payload，看你的DNSLog平台有没有收到解析请求——这一步是最干净的验证，因为它不依赖命令执行回显。

提醒：自检阶段所有的DNSLog、HTTP回显平台都用你自己搭建的，不要往第三方公共服务上传测试数据，很多公共服务会记录来源IP，回头解释起来很麻烦。

3. 指纹识别与密钥探测：先判断值不值得继续

3.1 三个低成本的指纹判断方法

真实项目里，你不可能一上来就抓到一个rememberMeCookie。识别一个站点是不是用了Shiro，通常从三个地方入手。

最直接的是响应头特征。未登录访问受保护路径，Shiro默认会302重定向到登录页，Location往往带着;JSESSIONID=这样的写法，或者路径里有明显的login跳转逻辑。这个特征不能单独作为结论，但可以作为一个"值得深挖"的信号。

第二个是Cookie回显。前面提到的rememberMe=deleteMe请求法是最稳的：你随便填一个非法值，Shiro解密失败后会调用forgetIdentity把Cookie清掉，于是响应里带上rememberMe=deleteMe。这个行为在相当多的版本里都存在，命中率很高。要注意的是，如果目标做了WAF或者反向代理对Set-Cookie做了处理，这个方法可能失效，得多测几次不同路径。

第三个是报错页面特征。主动构造一些异常请求，看错误页里有没有org.apache.shiro开头的堆栈。开了调试模式或者错误页没做处理的老系统，经常会直接把UnavailableSecurityManagerException、UnknownSessionException这类异常抛到页面上，一眼就能确认。这个方法的副作用是会往目标日志里写一条异常记录，授权测试里没问题，但要注意频率。

3.2 密钥探测的判定逻辑：有回显与无回显两套打法

确认是Shiro之后，下一步就是判断密钥。这里必须把逻辑讲清楚，否则很容易误判。

有回显场景的核心判定是"响应差异"。你用候选密钥构造一个payload发过去，观察三种结果。第一种，响应里依然有rememberMe=deleteMe，说明解密失败，密钥不对，或者你的payload格式拼错了。第二种，响应变成500或者跟正常请求完全不同的页面，说明解密成功但反序列化炸了，密钥大概率是对的，只是gadget链没配好。第三种，响应正常返回200且没有deleteMe，说明整条链走通了，可能是payload里的对象被成功构造了。这套逻辑听着简单，实操中最大的干扰来自目标自身的错误处理——有的应用把所有异常都吞掉统一返回同一个错误页，这时候三种结果长得一模一样，判定就失效了。

无回显场景就得靠带外数据了。这时候URLDNS这条链几乎是必选项：它只依赖java.util.HashMap和java.net.URL，不需要任何第三方库，payload极小，触发时会发起一次DNS解析。你只要能观察到DNS请求，就证明密钥正确、反序列化执行成功。用URLDNS的好处是它对JDK版本不敏感，从JDK 6到比较新的版本基本都能用，适合做"第一发"验证。缺点是它只能证明漏洞存在，不能执行命令，所以后续该换链还得换链。

3.3 探测频率、日志留痕与授权边界

这一段是很多教程不会讲、但实际工作中最重要的部分。密钥爆破本质上是高频率地向目标发送畸形Cookie，每一次失败尝试都会在服务端产生一条反序列化异常日志。几十次可能没人注意，几百上千次就很可能触发告警，严重的会直接导致服务不可用或者被安全设备封IP。

我的做法是：先把字典规模压下来。市面上那些上千条的密钥字典，绝大多数条目命中率极低，真正值得优先试的其实就那么十几条——各版本官方默认值、几个知名开源框架的内置值、以及"看起来像Base64的拼音"这类明显人工构造的值。按优先级分批试，第一批控制在20条以内，如果没命中再考虑扩大。同时控制并发和间隔，不要开多线程猛刷，单线程加合理延时，既能降低告警概率，也能让响应差异更容易观察。

还有一点必须说清楚：探测范围严格限定在授权清单内的资产。同一台服务器上挂了多个域名、同一套代码部署了多个环境，这些都不在授权范围内，除非白纸黑字写清楚了。真出过事情，一句"我以为都是同一个系统"是解释不通的。另外，整个过程的所有请求包、响应、时间点都要留存，这既是报告的证据，也是自证清白的依据。

4. 利用链怎么挑：依赖、JDK版本和"能不能打通"的关系

4.1 为什么CommonsBeanutils1在Shiro场景里出场率最高

如果你只记一条链的名字，那就记CommonsBeanutils1。原因很实在：Shiro自己对commons-beanutils有依赖。它的RememberMe身份对象处理、以及内部一些Bean操作都会用到这个库，所以只要目标用了Shiro，classpath里几乎必然有commons-beanutils。这就意味着这条链的"存在前提"天然满足，不需要碰运气去猜目标引了什么业务库。

这条链的本质是借助BeanComparator在比较过程中触发任意getter调用，再配合TemplatesImpl去加载字节码。之所以特别值得说，是因为TemplatesImpl这条路不依赖远程类加载。很多人在JNDI那条链上吃过亏——JDK 8u191之后com.sun.jndi.ldap.object.trustURLCodebase默认关闭，远程加载类被禁掉，老教程里的用法直接失效。但TemplatesImpl是通过defineClass在本地定义类的，跟远程加载是两条路，所以它在新版JDK上依然能打，这是它至今仍然主流的核心原因。

当然也有例外。如果目标应用做了序列化白名单，或者在ObjectInputStream层面加了过滤，TemplatesImpl这个名字往往是被重点照顾的对象。这种情况下要么换链，要么就得承认打不通，别在一条路上死磕。

4.2 常见链与依赖、JDK版本的对应关系

把常见链的适用条件整理成一张表，比背概念有用得多：

用这张表的时候有个实操技巧：先判断目标JDK。JDK版本可以通过报错页、Server头、甚至某些响应特征侧面推断，实在判断不出来就用几条不敏感的链分别试。判断依赖则更麻烦一点，除了靠经验猜业务框架，还可以通过公开信息（比如前端资源特征、favicon哈希、报错信息里的包名）来辅助。这两项信息越准，gadget的命中率越高。

4.3 GUI工具和命令行工具的边界在哪

工具选型上，我一般分两类用。命令行类的代表是ysoserial，它的优势是链全、可控、可脚本化。你可以批量生成payload、自己拼Cookie、自己判定响应，缺点是每一步都得自己写，探测阶段效率低。GUI综合工具的优势是一键完成"爆破密钥+选择链+执行命令"，对刚入门的人非常友好，用它快速验证一个目标是不是有戏，效率很高。但它的局限也很明显：内置链通常就那几条，遇到需要特定依赖的场景就卡住了；而且这类工具的请求特征比较固定，容易被流量设备识别。

我的习惯是混合用：先用GUI工具做快速筛查，确认密钥和基础利用可行；一旦需要针对特定依赖或特定JDK做精细利用，就退回到ysoserial加自己写脚本的方式。另外提醒一点，GUI工具在本地运行时生成的日志、payload文件、缓存都留在磁盘上，做项目的时候记得清理，这些文件本身也属于敏感资料。

Burp插件在识别阶段很有价值，它能被动地从流量里发现带rememberMe的请求，然后提供重放和替换的功能，省去手工构造的麻烦。但它只解决"发现和重放"，链的选择和判定还是得靠人。

5. Shiro-721：密钥不是默认值时还剩多少空间

5.1 Padding Oracle的触发前提

聊完550，就得聊721。很多人对这条链有误解，以为它能在任何Shiro目标上通用，实际上它的门槛比550高得多。

721的底层是CBC模式的Padding Oracle，原理是利用服务端对"解密后填充是否合法"这件事的响应差异，逐字节地把明文推出来。在Shiro这个场景里，它要解决的问题是：我知道Cookie是AES-CBC加密的，但我不知道密钥，能不能通过反复构造和发送Cookie，把一段合法密文"改造"成我想要的样子。

它有一个非常硬的前提：你手上得先有一个合法的、服务端能正常解密的rememberMe Cookie。这个Cookie通常来自一次正常的"记住我"登录——也就是说，你得先有一个能登录的账号。这个前提直接把大量场景排除掉了：没有账号的目标、登录有强验证码的目标、账号权限受限的目标，721基本无从下手。

5.2 和550的成本对比

把两条链放一起对比会更清晰：

从这张表就能看出来，721在实际项目中失败率相当高。请求量一大，网络抖动导致某一次响应判断错，整个推导过程就得重来；WAF对高频相似请求几乎必然会拦。我见过不少人在721上花了整整一天，最后卡在"推到一半响应突然变了"上。

5.3 什么时候该果断放弃

判断标准其实很简单：如果目标有WAF且规则敏感、或者网络延迟不稳定、或者你没有稳定的合法Cookie，就不要在721上耗时间。有那个精力，不如回头把550的字典再筛一遍，或者换个思路去找该系统的其他入口。

另外要说明的是，Padding Oracle这条链官方在1.4.2版本已经修掉了，做法是改用随机IV并增加完整性校验。所以如果你确认目标版本在1.4.2以上，721这条路基本可以直接跳过，别白费力气。

6. 加固这件事：从"修好"到"修对"

6.1 升级、换密钥、关功能三件事的优先级

修复这件事，我见过太多"改了个寂寞"的案例。最常见的是只做了一件事：换掉默认密钥。换密钥当然有用，它把550这条链堵死了，但如果业务还在用反序列化还原身份对象，本质风险只是从"密钥被猜中"变成了"密钥泄露就完蛋"，而且721那条链在特定版本上依然存在。

所以修复有个明确的优先级。第一优先是升级版本：至少升到官方已经修掉Padding Oracle的版本线，能一步到位升到较新版本更好。升级之前先把业务回归测试做全，Shiro的版本跨度大了之后，过滤器链、会话管理的默认行为都有变化，不测直接上生产容易出问题。

第二优先是密钥治理：删除配置里所有硬编码密钥，改成从环境变量或配置中心注入，并且确保每个环境、每次部署的密钥都不同。密钥本身用密码学安全的随机源生成，长度足够，别再用"拼音+Base64"这种人工构造的值。

第三优先才是考虑关闭rememberMe功能。如果你的业务里用户根本不依赖自动登录，那直接关掉是成本最低、收益最高的做法。关的方式是把RememberMeManager置空或者让登录时不设置该Cookie，改完记得验证Cookie不再下发。

6.2 序列化过滤与运行时防护

除了上面三件事，还有一层"兜底"手段值得加上：序列化过滤。较新的JDK支持通过系统属性配置jdk.serialFilter，限制允许反序列化的类范围：

# 只允许白名单内的类参与反序列化 -Djdk.serialFilter=org.apache.shiro.**;java.util.**;!*

这个配置的写法需要根据业务实际情况调整，写得太严会导致正常功能失败，写得太松就没有意义。上线前务必在测试环境验证自动登录、会话恢复等功能是否正常。

在应用层，还可以考虑重写或包装RememberMeManager，在反序列化之前做一次类名校验。这种做法要慎用，因为一旦自己实现加密逻辑，很容易引入新的问题，比如IV处理不当、校验逻辑被绕过等。我的建议是能不自己写就不自己写，优先依赖官方版本的修复。

网络层和设备层的缓解可以加，但要清楚它们的定位：WAF规则本质是特征匹配，能挡住扫描器和已知模式的攻击，挡不住针对性变形。把WAF当唯一防线是不靠谱的，它应该和版本修复、密钥治理组合使用。

6.3 漏洞报告里必须讲清楚的东西

作为乙方或者内部安全同学，报告写得好不好直接影响修复效率。我总结下来有几项是必须写清楚的。

复现步骤要能一步步走通，包括完整的请求包、Cookie值（脱敏后的）、响应特征，让别人拿着报告能自己复现一遍。影响范围要具体，不要只写"可导致远程代码执行"，而要说明是在什么前提下可执行、能拿到什么权限、能访问哪些数据。危害评级要有依据，可以引用通用评分体系，说明打分的维度。修复建议要分层次，给出"必须做"和"建议做"两档，让业务方知道哪些是硬性要求。

还有一个容易被忽略的点：说明复现过程中产生的日志和数据。你在测试时往目标日志里写入了多少条异常记录、有没有产生测试数据、需不需要清理，这些都该在报告里交代清楚，这既是专业度的体现，也能避免后续扯皮。

7. 实战踩坑记录：那些看着能打其实打不通的场景

7.1 排查链路比结论更重要

我碰到过一个很典型的情况：指纹确认是Shiro，密钥也试出来是对的（URLDNS能收到解析），但换任何一条命令执行链都失败，响应始终是500。当时的排查是这么走的。

第一步，确认密钥判定本身没错——重发URLDNS，多次都有解析，排除了"响应差异误判"。第二步，怀疑gadget链的依赖不存在，于是用几条不依赖第三方库的链分别试，全挂，说明问题可能不在依赖。第三步，怀疑JDK版本，从报错堆栈里翻出了JDK版本信息，发现是比较新的版本，JNDI那类依赖远程加载的链直接被排除。第四步，回到反序列化本身，构造一个极简的、只用JDK内置类的payload，观察是否还能正常反序列化——结果发现在反序列化阶段就被拦了，堆栈里出现了序列化过滤相关的类名。

到这一步结论就清楚了：目标在JDK层面或者应用层面加了序列化过滤，TemplatesImpl这类敏感类被拦了，所以命令执行链路全线失效。这种情况下硬打没有意义，正确做法是把这个发现写进报告，说明"存在反序列化入口，但被过滤机制拦住，风险等级相应下调"，同时建议把版本升级和密钥治理补齐。

这个案例的价值在于：排查过程本身就是信息。不要因为打不通就跳过，很多情况下"为什么打不通"比"能打通"更能说明目标的安全水位，报告里也更有说服力。

7.2 一些容易被忽略的小细节

还有几个细节，都是踩过之后才记住的。

Cookie名字不一定叫rememberMe。有的系统改成了自定义名字，你按默认名探测永远探不到。解决办法是先看登录响应里的Set-Cookie，或者在前端JS里搜一下Cookie写入逻辑。

HTTPS和HTTP的判定结果可能不同。有些系统在前面挂了代理，HTTP请求被重定向，Cookie在不同协议下的处理不一致，导致判定结果飘忽。测试时要保持协议一致。

响应时间也是有用的信息。密钥正确时，服务端要完整走完解密和反序列化流程，耗时通常比解密失败要长一点。在响应内容完全相同、无法靠内容判断的情况下，可以借助多次请求的耗时统计来做辅助判断，但只能作为参考，不能单独作为结论。

自己生成的payload要留档。做项目时生成的每一个payload、每一次尝试的密钥、每一条链的结果，都建议记在本子里或者文档里。当天可能觉得没用，第二天回头看可能就是破局的关键。我现在的习惯是每试一批密钥就记一行，包含时间、密钥、响应特征，最后汇总起来看规律，效率比凭记忆高得多。

别忘了清理环境。测试结束后，靶场该关的关，本地生成的payload文件和工具缓存该删的删，DNSLog之类的带外平台记录该清的清。这些都是基础操作，但确实有人因为留了个payload文件在共享目录里被问过话。

最后说一句实在话：这类工具和技巧本身没有立场，用在哪里、给谁用，才决定了它的性质。我自己的做法是，接活之前先把授权书看三遍，范围里没写的资产一律不碰，测试过程中所有操作留痕。技术再熟练，踩了这条线，前面所有积累都会归零。