尧图网站建设 
文档教程网络安全【免费下载链接】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 Mobile Application Security Testing GuideMASTG中MASVS-STORAGE分类下的「用户界面组件User Interface Components」知识条目系统讲解如何检测与防范 Android 应用在用户界面UI中暴露敏感数据的问题。文中不仅继承了 MASTG 对 UI 掩码masking要求、肩窥shoulder surfing风险的核心定义还结合仓库中的相关测试用例MASTG-TEST-0008、MASTG-TEST-0316、键盘缓存知识条目MASTG-KNOW-0055与源码级演示MASTG-DEMO-0064给出从静态审查、动态验证到自动化规则检测的完整实战方案。读完本文你将掌握敏感输入字段的掩码配置方法XML、传统 View 体系、Jetpack Compose 三种写法、inputType位掩码的解码技巧、键盘缓存风险的排查思路以及如何像安全测试工程师一样对 UI 数据泄露做出 PASS/FAIL 判定。一、问题背景UI 中的敏感数据为什么需要掩码MASTG-KNOW-0052 指出在某些时间点用户必然需要在应用中输入敏感信息。这些数据可能是信用卡号、用户账户密码等金融信息也可能是医疗健康数据。如果应用在输入过程中没有对数据进行适当的掩码处理这些数据就可能暴露在屏幕上。具体风险被称为肩窥shoulder surfing——攻击者在用户身后或通过摄像头直接观察屏幕上以明文显示clear text的密码、PIN、验证码等敏感输入。MASTG 对该问题的安全要求非常明确除非确实需要例如正在输入密码的瞬间不得通过用户界面暴露任何敏感数据对于必须在界面上呈现的数据应当进行恰当的掩码masked典型做法是用星号asterisks或圆点dots替代明文。这正是 MASVS-STORAGE 分类关注 UI 组件的原因数据泄露不一定只发生在存储层或网络层屏幕上的一次明文回显同样是一次数据泄露事件。与之对应的旧版测试项 MSTG-STORAGE-7MASTG-TEST-0008就是专门用于「检查通过用户界面泄露敏感数据」的。二、检测方法总览静态分析与动态分析MASTG 对 UI 敏感数据泄露的检测遵循「先静态后动态」的两段式流程这在 MASTG-TEST-0008 与新版测试 MASTG-TEST-0316 中有完整体现。2.1 静态分析审查所有相关 UI 组件静态阶段需要仔细审查所有展示敏感信息或接收敏感输入的 UI 组件搜索任何敏感信息的痕迹并评估它应当被掩码还是被完全移除。重点检查对象有两类文本输入字段Text Fields确认EditText是否正确配置掩码属性详见第三节应用通知App Notifications在静态评估时建议搜索NotificationManager类的使用它可能是某种通知管理行为的迹象。如果使用了该类下一步需要理解应用是如何生成通知的。这些代码位置可以反馈给动态分析环节帮助定位应用内可能动态生成通知的位置。2.2 动态分析运行应用并触发所有路径动态阶段的目标是运行应用找出所有可能泄露信息的组件对文本字段如果信息被掩码例如输入被替换为星号或圆点则应用没有向用户界面泄露数据对通知需要遍历整个应用及其所有可用功能寻找触发通知的方式。注意某些通知可能需要你在应用之外执行操作才能触发例如服务器推送。在运行应用期间可以跟踪所有与通知创建相关的函数调用例如NotificationCompat.Builder的setContentTitle、setContentText。观察最终的调用轨迹评估其中是否包含敏感信息。三、文本输入字段的掩码三种实现方式在 Android 中让输入字段显示圆点而非明文的核心手段是配置inputType。MASTG 测试明确给出了三种主流写法。3.1 XML 布局方式传统 View 体系在布局文件中为EditText设置android:inputType属性。最经典的值是textPassword它会令字段以圆点dots显示输入字符从而防止应用把密码或 PIN 明文泄露到界面EditText android:idid/password android:layout_widthmatch_parent android:layout_heightwrap_content android:hintstring/password_hint android:inputTypetextPassword /该示例取自 MASTG-KNOW-0055 中「XML Layouts」小节MASTG-TEST-0316 对 XML 视图的检测同样以此为判据EditText android:inputTypetextPassword ... /3.2 程序化设置Kotlin/Java 代码在代码中动态创建输入字段时可以通过setInputType方法或直接给inputType属性赋值。例如在 Kotlin 中创建一个掩码的 PIN 输入框val input EditText(context).apply { hint Enter PIN inputType InputType.TYPE_CLASS_NUMBER or InputType.TYPE_NUMBER_VARIATION_PASSWORD }这里TYPE_CLASS_NUMBER声明数字输入类别TYPE_NUMBER_VARIATION_PASSWORD声明密码变体两者按位或组合后即得到与 XML 中numberPassword等价的效果。3.3 Jetpack Compose 方式在 Jetpack Compose 中不再直接使用EditText而是使用TextField/OutlinedTextField等可组合函数配合keyboardOptions与visualTransformation参数实现同等行为。MASTG-KNOW-0055 给出的密码字段示例OutlinedTextField( value password, onValueChange { password it }, label { Text(Enter Password) }, visualTransformation PasswordVisualTransformation(), keyboardOptions KeyboardOptions( keyboardType KeyboardType.Password, autoCorrect false ), modifier Modifier.fillMaxWidth() )其中PasswordVisualTransformation()负责掩码输入KeyboardOptions中的KeyboardType.Password指定密码输入类型autoCorrect false关闭自动更正防止输入联想缓存。此外新版测试 MASTG-TEST-0316 特别提及 Jetpack Compose 中更专门的SecureTextField组件它通过TextObfuscationMode控制掩码行为默认值是TextObfuscationMode.RevealLastTyped仅回显最后输入的字符因此开发者不显式设置也能获得基本掩码SecureTextField( // textObfuscationMode defaults to TextObfuscationMode.RevealLastTyped textObfuscationMode TextObfuscationMode.RevealLastTyped, // or TextObfuscationMode.Hidden ... )需要特别警惕的是即便SecureTextField使用默认的RevealLastTyped或被显式配置为RevealLastTyped/Hidden后续仍可在代码中被程序化改为Visible——这恰恰是 MASTG-TEST-0316 评价阶段重点排查的失败场景之一。四、深入原理inputType 位掩码与逆向解码要判断一个字段是否真正做到了掩码安全测试者通常面对的是反编译后的代码——此时inputType已变成一串数字如129、18。MASTG-KNOW-0055 对此给出了完整的解码方法论。4.1 inputType 的构成Android 的inputType属性是类Class、变体Variation、标志Flag三类常量的按位组合类常量TYPE_CLASS_*定义输入类型大类文本、数字、电话等变体常量TYPE_TEXT_VARIATION_*等定义具体行为密码、邮箱、URI 等标志常量TYPE_TEXT_FLAG_*附加修饰禁止联想、多行等。例如inputType InputType.TYPE_CLASS_TEXT or InputType.TYPE_TEXT_VARIATION_PASSWORD其中TYPE_CLASS_TEXT 1、TYPE_TEXT_VARIATION_PASSWORD 128组合结果1 or 128 129——这就是你在反编译代码中看到的数值。4.2 常用非缓存/掩码输入类型一览无论采用哪种实现方式MASTG 认可的、能禁用联想并阻止缓存的inputType取值如下表引用自 MASTG-KNOW-0055 与旧版 MASTG-TEST-0006XMLandroid:inputType代码InputType常量最低 API 级别textNoSuggestionsTYPE_TEXT_FLAG_NO_SUGGESTIONS3textPasswordTYPE_TEXT_VARIATION_PASSWORD3textVisiblePasswordTYPE_TEXT_VARIATION_VISIBLE_PASSWORD3numberPasswordTYPE_NUMBER_VARIATION_PASSWORD11textWebPasswordTYPE_TEXT_VARIATION_WEB_PASSWORD11关于 minSdkVersion 的注意事项旧版测试MASTG-TEST-0006要求检查 AndroidManifest 中的android:minSdkVersion是否支持所用常量例如textWebPassword需要 API 11否则编译产物不会遵循这些输入类型常量键盘缓存将重新生效。而 MASTG 新版测试明确表示不再检查minSdkVersion因为测试对象被假定为现代应用——如果你在测试较老的应用则仍应做此核查见 MASTG-TEST-0258。4.3 反编译数值的快速解码MASTG-KNOW-0055 给出三组掩码用按位与即可拆分inputType的数值TYPE_MASK_CLASS0x0000000F提取类部分TYPE_MASK_VARIATION0x00000FF0提取变体部分TYPE_MASK_FLAGS0x00FFF000提取标志部分例如用 Python 快速验证129 0x0000000F # 1 (TYPE_CLASS_TEXT) 129 0x00000FF0 # 128 (TYPE_TEXT_VARIATION_PASSWORD)五、实战演示MASTG-DEMO-0064 的 PASS/FAIL 判定仓库中的演示项目 MASTG-DEMO-0064 完整展示了如何用 semgrep 规则自动化检测键盘缓存风险其样例源码 MastgTest.kt 是理解inputType数值与掩码逻辑的绝佳教材。5.1 样例代码中的三个字段showPopup方法创建一个弹窗内含三个EditText输入字段passwordTYPE_CLASS_TEXT or TYPE_TEXT_VARIATION_PASSWORD→ 正确密码不应被缓存passphrase仅TYPE_CLASS_TEXT→ 错误明文文本类输入允许缓存PIN初始为TYPE_CLASS_NUMBER or TYPE_NUMBER_VARIATION_PASSWORD但紧接着又被input3.inputType InputType.TYPE_CLASS_NUMBER覆盖 → 错误覆盖后变为可缓存类型。5.2 semgrep 规则与输出解码演示使用MASTG-TOOL-0110semgrep并配合仓库规则 rules/mastg-android-keyboard-cache-input-types.yml 运行规则捕获每一个setInputType调用及其参数。检测输出包含行号、反编译后的对象名、方法名与输入类型数值。随后按位解码(PASS)129129 0x0000000F 1TYPE_CLASS_TEXT、129 0x00000FF0 128TYPE_TEXT_VARIATION_PASSWORD阻止密码缓存正确(FAIL)1仅TYPE_CLASS_TEXT明文文本允许缓存。正确值应为129(FAIL)input3先为1818 0x0000000F 2即TYPE_CLASS_NUMBER18 0x00000FF0 16即TYPE_NUMBER_VARIATION_PASSWORD本应正确但反编译代码中存在第二次setInputType(2)2 0x0000000F 2TYPE_CLASS_NUMBER属于可缓存类型因此判定失败。这个例子揭示了两点实战要点一是反向工程中必须检查同一字段是否存在多次setInputType覆盖二是数值解码是判断掩码是否真正生效的唯一可靠手段。5.3 查找已被缓存的键盘数据如果应用没有正确禁用缓存攻击者或测试者可以直接从输入法缓存数据库中找回用户曾输入的敏感字符串。MASTG-KNOW-0055 给出了验证方法在 passphrase 字段中多次输入某个测试字符串例如 OWASPMAS随后adb shell strings /data/data/com.google.android.inputmethod.latin/databases/trainingcachev3.db | grep -i OWASPMAS OWASPMAS OWASPMAS OWASPMAS%能在缓存数据库中检索到明文输入即证明键盘缓存未被正确禁用。该技巧在动态分析阶段可快速确认应用是否存在 UI 输入层面的敏感数据留存。六、新版测试体系MASTG-TEST-0316 的完整流程旧版测试 MSTG-STORAGE-7MASTG-TEST-0008已在 MASTG V2 中弃用由新版测试 MASTG-TEST-0316App Exposing User Authentication Data in Text Input Fields取代并与键盘缓存测试 MASTG-TEST-0258 形成互补。MASTG-TEST-0316 的完整流程如下测试目标验证应用是否正确处理用户输入确保访问码密码或 PIN与验证码OTP不在文本输入字段中以明文暴露。执行步骤使用 MASTG-TECH-0013 对应用进行逆向工程使用 MASTG-TECH-0014 查找相关 API 的调用位置。观察输出应得到一份「所有用于访问码或验证码的文本输入字段位置」清单。评价标准若发现任何用于访问码/验证码的输入字段未掩码测试失败。典型失败原因包括使用了普通的TextFieldCompose 中无掩码的可组合函数使用了SecureTextField但配置为TextObfuscationMode.Visible。进一步验证由于「哪些字段处理访问码或验证码」取决于上下文需使用 MASTG-TECH-0023 逐一检查每个报告的位置确认字段是否处理敏感数据以及是否被正确掩码。预期的漏报False Negatives如果应用使用不依赖标准类如TextField、SecureTextField的自定义文本输入控件例如自定义 UI 框架或游戏引擎中的输入组件本测试可能产生漏报——这类场景需要人工补充验证。与之配套的键盘缓存测试 MASTG-TEST-0258引用知识条目 MASTG-KNOW-0055 与最佳实践 MASTG-BEST-0019则从另一角度验证应用是否通过inputType正确配置输入字段防止键盘缓存密码或个人数据等敏感信息。其检查点包括布局文件res/layout中的android:inputTypeXML 属性、代码中setInputType方法的调用、以及 Jetpack Compose 中KeyboardOptions的keyboardType与autoCorrect参数。七、审计清单快速核查要点结合上述文档与源码一次完整的 Android UI 敏感数据掩码审计应覆盖以下核查点输入字段所有接收密码、PIN、OTP、信用卡号、身份证号的EditText/ Compose 字段是否设置了textPassword/numberPassword/textWebPassword等掩码类型Compose 是否使用PasswordVisualTransformation或SecureTextField且TextObfuscationMode未被程序化改为Visible。覆盖检查反向工程中逐一确认同一字段不存在后续setInputType/inputType覆写参考 MASTG-DEMO-0064 中 PIN 字段被二次赋值的失败案例。键盘缓存敏感字段是否使用非缓存输入类型表见第四节可借助 rules/mastg-android-keyboard-cache-input-types.yml 规则批量扫描并用adb shell strings抽查输入法缓存数据库。通知应用是否通过NotificationManager/NotificationCompat.Builder在通知标题或正文中暴露敏感明文检查setContentTitle、setContentText。minSdkVersion若测试老应用确认所用输入类型常量与android:minSdkVersion匹配textWebPassword、numberPassword需要 API 11。八、总结MASTG 对用户界面组件的要求可归结为一句话敏感数据在界面上要么不出现出现了就必须掩码。从 MASTG-KNOW-0052 的风险定义出发本文串联了旧版测试 MASTG-TEST-0008 的静态/动态方法论、新版测试 MASTG-TEST-0316 的完整流程、MASTG-KNOW-0055 的位掩码解码原理以及 MASTG-DEMO-0064 的自动化检测实例。在实际测试中建议将掩码检查MASTG-TEST-0316与键盘缓存检查MASTG-TEST-0258配合执行前者回答「明文是否可见」后者回答「输入历史是否被留存」二者共同覆盖 UI 层敏感数据泄露的两个主要面从而完整对齐 MASVS-STORAGE 的安全目标。赞分享文档教程网络安全【免费下载链接】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 MASTG 最佳实践防止 Android 通知中的敏感数据泄露MASTG-BEST-0027OWASP MASTG 最佳实践防止 Android 通知中的敏感数据泄露MASTG BEST 0027 本指南基于 OWASP Mobile Appli文档教程网络安全OWASP MASTG 实践指南彻底移除 Android 应用日志代码防止敏感数据泄露OWASP MASTG 实践指南彻底移除 Android 应用日志代码防止敏感数据泄露 导读 本指南以 OWASP Mobile Application S文档教程网络安全OWASP MASTG 实战Android 内部存储明文敏感数据检测MASTG-DEMO-0010 / MASTG-TEST-0207OWASP MASTG 实战Android 内部存储明文敏感数据检测MASTG DEMO 0010 / MASTG TEST 0207 导读 本文以 OW文档教程网络安全上一篇PinchTab 安全与信任模型本地沙箱化浏览器自动化工具的完整安全指南下一篇抖音无水印视频下载器5分钟快速上手免费批量下载神器创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 OWASP MASTG 实战：Android 用户界面组件中的敏感数据掩码与防泄漏检测指南
文档教程网络安全【免费下载链接】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 Mobile Application Security Testing GuideMASTG中MASVS-STORAGE分类下的「用户界面组件User Interface Components」知识条目系统讲解如何检测与防范 Android 应用在用户界面UI中暴露敏感数据的问题。文中不仅继承了 MASTG 对 UI 掩码masking要求、肩窥shoulder surfing风险的核心定义还结合仓库中的相关测试用例MASTG-TEST-0008、MASTG-TEST-0316、键盘缓存知识条目MASTG-KNOW-0055与源码级演示MASTG-DEMO-0064给出从静态审查、动态验证到自动化规则检测的完整实战方案。读完本文你将掌握敏感输入字段的掩码配置方法XML、传统 View 体系、Jetpack Compose 三种写法、inputType位掩码的解码技巧、键盘缓存风险的排查思路以及如何像安全测试工程师一样对 UI 数据泄露做出 PASS/FAIL 判定。一、问题背景UI 中的敏感数据为什么需要掩码MASTG-KNOW-0052 指出在某些时间点用户必然需要在应用中输入敏感信息。这些数据可能是信用卡号、用户账户密码等金融信息也可能是医疗健康数据。如果应用在输入过程中没有对数据进行适当的掩码处理这些数据就可能暴露在屏幕上。具体风险被称为肩窥shoulder surfing——攻击者在用户身后或通过摄像头直接观察屏幕上以明文显示clear text的密码、PIN、验证码等敏感输入。MASTG 对该问题的安全要求非常明确除非确实需要例如正在输入密码的瞬间不得通过用户界面暴露任何敏感数据对于必须在界面上呈现的数据应当进行恰当的掩码masked典型做法是用星号asterisks或圆点dots替代明文。这正是 MASVS-STORAGE 分类关注 UI 组件的原因数据泄露不一定只发生在存储层或网络层屏幕上的一次明文回显同样是一次数据泄露事件。与之对应的旧版测试项 MSTG-STORAGE-7MASTG-TEST-0008就是专门用于「检查通过用户界面泄露敏感数据」的。二、检测方法总览静态分析与动态分析MASTG 对 UI 敏感数据泄露的检测遵循「先静态后动态」的两段式流程这在 MASTG-TEST-0008 与新版测试 MASTG-TEST-0316 中有完整体现。2.1 静态分析审查所有相关 UI 组件静态阶段需要仔细审查所有展示敏感信息或接收敏感输入的 UI 组件搜索任何敏感信息的痕迹并评估它应当被掩码还是被完全移除。重点检查对象有两类文本输入字段Text Fields确认EditText是否正确配置掩码属性详见第三节应用通知App Notifications在静态评估时建议搜索NotificationManager类的使用它可能是某种通知管理行为的迹象。如果使用了该类下一步需要理解应用是如何生成通知的。这些代码位置可以反馈给动态分析环节帮助定位应用内可能动态生成通知的位置。2.2 动态分析运行应用并触发所有路径动态阶段的目标是运行应用找出所有可能泄露信息的组件对文本字段如果信息被掩码例如输入被替换为星号或圆点则应用没有向用户界面泄露数据对通知需要遍历整个应用及其所有可用功能寻找触发通知的方式。注意某些通知可能需要你在应用之外执行操作才能触发例如服务器推送。在运行应用期间可以跟踪所有与通知创建相关的函数调用例如NotificationCompat.Builder的setContentTitle、setContentText。观察最终的调用轨迹评估其中是否包含敏感信息。三、文本输入字段的掩码三种实现方式在 Android 中让输入字段显示圆点而非明文的核心手段是配置inputType。MASTG 测试明确给出了三种主流写法。3.1 XML 布局方式传统 View 体系在布局文件中为EditText设置android:inputType属性。最经典的值是textPassword它会令字段以圆点dots显示输入字符从而防止应用把密码或 PIN 明文泄露到界面EditText android:idid/password android:layout_widthmatch_parent android:layout_heightwrap_content android:hintstring/password_hint android:inputTypetextPassword /该示例取自 MASTG-KNOW-0055 中「XML Layouts」小节MASTG-TEST-0316 对 XML 视图的检测同样以此为判据EditText android:inputTypetextPassword ... /3.2 程序化设置Kotlin/Java 代码在代码中动态创建输入字段时可以通过setInputType方法或直接给inputType属性赋值。例如在 Kotlin 中创建一个掩码的 PIN 输入框val input EditText(context).apply { hint Enter PIN inputType InputType.TYPE_CLASS_NUMBER or InputType.TYPE_NUMBER_VARIATION_PASSWORD }这里TYPE_CLASS_NUMBER声明数字输入类别TYPE_NUMBER_VARIATION_PASSWORD声明密码变体两者按位或组合后即得到与 XML 中numberPassword等价的效果。3.3 Jetpack Compose 方式在 Jetpack Compose 中不再直接使用EditText而是使用TextField/OutlinedTextField等可组合函数配合keyboardOptions与visualTransformation参数实现同等行为。MASTG-KNOW-0055 给出的密码字段示例OutlinedTextField( value password, onValueChange { password it }, label { Text(Enter Password) }, visualTransformation PasswordVisualTransformation(), keyboardOptions KeyboardOptions( keyboardType KeyboardType.Password, autoCorrect false ), modifier Modifier.fillMaxWidth() )其中PasswordVisualTransformation()负责掩码输入KeyboardOptions中的KeyboardType.Password指定密码输入类型autoCorrect false关闭自动更正防止输入联想缓存。此外新版测试 MASTG-TEST-0316 特别提及 Jetpack Compose 中更专门的SecureTextField组件它通过TextObfuscationMode控制掩码行为默认值是TextObfuscationMode.RevealLastTyped仅回显最后输入的字符因此开发者不显式设置也能获得基本掩码SecureTextField( // textObfuscationMode defaults to TextObfuscationMode.RevealLastTyped textObfuscationMode TextObfuscationMode.RevealLastTyped, // or TextObfuscationMode.Hidden ... )需要特别警惕的是即便SecureTextField使用默认的RevealLastTyped或被显式配置为RevealLastTyped/Hidden后续仍可在代码中被程序化改为Visible——这恰恰是 MASTG-TEST-0316 评价阶段重点排查的失败场景之一。四、深入原理inputType 位掩码与逆向解码要判断一个字段是否真正做到了掩码安全测试者通常面对的是反编译后的代码——此时inputType已变成一串数字如129、18。MASTG-KNOW-0055 对此给出了完整的解码方法论。4.1 inputType 的构成Android 的inputType属性是类Class、变体Variation、标志Flag三类常量的按位组合类常量TYPE_CLASS_*定义输入类型大类文本、数字、电话等变体常量TYPE_TEXT_VARIATION_*等定义具体行为密码、邮箱、URI 等标志常量TYPE_TEXT_FLAG_*附加修饰禁止联想、多行等。例如inputType InputType.TYPE_CLASS_TEXT or InputType.TYPE_TEXT_VARIATION_PASSWORD其中TYPE_CLASS_TEXT 1、TYPE_TEXT_VARIATION_PASSWORD 128组合结果1 or 128 129——这就是你在反编译代码中看到的数值。4.2 常用非缓存/掩码输入类型一览无论采用哪种实现方式MASTG 认可的、能禁用联想并阻止缓存的inputType取值如下表引用自 MASTG-KNOW-0055 与旧版 MASTG-TEST-0006XMLandroid:inputType代码InputType常量最低 API 级别textNoSuggestionsTYPE_TEXT_FLAG_NO_SUGGESTIONS3textPasswordTYPE_TEXT_VARIATION_PASSWORD3textVisiblePasswordTYPE_TEXT_VARIATION_VISIBLE_PASSWORD3numberPasswordTYPE_NUMBER_VARIATION_PASSWORD11textWebPasswordTYPE_TEXT_VARIATION_WEB_PASSWORD11关于 minSdkVersion 的注意事项旧版测试MASTG-TEST-0006要求检查 AndroidManifest 中的android:minSdkVersion是否支持所用常量例如textWebPassword需要 API 11否则编译产物不会遵循这些输入类型常量键盘缓存将重新生效。而 MASTG 新版测试明确表示不再检查minSdkVersion因为测试对象被假定为现代应用——如果你在测试较老的应用则仍应做此核查见 MASTG-TEST-0258。4.3 反编译数值的快速解码MASTG-KNOW-0055 给出三组掩码用按位与即可拆分inputType的数值TYPE_MASK_CLASS0x0000000F提取类部分TYPE_MASK_VARIATION0x00000FF0提取变体部分TYPE_MASK_FLAGS0x00FFF000提取标志部分例如用 Python 快速验证129 0x0000000F # 1 (TYPE_CLASS_TEXT) 129 0x00000FF0 # 128 (TYPE_TEXT_VARIATION_PASSWORD)五、实战演示MASTG-DEMO-0064 的 PASS/FAIL 判定仓库中的演示项目 MASTG-DEMO-0064 完整展示了如何用 semgrep 规则自动化检测键盘缓存风险其样例源码 MastgTest.kt 是理解inputType数值与掩码逻辑的绝佳教材。5.1 样例代码中的三个字段showPopup方法创建一个弹窗内含三个EditText输入字段passwordTYPE_CLASS_TEXT or TYPE_TEXT_VARIATION_PASSWORD→ 正确密码不应被缓存passphrase仅TYPE_CLASS_TEXT→ 错误明文文本类输入允许缓存PIN初始为TYPE_CLASS_NUMBER or TYPE_NUMBER_VARIATION_PASSWORD但紧接着又被input3.inputType InputType.TYPE_CLASS_NUMBER覆盖 → 错误覆盖后变为可缓存类型。5.2 semgrep 规则与输出解码演示使用MASTG-TOOL-0110semgrep并配合仓库规则 rules/mastg-android-keyboard-cache-input-types.yml 运行规则捕获每一个setInputType调用及其参数。检测输出包含行号、反编译后的对象名、方法名与输入类型数值。随后按位解码(PASS)129129 0x0000000F 1TYPE_CLASS_TEXT、129 0x00000FF0 128TYPE_TEXT_VARIATION_PASSWORD阻止密码缓存正确(FAIL)1仅TYPE_CLASS_TEXT明文文本允许缓存。正确值应为129(FAIL)input3先为1818 0x0000000F 2即TYPE_CLASS_NUMBER18 0x00000FF0 16即TYPE_NUMBER_VARIATION_PASSWORD本应正确但反编译代码中存在第二次setInputType(2)2 0x0000000F 2TYPE_CLASS_NUMBER属于可缓存类型因此判定失败。这个例子揭示了两点实战要点一是反向工程中必须检查同一字段是否存在多次setInputType覆盖二是数值解码是判断掩码是否真正生效的唯一可靠手段。5.3 查找已被缓存的键盘数据如果应用没有正确禁用缓存攻击者或测试者可以直接从输入法缓存数据库中找回用户曾输入的敏感字符串。MASTG-KNOW-0055 给出了验证方法在 passphrase 字段中多次输入某个测试字符串例如 OWASPMAS随后adb shell strings /data/data/com.google.android.inputmethod.latin/databases/trainingcachev3.db | grep -i OWASPMAS OWASPMAS OWASPMAS OWASPMAS%能在缓存数据库中检索到明文输入即证明键盘缓存未被正确禁用。该技巧在动态分析阶段可快速确认应用是否存在 UI 输入层面的敏感数据留存。六、新版测试体系MASTG-TEST-0316 的完整流程旧版测试 MSTG-STORAGE-7MASTG-TEST-0008已在 MASTG V2 中弃用由新版测试 MASTG-TEST-0316App Exposing User Authentication Data in Text Input Fields取代并与键盘缓存测试 MASTG-TEST-0258 形成互补。MASTG-TEST-0316 的完整流程如下测试目标验证应用是否正确处理用户输入确保访问码密码或 PIN与验证码OTP不在文本输入字段中以明文暴露。执行步骤使用 MASTG-TECH-0013 对应用进行逆向工程使用 MASTG-TECH-0014 查找相关 API 的调用位置。观察输出应得到一份「所有用于访问码或验证码的文本输入字段位置」清单。评价标准若发现任何用于访问码/验证码的输入字段未掩码测试失败。典型失败原因包括使用了普通的TextFieldCompose 中无掩码的可组合函数使用了SecureTextField但配置为TextObfuscationMode.Visible。进一步验证由于「哪些字段处理访问码或验证码」取决于上下文需使用 MASTG-TECH-0023 逐一检查每个报告的位置确认字段是否处理敏感数据以及是否被正确掩码。预期的漏报False Negatives如果应用使用不依赖标准类如TextField、SecureTextField的自定义文本输入控件例如自定义 UI 框架或游戏引擎中的输入组件本测试可能产生漏报——这类场景需要人工补充验证。与之配套的键盘缓存测试 MASTG-TEST-0258引用知识条目 MASTG-KNOW-0055 与最佳实践 MASTG-BEST-0019则从另一角度验证应用是否通过inputType正确配置输入字段防止键盘缓存密码或个人数据等敏感信息。其检查点包括布局文件res/layout中的android:inputTypeXML 属性、代码中setInputType方法的调用、以及 Jetpack Compose 中KeyboardOptions的keyboardType与autoCorrect参数。七、审计清单快速核查要点结合上述文档与源码一次完整的 Android UI 敏感数据掩码审计应覆盖以下核查点输入字段所有接收密码、PIN、OTP、信用卡号、身份证号的EditText/ Compose 字段是否设置了textPassword/numberPassword/textWebPassword等掩码类型Compose 是否使用PasswordVisualTransformation或SecureTextField且TextObfuscationMode未被程序化改为Visible。覆盖检查反向工程中逐一确认同一字段不存在后续setInputType/inputType覆写参考 MASTG-DEMO-0064 中 PIN 字段被二次赋值的失败案例。键盘缓存敏感字段是否使用非缓存输入类型表见第四节可借助 rules/mastg-android-keyboard-cache-input-types.yml 规则批量扫描并用adb shell strings抽查输入法缓存数据库。通知应用是否通过NotificationManager/NotificationCompat.Builder在通知标题或正文中暴露敏感明文检查setContentTitle、setContentText。minSdkVersion若测试老应用确认所用输入类型常量与android:minSdkVersion匹配textWebPassword、numberPassword需要 API 11。八、总结MASTG 对用户界面组件的要求可归结为一句话敏感数据在界面上要么不出现出现了就必须掩码。从 MASTG-KNOW-0052 的风险定义出发本文串联了旧版测试 MASTG-TEST-0008 的静态/动态方法论、新版测试 MASTG-TEST-0316 的完整流程、MASTG-KNOW-0055 的位掩码解码原理以及 MASTG-DEMO-0064 的自动化检测实例。在实际测试中建议将掩码检查MASTG-TEST-0316与键盘缓存检查MASTG-TEST-0258配合执行前者回答「明文是否可见」后者回答「输入历史是否被留存」二者共同覆盖 UI 层敏感数据泄露的两个主要面从而完整对齐 MASVS-STORAGE 的安全目标。赞分享文档教程网络安全【免费下载链接】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 MASTG 最佳实践防止 Android 通知中的敏感数据泄露MASTG-BEST-0027OWASP MASTG 最佳实践防止 Android 通知中的敏感数据泄露MASTG BEST 0027 本指南基于 OWASP Mobile Appli文档教程网络安全OWASP MASTG 实践指南彻底移除 Android 应用日志代码防止敏感数据泄露OWASP MASTG 实践指南彻底移除 Android 应用日志代码防止敏感数据泄露 导读 本指南以 OWASP Mobile Application S文档教程网络安全OWASP MASTG 实战Android 内部存储明文敏感数据检测MASTG-DEMO-0010 / MASTG-TEST-0207OWASP MASTG 实战Android 内部存储明文敏感数据检测MASTG DEMO 0010 / MASTG TEST 0207 导读 本文以 OW文档教程网络安全上一篇PinchTab 安全与信任模型本地沙箱化浏览器自动化工具的完整安全指南下一篇抖音无水印视频下载器5分钟快速上手免费批量下载神器创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考