2026年计算机移动应用审计考试题及答案

2026年计算机移动应用审计考试题及答案一、单项选择题（每题2分，共20分）1.移动应用数据处理中“数据最小化原则”的核心要求是：A.收集用户所有可能相关数据B.仅收集实现功能必需的最小数据C.对敏感数据进行加密存储即可D.数据留存时间无明确限制2.以下哪种加密算法更适用于移动应用端用户密码的本地存储保护？A.MD5（无盐值）B.SHA-1（单次哈希）C.PBKDF2（带盐值+迭代）D.AES-128（对称加密）3.根据《移动互联网应用程序个人信息保护管理暂行规定》，应用首次启动时需向用户明示的信息不包括：A.收集的个人信息类型B.信息共享的第三方主体C.开发者公司注册地址D.信息存储的地域范围4.移动应用使用第三方SDK时，审计重点不包括：A.SDK的权限申请是否超出其功能需求B.SDK的版本是否为最新稳定版C.SDK是否存在未声明的网络请求D.SDK开发者的注册资本规模5.针对移动应用的“过度索权”问题，审计时应重点检查：A.应用声明的权限与实际功能的匹配性B.权限申请弹窗的设计美观度C.权限拒绝后应用是否完全退出D.系统权限列表中应用的显示顺序6.移动应用支付功能审计中，“支付信息中间人攻击”的主要防范措施是：A.对支付页面进行UI防篡改检测B.确保支付接口使用HTTPS且证书绑定C.限制单日支付次数D.要求用户输入短信验证码7.以下哪项不属于移动应用性能审计的关键指标？A.应用启动时间（冷启动/热启动）B.后台驻留时的CPU占用率C.用户界面的色彩对比度D.高并发场景下的响应延迟8.移动应用隐私政策审计中，“动态更新”的合规要求是指：A.隐私政策内容需每月更新一次B.更新后需通过弹窗或站内信通知用户C.旧版本用户无需知晓新政策D.政策更新后无需用户重新确认授权9.针对移动应用的“深度伪造（Deepfake）”内容风险，审计应关注：A.用户提供内容的AI鉴伪能力B.应用服务器的负载均衡配置C.开发者的AI算法专利数量D.应用图标是否涉及侵权10.移动应用日志审计的核心目的是：A.记录用户操作习惯用于精准营销B.追踪安全事件的完整操作链路C.统计应用的日活用户数量D.分析界面交互的用户偏好二、简答题（每题8分，共40分）1.简述移动应用数据生命周期审计的关键阶段及各阶段的审计要点。2.列举移动应用使用OAuth2.0授权时常见的安全风险，并提出至少3项审计应对措施。3.说明移动应用“SDK滥用”的主要表现形式，审计时如何验证SDK的合规性？4.移动应用进行大模型（如对话式AI）集成时，需重点审计哪些安全与合规风险？5.对比Android与iOS系统下移动应用权限审计的差异，举例说明典型场景。三、案例分析题（每题15分，共30分）案例1：某电商APP用户投诉称，未主动授权位置信息时，APP首页仍显示“附近门店”；点击“拒绝权限”后，部分商品推荐功能无法使用，但其他核心功能（如搜索、下单）也被限制。审计团队需对该APP进行合规性检查。问题：（1）指出案例中存在的违规行为；（2）提出针对性的审计验证方法；（3）给出整改建议。案例2：某金融类移动应用近期发生多起用户账户盗刷事件，经初步排查，可疑操作均通过APP的“快捷支付”功能完成，且用户未收到短信验证码。审计团队需重点审计该功能的安全机制。问题：（1）分析可能的安全漏洞点；（2）设计审计测试用例验证漏洞；（3）提出加固措施。四、综合应用题（30分）假设你是某科技公司的移动应用审计工程师，需对一款新上线的“智能医疗问诊APP”进行全面审计。该APP功能包括：用户健康数据录入、在线问诊（与医生视频通话）、处方药配送（需上传处方照片）、医保电子凭证调用。要求：（1）制定审计计划（包含阶段划分、时间节点、关键任务）；（2）识别至少8个高风险审计点（涵盖安全、合规、性能维度）；（3）针对其中2个高风险点设计具体的测试方案（需包含测试环境、工具、步骤、预期结果）。答案一、单项选择题1.B（数据最小化原则要求仅收集必要数据，避免过度采集）2.C（PBKDF2通过盐值和迭代次数增强密码存储安全性，优于简单哈希或对称加密）3.C（法规要求明示的信息不包括开发者注册地址，需关注数据类型、共享方、存储地域等）4.D（SDK审计重点是权限、功能匹配性及安全性，与开发者注册资本无关）5.A（过度索权的核心是权限与功能不匹配，而非弹窗设计或权限拒绝后的行为）6.B（HTTPS证书绑定可防止中间人攻击截获支付信息）7.C（色彩对比度属于UI可用性范畴，非性能审计指标）8.B（隐私政策更新需主动通知用户，而非强制更新频率或忽略旧用户）9.A（深度伪造风险需关注内容鉴伪能力，与服务器配置或专利无关）10.B（日志审计核心是追踪安全事件，而非用户行为分析或统计）二、简答题1.数据生命周期审计阶段及要点：（1）收集阶段：审计数据类型与功能的必要性（是否符合最小化）、授权方式（是否明确同意）、收集渠道（是否合法）。（2）存储阶段：检查敏感数据加密方式（如AES-256）、存储位置（本地/云端）、访问权限控制（角色分离）、留存时间（是否超必要）。（3）使用阶段：验证数据用途是否与声明一致（如健康数据仅用于问诊）、跨功能调用的授权（如用户是否同意用于推荐）。（4）共享/传输阶段：审计第三方共享的必要性（是否需用户单独授权）、传输协议（是否TLS1.2+）、数据脱敏情况（如隐藏身份证部分号码）。（5）删除阶段：检查用户删除请求的响应时间（是否15个工作日内）、技术实现（是否物理删除而非逻辑删除）、备份数据的同步删除机制。2.OAuth2.0常见风险及审计措施：风险：（1）授权码泄露（如通过日志记录或未加密传输）；（2）默认使用弱授权类型（如隐式授权模式）；（3）重定向URI未校验（允许任意跳转）；（4）访问令牌过期时间过长（增加被盗用风险）。审计措施：（1）抓包检测授权码是否在HTTP请求中明文传输；（2）检查代码中授权类型配置（优先使用授权码模式）；（3）验证重定向URI白名单机制（是否仅允许注册的域名）；（4）核查令牌过期时间（如设置为1小时内）。3.SDK滥用表现及合规验证：表现形式：（1）超范围申请权限（如天气SDK申请通讯录权限）；（2）未声明的后台数据传输（如统计SDK上传设备IMEI）；（3）嵌套第三方SDK（如广告SDK内置其他未备案SDK）；（4）使用已被通报的高危SDK（如存在代码注入漏洞的旧版本）。合规验证方法：（1）通过反编译工具（如JEB、Hopper）分析APK/IPA包，提取所有SDK标识；（2）使用流量分析工具（Charles、Wireshark）监控SDK的网络请求，比对隐私政策声明的传输内容；（3）检查SDK的《个人信息处理规则》是否独立向用户明示；（4）核查SDK备案情况（通过国家互联网信息办公室移动应用安全管理平台）。4.大模型集成的安全与合规风险：（1）数据泄露风险：用户输入的敏感信息（如病历、银行卡号）可能被大模型缓存或训练使用；（2）模型输出风险：AI提供内容可能包含错误信息（如医疗建议误导用户）、偏见内容（如种族歧视）或侵权内容（如抄袭他人作品）；（3）接口安全风险：大模型API调用未做频率限制（易被刷量）、身份验证薄弱（如使用固定APIKey）；（4）合规风险：提供内容未标注“AI提供”（违反《提供式人工智能服务管理暂行办法》）、训练数据来源未合规（如使用未授权的用户数据）。5.Android与iOS权限审计差异：（1）权限管理机制：Android采用“运行时权限”（需用户主动授权），iOS14+采用“精确权限”（如仅允许一次定位或模糊定位）。审计时需检查Android是否在功能使用前动态申请权限（而非启动时一次性申请），iOS是否提供权限粒度选择（如位置的“仅使用期间”或“精确位置”）。（2）敏感权限范围：Android的“读取通话记录”“访问通讯录”属于危险权限，需单独申请；iOS的“健康数据”“照片”访问需用户授权，且iOS对麦克风、摄像头的使用有状态栏提示（如橙色圆点）。审计iOS时需验证应用使用麦克风时是否触发系统提示，Android需检查危险权限的申请时机是否与功能触发场景一致（如拍照时申请相机权限，而非启动时）。（3）权限拒绝处理：Android应用在权限被拒绝时，需允许用户继续使用非核心功能（如拒绝通讯录权限后仍可使用聊天功能的文字输入）；iOS应用若权限被拒绝，可能直接限制相关功能，但需明确提示用户如何在设置中开启。审计时需测试Android应用在拒绝权限后的功能可用性（如拒绝位置权限后能否使用搜索功能），iOS需检查拒绝权限后的引导提示是否清晰。三、案例分析题案例1答案：（1）违规行为：①未授权时使用位置信息（违反“最小必要”原则）；②拒绝权限后限制非核心功能（违反“权限与功能解耦”要求）。（2）审计验证方法：①通过抓包工具（如PacketCapture）监控APP在拒绝位置权限时的网络请求，检查是否仍发送位置坐标；②手动拒绝位置权限后，测试“附近门店”模块是否隐藏或提示需授权，同时验证搜索、下单等核心功能是否正常使用；③反编译APP代码，检查位置信息调用逻辑（是否在未授权时仍调用系统接口）。（3）整改建议：①调整位置信息触发逻辑，仅在用户主动点击“附近门店”时申请权限；②权限拒绝后，“附近门店”模块显示“需开启位置权限以查看”，但不影响搜索、下单等核心功能；③在隐私政策中明确说明位置信息的使用场景及拒绝权限的影响。案例2答案：（1）可能漏洞点：①快捷支付接口未验证设备指纹（同一账户多设备登录无提醒）；②短信验证码逻辑存在缺陷（如未限制重发次数、验证码明文存储在本地）；③支付请求未做防重放攻击（相同请求可重复提交）；④HTTPS证书未绑定（中间人攻击截获支付信息）。（2）测试用例设计：测试用例1（设备指纹验证）：环境：2台不同手机（设备ID不同），已登录同一账户；工具：Charles（抓包）、自动化测试工具（如Appium）；步骤：在第一台手机发起快捷支付→记录请求参数→在第二台手机使用相同参数重放请求；预期结果：第二台手机请求应被拒绝，并触发“异地登录提醒”。测试用例2（短信验证码逻辑）：环境：模拟器（可拦截短信）、被测APP；工具：AndroidStudio（模拟短信接收）、BurpSuite（修改请求）；步骤：发起支付→获取短信验证码→在支付请求中修改验证码为错误值→重复提交同一验证码（超过3次）；预期结果：错误验证码应提示“验证失败”，重复提交同一验证码应提示“验证码已失效”。（3）加固措施：①增加设备指纹校验（结合IMEI、MAC地址提供唯一标识）；②短信验证码设置有效时间（如5分钟）和错误重试限制（如3次）；③支付请求添加时间戳和随机数（防止重放攻击）；④启用证书双向绑定（APP端预存服务器公钥，验证响应证书）。四、综合应用题（1）审计计划：阶段时间节点关键任务准备阶段第1-2天收集资料（隐私政策、功能说明、第三方SDK清单）；制定审计清单（安全/合规/性能）；搭建测试环境（Android/iOS真机、模拟器、抓包工具）合规审计第3-5天检查个人信息收集（是否最小化）、权限申请（与功能匹配）、隐私政策（是否明示共享方、存储方式）、SDK合规（备案情况、权限使用）安全审计第6-8天测试数据加密（本地存储/传输）、支付功能（防篡改/中间人攻击）、视频通话（音视频加密）、处方上传（防伪造）、医保接口（身份验证）性能审计第9-10天测试启动时间（冷/热启动）、高并发下单（响应延迟）、视频通话卡顿率、后台驻留（CPU/内存占用）报告阶段第11天整理问题清单（高/中/低风险）；提出整改建议；出具审计报告（2）高风险审计点（8个）：①健康数据收集：是否超范围（如收集与问诊无关的基因信息）；②视频通话安全：音视频流是否加密（如是否使用SRTP）、是否存在中间人攻击风险；③处方上传鉴伪：是否具备OCR识别+人工审核双重机制，防止伪造处方；④医保接口安全：调用医保电子凭证时是否验证用户生物信息（如人脸）、是否存在接口越权；⑤SDK合规：统计SDK是否上传用户健康数据（未声明）、广告SDK是否超范围申请权限；⑥数据存储安全：本地存储的健康记录是否加密（如是否使用硬件安全模块HSM）；⑦支付功能：处方药配送支付是否与医保支付隔离，防止混合支付导致的资金风险；⑧性能瓶颈：同时在线问诊人数超1000时，视频通话是否出现卡顿（影响问诊质量）。（3）测试方案（以“视频通话安全”和“处方上传鉴伪”为例）：测试方案1：视频通话安全审计测试环境：Android/iOS真机各1台（安装被测APP）、模拟攻击设备（安装抓包工具Charles）；测试工具：Wireshark（抓包分析）、OpenSSL（验证