
文档教程网络安全【免费下载链接】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-DEMO-0158 演示样例讲解如何通过 Frida 在运行时动态分析 AndroidWebViewClient对 URL 的拦截与校验行为。你将掌握一套可复用的动态检测方法论识别应用注册的WebViewClient实现、观测shouldOverrideUrlLoading与shouldInterceptRequest的每次调用及返回值、并通过挂钩Uri的 host/scheme/path 访问器来判断处理器是否真正执行了基于主机名的白名单校验。这套方法可用于验证 MASTG-TEST-0400 所要求的动态测试结论并与静态分析MASTG-DEMO-0157形成互补。背景为什么要动态分析 WebView 的 URL 加载Android 应用中的WebView默认行为是把用户点击的链接交给系统浏览器处理。当应用自定义WebViewClient并重写shouldOverrideUrlLoading与shouldInterceptRequest时它就接管了导航决策与资源请求的裁决权。如果这两个处理器没有对 URL 做任何主机名host、协议scheme或路径path层面的白名单校验WebView 就会加载用户被引导到的任何域名内容——这正是开放重定向Open Redirect和加载不可信内容的温床对应 OWASP MASVS-CODE-4WebView 相关代码质量与输入校验及 MASWE-0035 弱点枚举。静态分析Semgrep 规则见 rules/mastg-android-webview-url-handlers.yml可以快速定位setWebViewClient调用和两个被重写的处理器即 MASTG-TEST-0398但它无法证明应用在运行时的真实行为。比如处理器里是否只是做了日志记录还是真的调用了Uri.getHost()之类的校验函数只有动态观测才能给出确凿证据。MASTG-DEMO-0158 提供的正是这样一份运行时证据采集方案。示例应用一个不校验 URL 的 WebViewClient示例应用的核心代码位于 MastgTestWebView.kt该文件与 MASTG-DEMO-0157 共用同一样例实现0157 中还提供了反编译视角的 MastgTestWebView_reversed.javaclass MastgTestWebView(private val context: Context) { fun mastgTest(webView: WebView): String { // Configure WebView settings webView.settings.apply { javaScriptEnabled true } // FAIL: [MASTG-TEST-0398] Custom WebViewClient intercepts URL loading without proper validation webView.webViewClient object : WebViewClient() { override fun shouldOverrideUrlLoading(view: WebView?, request: WebResourceRequest?): Boolean { val url request?.url?.toString() // No URL validation is performed - any URL will be loaded Log.d(MastgTest, Loading URL: $url) return false // Allow the WebView to load the URL } override fun shouldInterceptRequest(view: WebView?, request: WebResourceRequest?): android.webkit.WebResourceResponse? { val url request?.url?.toString() Log.d(MastgTest, Intercepting request: $url) // No validation - allow all requests return super.shouldInterceptRequest(view, request) } } // Load a trusted page initially webView.loadUrl(https://mas.owasp.org/) return WebView configured with custom URL handling } }从源码结构可以确认两处关键事实shouldOverrideUrlLoading只把 URL 转成字符串用于Log.d打印随后固定返回false。在 Android 的WebViewClient语义中返回false表示继续在 WebView 内加载该 URL等于对任何导航不做拦截。shouldInterceptRequest同样只记录日志随后调用super.shouldInterceptRequest(view, request)回退到默认行为对任何资源请求照单全收。两个处理器都从未调用Uri.getHost()、Uri.getScheme()或Uri.getPath()即不存在任何基于主机名的白名单决策逻辑。应用清单文件 AndroidManifest.xml 声明了INTERNET权限入口 Activity 为MainActivityWebView正常联网加载网页是标准的可运行测试靶标。Frida 脚本三个层次的挂钩设计动态测试脚本位于 script.js它一次安装三组 hook分别回答三个问题1. 暴露应用注册的 WebViewClient 及被重写的处理器挂钩WebView.setWebViewClientscript.js在应用调用该方法时立刻通过反射获取client.getClass().getName()并遍历其getDeclaredMethods()凡是出现shouldOverrideUrlLoading或shouldInterceptRequest就标记为自定义 URL 处理。这一步在应用启动时就会触发不需要任何用户交互。WebView.setWebViewClient.implementation function(client) { this.setWebViewClient(client); var cls client.getClass(); console.log(\n[*] setWebViewClient called); console.log( WebViewClient implementation: cls.getName()); var methods cls.getDeclaredMethods(); for (var i 0; i methods.length; i) { var n methods[i].getName(); if (n shouldOverrideUrlLoading || n shouldInterceptRequest) { console.log( [!] Overrides n (custom URL handling)); } } };2. 记录每个 URL 及处理器的返回值分别挂钩WebViewClient.shouldOverrideUrlLoading与shouldInterceptRequest的(WebView, WebResourceRequest)重载script.js。每次调用时读取request.getUrl().toString()调用原实现后打印 URL 与返回值shouldOverrideUrlLoading返回false意味着URL 被加载且未经校验shouldInterceptRequest返回非空WebResourceResponse表示返回了自定义响应返回null即走super默认实现表示默认加载、无校验。3. 追踪处理器执行期间的 URL 结构检查这是整个方法论中最精巧的部分。脚本挂钩Uri.getHost、Uri.getScheme、Uri.getPath三个访问器script.js并引入按线程记账的两张表handlerActive[threadId]标记当前线程是否正在执行某个 URL 处理器inspectionLog[threadId]记录该次执行期间调用了哪些访问器。之所以按线程区分是因为shouldInterceptRequest可能在多个工作线程上并发执行WebView 资源加载线程与主线程混在一起会污染统计。一个真实的 allowlist 校验必然要读取 URL 的 host通常还有 scheme才能做出信任决策。因此如果某次处理器执行期间getHost/getScheme/getPath一个都没有被调用就可以断定该处理器根本没有做基于主机的校验。[getHost, getScheme, getPath].forEach(function(name) { Uri[name].implementation function() { var t tid(); if (handlerActive[t]) { inspectionLog[t].push(name); } return this[name](); }; });执行步骤运行环境要求与操作流程在 MASTG-DEMO-0158.md 中有明确说明这里结合仓库文件给出完整流程安装目标应用将示例 App 安装到设备MASTG-TECH-0005 安装技术确认设备可通过adb访问。准备 Frida 环境在本机安装 Frida CLIMASTG-TOOL-0001并在设备上运行与设备架构匹配的frida-server确保本机与设备间的通信正常。以 spawn 模式启动运行 run.sh#!/bin/bash frida -U -f org.owasp.mastestapp -l script.js -o output.txt命令参数说明-U指定 USB 连接的设备-f org.owasp.mastestapp以 spawn 模式启动该包名应用并在入口处注入脚本-l script.js加载注入脚本-o output.txt将脚本的 console 输出保存到文件。spawn 模式保证了 hook 在setWebViewClient执行之前就已生效。 4.交互触发更多导航可选在 App 界面点击 WebView 中的链接触发shouldOverrideUrlLoading的额外执行路径。 5.结束会话按CtrlC或输入q退出 Frida CLI然后查看output.txt。输出解读仓库自带的运行结果样本 output.txt 展示了典型输出[*] Hooking WebViewClient URL loading handlers... [*] WebViewClient hooks installed successfully [*] setWebViewClient called WebViewClient implementation: org.owasp.mastestapp.MastgTestWebView$mastgTest$2 [!] Overrides shouldInterceptRequest (custom URL handling) [!] Overrides shouldOverrideUrlLoading (custom URL handling) [shouldInterceptRequest] URL: https://mas.owasp.org/ URL inspection during handler: NONE (no host/scheme/path check - no validation) - default loading (no validation)逐段解读WebViewClient implementation: org.owasp.mastestapp.MastgTestWebView$mastgTest$2类名中的$mastgTest$2表明这是一个在mastgTest()方法内部定义的匿名内部类与 MastgTestWebView.kt 中object : WebViewClient()的写法完全对应实现了运行时证据与源码的互相印证。两个[!] Overrides ...行确认该匿名类同时重写了两个 URL 加载处理器攻击面完整暴露。[shouldInterceptRequest] URL: https://mas.owasp.org/这是应用初始loadUrl触发的资源拦截URL 指向官方信任站点。URL inspection during handler: NONE执行期间Uri的 host/scheme/path 访问器一个都没有被调用——处理器没有做任何基于主机名的校验。- default loading (no validation)返回了默认加载行为super.shouldInterceptRequest的null响应资源请求被无条件放行。评估为何判定测试失败综合运行时证据MASTG-TEST-0400 的失败判定成立理由有三个第三方主机资源被无条件放行观察到的每一次shouldInterceptRequest都回退到默认加载行为包括对fonts.googleapis.com、cdn.datatables.net等第三方主机的请求——信任域名列表形同虚设。零 host/scheme/path 检查所有处理器执行期间的URL inspection during handler均报告NONE。由于 allowlist 校验至少必须读取 host 才能做出信任判断这证明处理器根本不存在基于主机的校验决策而非仅仅碰巧没拦截到特定 URL。点击链接时返回false当shouldOverrideUrlLoading被实际触发用户点击链接时返回false意味着用户被引导到的每一个 URL 都会被 WebView 加载开放重定向与任意内容加载的路径完全敞开。由于两个处理器都不做 host/scheme/path 检查WebView 可以从任意主机加载内容可能将用户导向不可信内容或形成开放重定向漏洞。需要强调拦截 URL 加载本身并不天然不安全这也是 MASTG-TEST-0400 的明确立场测试只有在实现未将导航限制在受信任内容时才判失败。方法论的局限与补充验证本技术只能观测到基于 host/scheme/path 的校验模式这覆盖了标准的 allowlist 写法但存在一个已知盲区如果校验是通过对原始 URL 字符串做匹配完成的例如String.contains或直接String.equals本方法检测不到。为此MASTG-DEMO-0158 明确建议与静态分析结合使用 MASTG-DEMO-0157 的 Semgrep 静态扫描规则见 rules/mastg-android-webview-url-handlers.yml定位全部处理器代码对疑似 handler 调用栈可用 MASTG-TECH-0023静态逆向工程检查具体实现确认其校验逻辑是否可靠地把导航限制在受信任域名例如校验完整 host 而非子串匹配。动态证据与静态代码审查双管齐下才能对 WebView 的 URL 处理安全性给出完整、可复查的结论。相关仓库资源演示文档MASTG-DEMO-0158.md示例源码MastgTestWebView.kt、AndroidManifest.xmlFrida 注入脚本script.js、启动脚本 run.sh、运行输出 output.txt动态测试定义MASTG-TEST-0400.md静态分析对照MASTG-DEMO-0157.md、mastg-android-webview-url-handlers.yml赞分享文档教程网络安全【免费下载链接】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点击查看免费下载相关推荐Android 运行时 Hook 检测实战基于 /proc/self/maps 的 Frida 检测与进程终止MASTG-DEMO-0107 深度剖析Android 运行时 Hook 检测实战基于 /proc/self/maps 的 Frida 检测与进程终止MASTG DEMO 0107 深度剖析 本文档教程网络安全大麦自动抢票工具Selenium 与 Appium 双端抢票脚本配置完整指南大麦自动抢票工具Selenium 与 Appium 双端抢票脚本配置完整指南 热门演出开票时从按钮可点到售罄往往只有几秒钟人工依次点击城市、日期、票价、观文档教程网络安全advanced-java 高并发系列为什么使用消息队列解耦、异步、削峰三大核心场景与 Kafka/RabbitMQ/RocketMQ/ActiveMQ 选型对比advanced java 高并发系列为什么使用消息队列解耦、异步、削峰三大核心场景与 Kafka/RabbitMQ/RocketMQ/ActiveMQ 选文档教程网络安全上一篇Minimal Mistakes 主题图片插入完全指南标准图片与 .full 全宽展示的 HTML/Kramdown 双语法实践下一篇NocoBase RunJS ctx.openView() 完整指南以编程方式打开抽屉、弹窗与页面视图创作声明:本文部分内容由AI辅助生成(AIGC),仅供参考