mcpField
T
testing-thick-clients

testing-thick-clients

github.com/trilwu安全17744 次安装12 周前更新
代码仓库

关于 testing-thick-clients

这项技能指导安全测试人员评估已安装的桌面客户端,涵盖本地机密与存储、网络流量、授权、更新和 DLL 加载。重点是发现应用把信任放在用户可控制的客户端上的问题。

主要功能

  1. 01梳理客户端与后端架构
  2. 02检查本地机密、文件和内存
  3. 03拦截非 HTTP 流量
  4. 04测试客户端授权机制
  5. 05审查更新与 DLL 加载

适用场景

  1. 01评估已安装的桌面应用
  2. 02调查 Burp 无法观察流量的客户端
  3. 03测试双层应用的数据库访问

安装

复制下面的命令,在终端中运行。

$npx skills add https://github.com/trilwu/secskills --skill testing-thick-clients

安装后在 Claude Code 中输入/testing-thick-clients确认已加载。

详细介绍

测试厚客户端

厚客户端会将部分应用程序放在测试人员自己的机器上,这正是整个测试机会所在:二进制文件、配置、内存和流量都触手可及。这类应用反复出现的问题是信任客户端——在用户控制的设备上实施授权、隐藏功能或存放机密。任务是枚举这片攻击面,并指出信任错置之处。

适用场景

  • 评估与后端通信的已安装桌面应用(.NET/WPF、Java/Swing、Electron、Qt、原生 Win32)
  • 使用 Burp 看不到任何内容的胖客户端,因为流量不是 HTTP,或客户端不支持代理
  • 直接连接数据库的两层应用
  • 检查桌面应用的本地存储、IPC、更新完整性和 DLL 加载

不适用场景

  • 浏览器/Web 应用及其 API——使用 testing-web-applications 和 testing-apis;仅在面对已安装的桌面客户端时使用此处内容。
  • 将 Electron 内部机制作为 JS 逆向问题处理(解包 app.asar、反混淆代码包):代码部分参考 reversing-obfuscated-javascript,应用的信任面则参考此技能。
  • 没有安全测试目标的纯二进制逆向工程——使用 analyzing-binaries;对于托管代码,使用 analyzing-dotnet-assemblies。
  • 移动应用——使用 testing-mobile-applications。
  • 将内存破坏导致的崩溃转化为漏洞利用——这属于 exploiting-memory-corruption。

先梳理架构

最重要的问题是应用有几层,因为这会改变攻陷客户端后能获得什么:

  • 两层(客户端 → 直接连接数据库):客户端必须持有数据库凭据,而配置或内存中的连接字符串能让你获得与应用相同的数据库直接访问权限。这是厚客户端中价值最高的发现;应优先检查。
  • 三层(客户端 → 应用服务器 → 数据库):客户端与 API 通信,攻击面类似于 Web 测试,还要加上下文所述的本地攻击面。

接下来确定技术栈——托管型(.NET、Java)、Electron 或原生——因为这决定了后续每一步要使用的工具。

本地攻击面

应用存储在测试人员机器上的所有内容都可读取:

  • 配置和机密。 app.config/.exe.config、.ini、JSON、注册表或 %APPDATA% 中的连接字符串、API 密钥和加密密钥。留意使用随同一二进制文件发布的密钥进行“加密”的机密——找回密钥后,内容就会变成明文。
  • 文件系统和注册表活动。 在操作应用时运行 Procmon(Sysinternals),查看它访问的每个文件和注册表项;Regshot 可对比操作前后的注册表。安装目录或服务的 ACL 设置过弱,会导致本地权限提升。
  • 本地数据库。 SQLite 和类似存储通常会缓存数据或令牌;直接打开它们。
  • 内存。 为供使用而解密的机密会留在进程中;对转储运行 strings,或使用 Process Hacker / System Informer,即可找回这些内容。
  • 二进制文件。 使用 dnSpy/ILSpy(适用于 .NET,混淆代码可配合 de4dot)或 Java 反编译器反编译托管代码;硬编码逻辑、密钥和隐藏端点都会显现出来。

拦截非 HTTP 流量

如果客户端不支持代理或不使用 HTTP,Burp 就什么也看不到:

  • 使用 HTTP 但不支持代理 — 强制流量经过代理(系统代理、类似 proxifier 的重定向,或 hosts/DNS),并信任代理 CA。通常需要配置后,.NET 应用才会使用系统代理。
  • 非 HTTP TCP/TLS — 使用 mitmproxy 的透明/反向模式,或设置隐形代理,并先用 Wireshark 了解协议。旧资料中会提到 Echo Mirage;但它在现代 Windows 上不可靠,因此优先采用运行时 Hook。
  • 运行时 Hook — 使用 Frida 在桌面进程中直接拦截 send/recv 或 TLS 例程;当应用固定证书或自行封装加密时,这比折腾网络层更有效。

客户端信任——核心类别

假设任何仅由客户端强制执行的控制都可以绕过,并验证这一点:

  • 禁用的按钮、隐藏的菜单,以及由客户端标志控制的“管理员”功能 — 在内存中或反编译后的二进制文件中修改该标志;如果服务器不重新检查,你就能使用该功能。
  • 客户端输入验证和业务规则 — 通过代理绕过,并检查服务器是否会重新验证。
  • 由客户端决定的授权 — 这是经典的厚客户端漏洞:UI 会隐藏用户无权执行的操作,但后端只根据身份进行授权。测试操作,而不是按钮。

更新通道和 DLL 加载

  • 更新完整性 — 如果应用通过 HTTP 获取更新,或通过 HTTPS 获取更新但不验证签名,那么更新通道就是代码执行路径。检查更新程序如何验证它安装的内容。
  • DLL 搜索顺序劫持 — 如果应用从搜索路径上的可写目录加载缺失的 DLL,就能在应用的上下文中本地执行代码;枚举应用的导入项和加载路径。

范围和授权

厚客户端的后端属于生产基础设施,因此适用与任何网络测试相同的范围和授权规则——你可以自由进行本地分析,但客户端发送的任何内容都会到达客户的系统。

对于双层架构的情况,需要明确告知客户:提取数据库连接字符串会带来直接且通常具有高权限的数据库访问,绕过应用层原本会强制执行的所有控制。应通过演示访问来证明发现的问题;不要在生产数据中四处翻找,超出展示影响所需的范围,并将此事记录在项目的访问清单中(maintaining-engagement-state)。

应当驳斥的借口

  • “Burp 看不到流量,所以没什么可测的。” 客户端不支持代理,或者使用的协议不是 HTTP。强制流量经过代理或 Hook 进程;流量确实存在。
  • “配置文件里的秘密是加密的。” 如果密钥随二进制文件一起发布,那是混淆,不是加密。提取密钥并读取内容。
  • “管理员功能是灰色的,所以受到了保护。” 客户端控制不等于授权。修改它,并检查服务器是否会重新强制执行——这就是需要报告的发现。
  • “这是桌面应用,无法触及后端。” 双层应用会向你提供数据库凭据。别先假定数据层安全,先查找连接字符串。
  • “仅影响本地的问题严重性较低。” 安装权限 ACL 薄弱、DLL 劫持和未签名更新程序,都是本地代码执行和权限提升路径,不是表面问题。

参考资料

  • testing-web-applications — 三层客户端的后端 API 攻击面
  • analyzing-dotnet-assemblies — 反编译托管 .NET 客户端
  • reversing-obfuscated-javascript — Electron 应用程序包
  • exploiting-memory-corruption — 原生客户端存在内存漏洞时
  • maintaining-engagement-state — 记录提取的数据库访问权限和凭据

评论

支持 Markdown