最近在帮团队搭建移动应用安全测试流程翻GB/T 34975-2017的次数比过去几年加起来都多。不少开发同学拿到这份标准文本后问我这么多条款到底该先看哪一部分测试评价方法那一章又是怎么和技术要求对应的说实话我刚开始啃这份标准时同样头疼条文多、术语密但把它拆开看之后会发现它的逻辑骨架其实非常清晰。这篇笔记就把我的理解完整梳理一遍尽量讲清楚这份标准约束谁、要求什么、怎么验证、落地时容易错在哪。这份GB/T 34975-2017全称是《信息安全技术 移动智能终端应用软件安全技术要求和测试评价方法》2017年发布属于信息安全技术国家标准体系中的一项。理解它不需要深厚的密码学背景但确实需要一点耐心把技术要求和测试评价方法两条主线串起来读。适合移动端开发、安全测试、产品经理以及需要配合应用合规工作的同学参考。1. 先读懂这份标准的定位推荐性国标为什么绕不开1.1 一句话说清标准是什么GB/T 34975-2017解决的是这样一个问题一个移动智能终端应用软件也就是我们常说的App在安全方面到底应当做到什么程度以及怎么去验证它是不是真的做到了。标准把安全拆成两层一层是技术要求告诉开发者应用应该具备哪些安全能力比如说权限不该随便乱申请、数据不该明文存在本地、通信链路不该裸奔另一层是测试评价方法告诉检测人员怎么通过静态分析、动态运行、人工核查这些手段去验证前面那些要求是不是真的满足。这两层是咬合的关系没有技术要求测试就没有判断依据没有测试方法技术要求就停留在纸面上无法落地。所以读这份标准时建议把技术要求和对应的测试评价方法放在一起看不要割裂。1.2 推荐性国标为什么绕不开GB/T开头的标准是推荐性国家标准从严格意义上说不像强制性标准那样必须执行。但实际工作中你会发现它绕不开。应用分发平台、监管抽查、第三方安全检测机构大量依据这类标准来评估App的安全合规水平企业内部做安全评审、上线前测试也经常把GB/T 34975-2017当作参照基线。尤其是当你需要向外部机构提交安全检测报告时里面字段和结论的判定逻辑往往就是按照这类标准的框架来的。它的适用对象是移动智能终端应用软件也就是说只要你的应用运行在手机、平板这类智能终端上不管是Android还是iOS平台都在考虑范围内。标准里涉及的安全问题大多集中在应用自身的安全能力、用户数据的保护、以及对外部恶意行为的防范上。它不深究某一款操作系统底层实现而是站在应用软件层面提要求所以即使系统版本迭代了大部分安全要求的思路仍然适用。另外读这份标准时建议和《信息安全技术 个人信息安全规范》GB/T 35273摆在一起看。前者侧重应用软件的安全能力和测试方法后者侧重个人信息处理活动的合规边界。两者之间有交集但视角不同。权限管理、个人信息收集这些方面两份标准都提到但一个从软件行为出发一个从数据生命周期出发。把两份标准对照着读能更好地理解监管逻辑。2. 安全技术要求的九大考查方向拆开看才有抓手标准里的技术要求覆盖了移动智能终端应用软件从启动、运行到退出的全过程。我自己习惯把标准中的安全要求归纳成九个方向这样在给团队拆解和建checklist时方便很多。下面按主题逐一说明。2.1 权限与个人信息保护最容易被盯上的两块权限管理是很多应用翻车的高发区。技术层面标准强调最小权限原则应用申请的权限应当与实现功能有直接关联不应当申请与业务无关的权限也不应该在用户未授权的情况下静默获取敏感信息。举例来说一个手电筒应用没理由申请读取联系人权限一个天气应用也没必要常驻后台读取精确位置。开发团队做权限梳理时不能只看清单里有没有权限更要看每个权限对应的使用场景是否合理。个人信息保护这部分和GB/T 35273呼应。应用收集个人信息前应当有隐私政策向用户明示收集了什么、为什么收集、怎么使用收集方式要获得用户的知情同意不能通过诱导、默认勾选、隐藏协议这些手段绕过去。除了收集环节存储和使用环节同样是考查重点个人信息不应被无关人员随意访问不应被用于与声明目的无关的场景未经同意不能共享给第三方SDK。这里要特别提醒一句很多团队只在隐私政策里写了我们不会共享你的信息结果接入的统计SDK、广告SDK、推送SDK都在后台上报数据这种声明与行为不一致的问题在测试中几乎是必查项。2.2 通信、存储与代码安全底层安全能力的硬指标通信安全方面标准要求应用在传输数据时采用可靠的加密方式常见的判定点包括不应当使用明文HTTP协议传输敏感数据使用HTTPS时要有正确的证书校验逻辑不能图省事故意放开证书校验不在日志里打印Cookie、Token、用户口令这类关键信息。这部分的测试往往是通过流量抓包和日志审计来完成很多问题出在自己测试时为了方便把证书校验关掉了结果正式包也忘了打开。存储安全重点在本地数据的加密保护。应用不能把账号口令、支付信息、身份证号等敏感数据明文写在SharedPreferences、本地数据库或日志文件里密钥不能硬编码在代码中。实际检测中经常见到的情况是敏感数据做了加密但加密密钥就写在同一个工程的代码里这等于把钥匙和锁放在一起防护效果大打折扣。更稳妥的做法是使用系统密钥链、安全芯片或专业的密钥管理方案至少也要做到密钥与应用运行逻辑隔离。代码安全主要涉及抗逆向和完整性保护。常见的落地手段包括代码混淆、加固、签名校验、反调试等。标准并不强制要求所有应用都做到银行级防护但它会考量应用面对常见逆向分析手段时的抵抗能力。对大多数商业应用来说最基本的底线是代码混淆要开启重要逻辑不能裸奔要避免把签名密钥、云服务密钥、支付密钥直接写在代码里。2.3 组件、WebView与恶意行为隐蔽风险集中的区域组件安全是Android平台特有的考查点。四大组件Activity、Service、BroadcastReceiver、ContentProvider如果在Manifest里被设置为导出同时没有做权限保护就可能被其他应用恶意调用导致信息泄露、界面劫持或越权操作。测试时检测人员会重点核查导出的组件有没有做调用方校验ContentProvider有没有暴露敏感数据的读写能力动态注册的Receiver有没有处理恶意广播。iOS平台虽然没有这套组件模型但同样会关注URL Scheme的开放范围是否合理。WebView安全也是高频问题点。很多应用内嵌了H5页面如果WebView开启了JavaScript接口addJavascriptInterface又没有对调用方做严格校验就可能被恶意网页注入攻击。标准在这一点上的要求很明确加载不可信内容时禁用JavaScript确需启用时要对调用接口做白名单校验WebView本地文件访问权限要按需关闭不允许任意URL都被WebView直接加载。恶意行为防范是一个底线性的要求。应用自身不能是恶意软件不能包含木马、病毒、后门逻辑也不能偷偷在后台收集用户信息、私自联网上传数据、静默安装其他应用、强制弹窗诱导点击。这一块除了人工代码审计很多检测机构还会把应用放到沙箱里运行结合行为监控观察网络行为、文件访问行为、进程间通信行为。对开发者来说这条要求意味着除了自己写的代码还要特别留意集成的第三方SDK。有些SDK在后台做的事情可能连接入的团队自己都不完全清楚。3. 测试评价方法不是随便测测技术要求怎么对应检测项3.1 四种测试手段的组合逻辑标准里的测试评价方法通常不会是单一技术而是静态检测、动态检测、人工核查、渗透测试四类手段的组合。理解它们的区别对团队内部预估测试成本和时间很有帮助。静态检测是在不运行应用的情况下做分析。检测人员拿到App安装包先解包看AndroidManifest配置提取权限列表、组件导出情况、备份标志位再用反编译工具或者自动化扫描工具对代码做批量审查查找硬编码密钥、WebView风险、不安全的加密算法调用、敏感API使用等。这一步自动化程度可以很高产出也快缺点是对运行时行为无能为力。动态检测是把应用装到真机或者模拟器里运行观察它的实际行为。检测人员会抓取网络请求检查有没有明文流量、敏感数据外发监控文件系统的读写看敏感数据是否被明文落盘观察启动过程、后台行为以及应用之间的交互。动态检测能发现很多静态扫描看不到的问题比如某个SDK在特定条件下才会触发的数据上报只有靠运行时的行为监控才能暴露出来。人工核查主要针对那些机器不容易判断的内容。最典型的是隐私政策审核隐私政策文本有没有写清楚收集哪些信息申请权限的时机和说明是否与真实行为一致这些都依赖人去看。还有一个典型场景是权限申请的时机——应用在用户首次启动时就弹出一堆权限请求框还是在使用具体功能时才弹这类问题靠自动工具很难给出准确判断。渗透测试则是在授权前提下模拟攻击者的思路去尝试突破应用的安全边界。常见方向包括尝试中间人攻击验证通信链路安全性对导出的组件做越权调用测试对WebView接口做注入测试尝试绕过客户端的完整性校验。渗透测试对测试人员的能力要求最高通常由专业安全测试人员执行但它的价值在于验证看起来安全的设计是不是真的有抵抗能力。3.2 从检测项到判定结论怎么给一个应用打分每次测试得到的结果最终要落到一个个判定结论上。常见的结果分类大概是符合、基本符合、不符合、不适用。符合表示该检测项在实际测试中未发现问题不符合表示明确存在安全问题基本符合的情形比较微妙通常是发现了问题但影响范围有限或者问题整改起来不涉及架构级改动。比如权限列表中有一个冗余权限但实际没有被调用可能被判定为基本符合但具体要看检测机构的尺度和标准条款的表述。不适用则是指该检测项对应的功能在当前应用里根本不存在比如不涉及支付功能的应用就不需要考核支付安全相关条款。判定逻辑里有两点值得注意。第一标准要求的是安全能力而不只是外部表现所以即使应用没有直接出事只要它的设计存在明显可以被利用的漏洞同样会判不符合。第二同一个问题可能同时落在多个检测项下比如本地明文存储用户手机号既涉及存储安全条款也可能涉及个人信息保护条款这种交叉情况在整改时不要遗漏。3.3 一次完整测试的产物长什么样做过安全合规立项的同学应该比较关心这个问题。一次完整的标准符合性测试最终交付的通常是一份安全测试报告和一个问题清单。安全测试报告的主体结构一般包括应用基本信息、测试环境说明、测试工具清单、检测项逐条记录的测试结果、不符合项的严重程度分级。问题清单里会列出问题描述、涉及的条款、复现步骤、影响分析和整改建议。对团队来说最有价值的其实是那个问题清单因为每一项都对应到代码层面的具体位置或配置。拿到之后建议立刻按严重程度排序把P0级问题例如核心敏感数据明文传输、任意组件可被外部调用并泄露数据优先处理然后再处理合规性方面的问题。4. 合规落地中反复踩到的坑以及我的处理习惯4.1 常见误判把过了测试当成安全达标我和不少研发团队协作时发现一个普遍心态只要拿到了检测通过的结论就觉得安全问题可以不用管了。但实际工作中一份测试报告上写着通过只代表测试时用的样本包和测试环境下没有发现标准范围内的问题并不等于应用万无一失。标准本身给出的是基线不是天花板而且测试样本包和线上正式包如果存在差异结果也不可累推。更进一步说很多团队只在提测前临时做安全测试开发过程中完全不管安全。这样做的直接后果是测试阶段一次性跑出几十个问题修复成本高有些架构性的问题甚至要返工。更理智的做法是把标准中的核心要求提前嵌入需求评审和开发自测环节发布前再做一轮完整的合规验收。测试不应该只是最后一关的守门员更应该是开发过程里的导航仪。4.2 几个现场整改的高频场景从我的观察看测试不过的问题集中在这么几个场景。权限申请与功能不匹配是最常见的一项。应用清单里有一堆权限但代码里根本找不到对应调用或者权限申请时机过于激进一启动就弹窗要通讯录权限。整改建议是回到产品功能设计层面明确哪些功能使用哪些权限删除无用权限权限申请的时机尽量放到具体业务触发的节点并且要向用户解释申请目的。隐私政策声明与行为不一致排在第二。很多应用的隐私政策是上线前临时从网上抄来的模板里面说不会采集用户信息但代码里统计SDK、推送SDK都在收集设备信息。整改时不是简单改一版隐私政策文本就行而是要根据真实的代码行为重新梳理数据收集清单再把清单写进隐私政策里。换句话说先改行为再改声明声明要如实反映行为。第三大高频问题是明文传输。有些老项目为了后端调试方便线上环境还在用HTTP请求。整改方案是在服务端和客户端同时切换到HTTPS并且做证书校验。这种问题往往不只是一个配置项还会牵扯到后端接口的支持情况需要前后端联动处理评估周期要留足。还有一类问题比较隐蔽日志中打印了敏感信息。开发阶段为了方便排查很多人会在日志里输出Token、用户ID、甚至密码字段。解决问题不能只靠上线前删日志而是要在日志框架层面做脱敏对包含关键字的数据统一打码同时禁止在生产模式下输出调试级别的日志。4.3 把标准翻译成内部checklist标准全文比较长研发团队不可能每次评审都从头翻一遍。我的建议是把标准里的技术要求整合成一份内部的移动应用安全基线Checklist内容直接面向开发人员。比如权限配置清单每个权限对应的功能点上线前逐个确认网络请求基线生产环境全部HTTPS禁止绕过证书校验数据存储基线敏感数据必须加密密钥不得写在代码里组件安全基线非必要组件不导出导出的必须做权限校验WebView基线禁止对不可信网页启用JavaScript接口第三方SDK清单接入前做安全评估明确SDK收集了什么数据、上报到哪里这份checklist不追求覆盖标准所有条款只要求覆盖自己业务涉及到的部分后续随着团队经验积累持续迭代。比背标准条文更管用也更容易在日常开发中执行。5. 把标准变成团队日常从评审清单到发布门禁5.1 将标准条款翻译成开发团队看得懂的语言标准里的表述为了严谨很多地方偏向法律文书或者学术风格一线开发读起来并不轻松。我的习惯是在团队评审或培训时用业务场景违规例子正确写法的方式讲解每一项要求。比如讲本地数据加密时先展示一段把用户Token直接存进SharedPreferences的代码再展示结合EncryptedSharedPreferences正确存取的写法。这样开发同学能够立刻感知到安全问题不是一个抽象条款而是具体代码层面的选择。再比如说通信安全这一块与其反复强调不要用HTTP不如在代码评审里直接标注这里是否走了HTTPS证书校验策略做了什么形成评审惯例。把标准的词汇翻译成代码评审里会出现的问题执行阻力会小很多。5.2 与现有开发流程衔接的实操建议在流程层面我建议把安全测试做成发布门禁的一部分而不是可有可无的环节。对于中小团队不需要一上来就买昂贵的安全测试平台可以先用开源工具跑静态扫描再结合人工代码评审和上线前的核心用例动态测试。条件允许的情况下把静态扫描工具接到CI流水线里每次提交自动跑一遍发现问题直接阻挡合并。这样做的问题在于刚开始扫描结果可能噪音很多需要花时间去配置白名单和过滤规则但一旦跑顺了收益非常明显。第三方SDK的管理也要纳入流程。建议团队维护一张SDK清单记录每个SDK的用途、版本、权限申请、数据采集项。每次接入新SDK之前先走一遍安全评估它申请了什么权限会往哪些域名上报数据数据入库后怎么管理如果评估不通过宁可自己不实现相关功能也不要随便引入一个来路不明的闭源SDK。还有一点标准版本和相关配套标准是动态更新的。团队里最好有专人持续关注与移动应用安全相关的国标、行业标准以及检测机构的实际操作口径变化。标准只是起点真正的安全能力来自团队对威胁的持续跟踪和对质量的持续投入。说一点我个人的体会。做移动应用安全合规这几年最大的感受就是不要把GB/T 34975-2017当成一份束之高阁的文档它是可以直接指导代码实践的。每次因为权限问题、数据明文存储问题做整改时回头看标准总能发现原来条款早就摆在那里只是我们读的时候没有和业务场景对应起来。建议你下次接一个新App的安全评审之前先对着标准把九个方向过一遍再结合自己产品特性圈定重点检测项你会发现后面的事情顺很多。