文档教程网络安全【免费下载链接】mastgThe OWASP Mobile Application Security Testing Guide (MASTG) is a comprehensive manual for mobile app security testing and reverse engineering. It describes technical processes for verifying the OWASP Mobile Security Weakness Enumeration (MASWE) weaknesses, which are in alignment with the OWASP MASVS.项目地址https://gitcode.com/gh_mirrors/ow/mastg点击查看免费下载本文基于 OWASP MASTGMobile Application Security Testing Guide测试用例 MASTG-TEST-0217 展开讲解如何在 Android 应用中通过逆向 静态分析的方式定位代码里显式启用不安全 TLS 版本SSLv3、TLS 1.0/1.1 等的两类典型入口Java 网络栈SSLContext/SSLSocket与第三方网络库如 OkHttp 的ConnectionSpec。读完本篇你可以掌握一套可直接落地的检索模式、观察与判定标准并理解该静态测试与动态流量验证测试之间的互补关系与边界。一、测试定位与背景该测试用例的元数据Front Matter明确了它的定位测试编号MASTG-TEST-0217标题为Insecure TLS Protocols Explicitly Allowed in Code测试类型[static, code]即纯静态分析、针对代码对应弱点MASWE-0026不安全/未加密的网络通信。在动手之前需要先理解一个 Android 平台层面的关键事实它直接决定了这个测试为什么以代码为检索对象Android 的网络安全配置Network Security Configuration, NSC并不提供对具体 TLS 版本的直接控制。这与 iOS 不同——iOS 可以在 Info.plist 中通过NSExceptionMinimumTLSVersion之类的键显式设定最低 TLS 版本。因此在 Android 上一个应用允许哪些 TLS 版本这件事主要落在应用自身的代码或其所依赖的网络库层面。自 Android 10API level 29起TLS 1.3 默认为所有 TLS 连接启用这是 MASTG 文档 Document/0x04f-Testing-Network-Communication.md 中Recommended TLS Settings一节给出的平台基线。因此平台默认本身不是问题问题在于应用代码是否主动放宽了这一基线。结合该章节对协议版本的基线判断SSL 已废弃TLS 1.0 与 TLS 1.1 存在已知漏洞且已被各大浏览器弃用TLS 1.2 与 TLS 1.3 才是安全传输的最佳实践可以得出本测试的核心命题只要应用代码显式启用了 SSL/TLS 1.0/TLS 1.1 这类旧版本或启用了允许回落到旧版本的宽松配置就应判为失败。二、应用代码允许不安全 TLS 的两条路径MASTG-TEST-0217 的 Overview 归纳了应用代码中启用不安全 TLS 版本的几种方式可归为两大类。路径一Java 网络栈Java Sockets这是最直接的一条路径涉及两个 APISSLContext.getInstance(TLSv1.1)。SSLContext.getInstance(String protocol)的参数就是协议名称。传入TLSv1.0、TLSv1.1、SSLv3等参数会直接得到一个基于旧协议的上下文对象后续由其socketFactory创建的 socket 即运行在旧协议之下。这是静态检索时信号最强的命中点——协议字符串通常以字面量形式出现在代码里。javax.net.ssl.SSLSocket.setEnabledProtocols(String[] protocols)。即使上下文是默认的应用也可以对SSLSocket实例直接调用setEnabledProtocols显式设定启用的协议列表。若传入的数组包含TLSv1、TLSv1.1、SSLv3同样构成不安全配置。与之相邻的还有setEnabledCipherSuites一类调用常与协议降级配合出现检索时可一并关注。仓库中的演示代码恰好展示了开发者手动配置SSLContext的典型写法在 demos/android/MASVS-NETWORK/MASTG-DEMO-0054/MastgTest.kt 中示例应用通过val sslContext SSLContext.getInstance(TLS) // MastgTest.kt 第 52 行 sslContext.init(null, trustAllCerts, SecureRandom()) connection.sslSocketFactory sslContext.socketFactory为HttpsURLConnection安装自定义的SSLContext。该示例的演示重点是忽略证书链校验对应 MASVS-NETWORK 的其他测试但它同时说明了一个对本测试很有价值的现象一旦开发者开始手动构造SSLContext协议参数字符串就随之出现在代码中这正是静态扫描要捕捉的目标形态把其中的TLS换成TLSv1.1即构成 MASTG-TEST-0217 所定义的失败情形。同目录下 MASTG-DEMO-0055 也使用了相同的SSLContext.getInstance(TLS)模式可作为检索该模式的更多样例。路径二第三方网络库的宽松 TLS 配置很多应用并不直接使用SSLSocket而是通过 OkHttp、Retrofit 或 Apache HttpClient 等库发起请求。这些库提供了自定义 TLS 协议的配置接口管理不当时就会放宽协议基线。原文档点名了 OkHttp 的两个关键 APIConnectionSpec.COMPATIBLE_TLS这是一个兼容性优先的预设ConnectionSpec。文档指出在部分 OkHttp 版本中使用ConnectionSpec.COMPATIBLE_TLS例如通过okhttp3.ConnectionSpec.Builder.connectionSpecs(...)将其加入客户端的连接规范会导致类似TLS 1.1 这样的旧版本被默认启用。因此即便代码中没有出现任何TLSv1.1字面量仅凭引入了COMPATIBLE_TLS这一允许使用过时 TLS 版本的设置按评估标准也应判为失败。ConnectionSpec.Builder.tlsVersions(...)显式设置连接规范中启用的协议版本数组。传入包含TlsVersion.TLS_1_0、TlsVersion.TLS_1_1的列表即为不安全配置与之相对的安全写法是仅保留TLS_1_2/TLS_1_3。Retrofit 和 Apache HttpClient 同理Retrofit 通常直接委托 OkHttp 的OkHttpClient配置最终仍落到ConnectionSpecApache HttpClient 则可通过SSLContext/协议列表进行类似的定制。检索时应把这三类库的 TLS 相关 API 都纳入范围。三、标准测试流程逆向 静态分析MASTG-TEST-0217 的 Steps 非常简洁引用了两个标准技术页使用 MASTG-TECH-0013 对应用进行逆向工程使用 MASTG-TECH-0014 静态分析查找上述相关 API。下面结合这两个技术页的实际内容把流程展开为可操作的步骤。3.1 获取可分析的代码TECH-0013TECH-0013 指出逆向 Android 应用需要同时处理 Java 字节码与 native 代码并给出了三个落地子技术DEX/代码分析、反编译、native 分析。对本测试而言核心是把 APK 中的 DEX 反编译为近似的 Java 源码。具体做法可参考 MASTG-TECH-0017用 jadx推荐jadx-gui打开 APKjadx-gui UntouchedApp.apkjadx 直接支持.apk输入会自动完成 DEX → JAR → Java 的反编译链路若局部反编译失败可回退到 Bytecode-Viewer聚合六种反编译器或继续用 jadx 的 Fallback 模式。注意事项来自 TECH-0013 本身的告诫应用可能用 JNI 把逻辑藏进 native 层也可能刻意混淆以干扰反编译。对 TLS 配置这类字符串字面量较强的代码混淆通常仍会保留协议字符串如TLSv1.1因此在反编译产物上做文本级检索依然有效但若命中点极少应保持警惕考虑 native 层或动态验证见第五节。3.2 检索不安全 TLS 配置TECH-0014TECH-0014Static Analysis on Android给出的工具建议是grep与 semgrep。按本文档定义的两条路径可以构造如下检索在 jadx 导出的源码目录上执行# 路径一Java 网络栈 —— 协议字面量与显式设定 grep -rn SSLContext.getInstance . grep -rn setEnabledProtocols\|setEnabledCipherSuites . grep -rn TLSv1\.0\|TLSv1\.1\|SSLv3\|SSL . # 路径二第三方库以 OkHttp 为例 grep -rn COMPATIBLE_TLS\|MODERN_TLS . grep -rn tlsVersions(\|connectionSpecs(\|TLS_1_0\|TLS_1_1 . # 补充Apache HttpClient / Retrofit 常见入口 grep -rn setSupportedSSLParameters\|SSLContextBuilder\|setDefaultSSLContext .对于更复杂、需要排除误报的模式TECH-0014 给出的 semgrep 用法该页以SecureRandom固定种子为示例同样适用。沿用其规则风格一个针对setEnabledProtocols含旧协议的规则可写为rules: - id: insecure-tls-protocols-enabled patterns: - pattern: | $SOCKET.setEnabledProtocols($PROTOS) - pattern-either: - pattern: | String[] $PROTOS { TLSv1, TLSv1.0, TLSv1.1, ... }; - pattern: | $SOCKET.setEnabledProtocols(new String[] { ..., TLSv1.1, ... }) message: SSLSocket explicitly enables an insecure TLS version. languages: [java] severity: WARNINGsemgrep 规则为基于 TECH-0014 示例风格的示意写法实际使用时按具体反编译产物微调grep的结果则需人工确认上下文例如String[]常量的定义处。检索时建议同时维护一份安全基线参照SSLContext.getInstance(TLS)、TLSv1.2、TLSv1.3以及 OkHttp 的MODERN_TLS均属于正常/安全取值不应误报需要报告的命中是旧协议字面量与宽松预设如COMPATIBLE_TLS两类。四、观察结果与判定标准观察Observation按原文档要求测试输出应包含上述 API 调用中所有被启用的 TLS 版本的清单——即把SSLContext.getInstance(...)的协议参数、setEnabledProtocols(...)的数组内容、tlsVersions(...)的列表逐一列出并归位到调用点。判定Evaluation满足以下任一条件测试用例即判失败任意不安全 TLS 版本被直接启用。不安全版本的判定基准链接到 Document/0x04f-Testing-Network-Communication.md 的Recommended TLS Settings一节SSL含 SSLv2/SSLv3、TLS 1.0、TLS 1.1 均不达标只有 TLS 1.2 / 1.3 是最佳实践应用启用了任何允许使用过时 TLS 版本的设置文档给出的典型例子是okhttp3.ConnectionSpec.COMPATIBLE_TLS——即使代码中没有出现任何旧协议字符串只要配置本身允许回落到旧版本就应判失败。这一点值得强调本测试的判定对象是代码显式允许的协议集合而不是网络上实际发生的握手。前者是静态、确定性的后者受服务器端配置影响见下文。五、纵深理解静态测试的边界与配套验证5.1 为什么静态结论需要动态校验TLS 版本协商发生在客户端与服务端之间的运行时握手中客户端允许 TLS 1.1不等于实际连接就一定使用 TLS 1.1——若服务端只支持 TLS 1.2/1.3协商结果仍可能是安全版本反之若服务端配置宽松而客户端基线正常静态扫描可能漏掉实际降级。为此MASTG 为同一弱点MASWE-0026配套了动态测试 MASTG-TEST-0218Insecure TLS Protocols in Network Traffic类型[dynamic, network]通过安装应用、抓包并充分遍历业务流程观察实际协商出的 TLS 版本。两份文档的分工非常清晰0217本文回答代码里是否显式放宽了协议基线产出是 API 调用清单与判定0218回答线上流量实际跑在哪个协议上弥补静态分析不完整或不可行时的盲区。此外从测试谱系看旧版目录中的 tests/android/MASVS-NETWORK/MASTG-TEST-0020.mdTesting the TLS Settings已被标记为deprecated其covered_by字段正是[MASTG-TEST-0217, MASTG-TEST-0218]——即 MASTG V2 把测试 TLS 配置这一笼统测试拆分成了静态查代码与动态查流量两个更精确的用例。5.2 与相邻测试的关系与常见混淆在 tests-beta/android/MASVS-NETWORK 目录中围绕SSLSocket与网络安全的静态测试还有几项与本测试容易混淆注意区分判定对象MASTG-TEST-0234MASWE-0027检查使用SSLSocket却缺少HostnameVerifier主机名校验的问题。值得注意的是该测试还指出SSLSocket不受 Network Security Configuration 约束即使 NSC 完全安全裸SSLSocket仍可能被 MITM——这也是代码级问题独立于配置层存在的又一例证MASTG-TEST-0235检查允许明文流量的配置android:usesCleartextTraffic、cleartextTrafficPermitted关注的是是否加密而非加密用了哪个协议版本。本测试0217只针对协议版本这一维度。5.3 静态检索的已知局限综合原文档与仓库上下文静态测试的局限主要来自三方面混淆与字符串加解密若协议字符串被加密或运行时拼出grep级检索会漏报此时应结合反编译后的数据流分析或直接落到 0218 的动态抓包native 层如 TECH-0013 所述应用可能把网络逻辑放进 JNIJava 侧检索不到不代表 native 侧如 BoringSSL/BioTLS 直连没有放宽协议跨平台框架Flutter、React Native 等框架自带 HTTP 栈其 TLS 配置路径与原生 API 不同仓库中 MASTG-TEST-0237 即为这一场景预留的占位测试用本测试的检索模式覆盖不到时不要草率下未发现问题的结论。六、小结MASTG-TEST-0217 给出了一个边界清晰、可执行的静态判定方法因为 Android 的 NSC 不控制 TLS 版本审计者必须直接检查代码——SSLContext.getInstance的协议参数、SSLSocket.setEnabledProtocols的数组内容以及 OkHttpConnectionSpec中的COMPATIBLE_TLS/tlsVersions(...)配置。流程上先按 TECH-0013 完成逆向jadx 反编译再按 TECH-0014 用 grep/semgrep 做模式检索观察结果是被启用 TLS 版本的完整清单判定基准是 0x04f 章节给出的仅 TLS 1.2/1.3 达标。静态结论应与配套的动态流量测试 MASTG-TEST-0218 相互印证才能对不安全 TLS问题给出完整、可辩护的结论。赞分享文档教程网络安全【免费下载链接】mastgThe OWASP Mobile Application Security Testing Guide (MASTG) is a comprehensive manual for mobile app security testing and reverse engineering. It describes technical processes for verifying the OWASP Mobile Security Weakness Enumeration (MASWE) weaknesses, which are in alignment with the OWASP MASVS.项目地址https://gitcode.com/gh_mirrors/ow/mastg点击查看免费下载相关推荐MASTG 实战用 Semgrep 静态检测 Android 不安全的 PendingIntentMASTG-DEMO-0147MASTG 实战用 Semgrep 静态检测 Android 不安全的 PendingIntentMASTG DEMO 0147 导读 本文围绕 OWAS文档教程网络安全猫抓插件完整指南浏览器资源嗅探、下载网页视频与 M3U8 解析一次讲清猫抓插件完整指南浏览器资源嗅探、下载网页视频与 M3U8 解析一次讲清 猫抓Cat Catch是一款免费开源的浏览器资源嗅探扩展它盯着当前页面发出的所有音视频OpCore-Simplify 完整教程把黑苹果 EFI 制作时间从几天压缩到半小时零基础也能跑通OpCore Simplify 完整教程把黑苹果 EFI 制作时间从几天压缩到半小时零基础也能跑通 OpCore Simplify 是一个 Python 命文档教程网络安全上一篇PaddleSpeech Metaverse 虚拟人 Demo 实战用 FastSpeech2 PaddleGAN 让图片人物开口说话下一篇Minimal Mistakes 多图排版实战figure、half/third 响应式布局与图库用法创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考