Shiro反序列化漏洞利用实战：医院系统渗透测试与Web漏洞绕过技巧总结

是的，你没听错，整个利用过程可能只需要一分钟就能拿到shell。

这明显是一个Shiro反序列化漏洞，但使用常规字典爆破密钥并未成功。

不过，目标站点开启了Spring Boot Actuator端点，可以尝试手动添加路径进行访问。

通过访问/actuator/heapdump接口下载堆转储文件，然后进行解密分析，就能找到隐藏在其中的Shiro密钥。

你以为文章就结束了吗？不，这才刚刚开始。上面的案例其实是一个引子，它来自另一个项目中的真实漏洞。

前阵子我投入了一个非常消耗精力的项目，在长达一个多月的时间里，与380个医院站点进行“对抗”。整个过程充满了挑战，一边要应对WAF的拦截，一边还要躲避系统的自动封禁，全程都在反复切换网络连接，考验着手速和反应能力。

将这两个项目对比后，我发现除了医院（以及金融等）这类防护相对较强的目标，其他很多普通项目在安全测试面前，防护等级要低得多，测试起来会轻松不少。

实际上，医院站点的漏洞也并不都是很高深的技术，更多时候是捡漏那些尚未被他人发现的OWASP Top 10漏洞，以及运用一些比较巧妙的思路。在安全/渗透/逆向领域，这类实战经验尤为宝贵。

其中占比较高的漏洞类型是反射型XSS、存储型XSS和越权漏洞。

反射型XSS的绕过技巧

对于某些配置的WAF，反射型XSS可以通过参数污染的方式进行绕过。

比如攻击载荷key=<script>alert(1)</script>，直接提交可能会被拦截。

这时可以尝试增加大量无关参数，例如a=12&b=232&c=23&d=2312...。十个参数不够就加二十个，一直加到绕过为止。

或者观察WAF拦截了哪些关键词。像prompt、alert、confirm这类常见弹窗函数如果都被拦截，可以尝试使用console.log，它的拦截率通常会低一些。

如果这些方法都无效，就只能尝试其他HTML标签和攻击思路了，例如加载外部JS、构造跳转链接，或者利用DOM操作修改页面元素等。毕竟在渗透测试中，除了获取Shell，这些同样都是有效的安全漏洞。

一个典型的参数污染载荷示例如下：

AppLock=zb4w3&_VIEWSTATEENCRYPTED=uy2a5&allowfiles=xk1h9&c=hfzn2&callback=p17u0&cmdButtons=trwg1&div=voia2&email=h6hq5&enddate=d7157&g_PageMainMenuID=x8l74&h_packageMode=zhm34&h_zlk=avsp2&jpg=dm0g6&l=d4fm5&mode=</script><meta http-equiv="refresh" content="3;url=https://www.baidu.com">oImg=c5830&oTDFlag=bzfx7&r=noz70&segs=pf9p6&textarea=flgl2

案例一：
某个站点防护非常严密，最终通过构造重定向载荷成功验证漏洞。

案例二：
这是一个前端 & 移动端的小程序，在修改用户名信息时存在漏洞，但受到了WAF和字符长度限制的双重防护，弹窗被拦截。
最终通过输入"><svg onload=console.log(1)>，成功闭合标签并执行代码。

案例三：
某医院官网。与案例一类似，使用参数污染，起初alert弹窗被拦截，但后来发现WAF只拦截了alert，prompt可以正常弹窗。

存储型XSS的利用

存储型XSS通常需要寻找各类文件上传接口，构造恶意文件。直接上传JSP等动态脚本文件基本会失败，可以尝试SVG、XML、HTML或利用PDF的XSS。

案例一

案例二

案例三

越权漏洞测试

越权漏洞在医院的小程序中较为常见。

如果参数是明文ID，通常可以直接进行遍历测试。
如果ID是UUID或SHA256等哈希值，由于账号实名信息固定，可以尝试使用同事的账号ID进行替换，测试两个账号间的数据能否互相访问。

案例一：遍历ID
通过遍历参数，可以越权查看到其他患者的敏感信息。

案例二：替换friendId
替换请求中的friendId等参数，实现越权操作。

很多医院都有住院部、食堂等配套小程序，登录或查询通常需要住院人姓名、身份证号或手机号的组合。
暴力破解通常不可行，但有时能在社交平台（如抖音）上找到安全意识薄弱的人发布的病例信息，通过搜索对应医院名称可能有所收获。虽然这种方法涉及伦理问题，但确实暴露了信息泄露的风险。

其他常见漏洞

短信轰炸漏洞：很多小程序的数据加解密算法并不复杂，常见的是AES CBC 128位加密。反编译小程序后，直接在JS代码中搜索aes、decrypt、encrypt等关键词，很可能找到密钥。找到密钥后，可以解密出手机号等参数，通过修改参数（如添加逗号、空格、分号），或直接进行并发请求，来测试短信轰炸漏洞。

支付逻辑漏洞：在众测(SRC)中常被提及的支付逻辑漏洞，这次也遇到了。在一个积分兑换奖品的功能中，抓包修改积分为0后提交，即可成功兑换，实现“零元购”。

以上便是近期在一些项目，特别是医疗行业渗透测试中的一些经验复盘与总结。从HTML/CSS/JS层面的前端绕过，到后端的逻辑缺陷，安全测试往往是一场关于细节和耐心的较量。希望这些实战案例能为你带来一些启发。更多技术讨论，欢迎访问云栈社区进行交流。