企业级安全审计方法论
做移动安全审计这些年，我见过太多「看起来安全」的App了。说白了，安全审计不是拿着工具扫一遍就完事，它是一套系统化的方法论。今天我就把这套方法论掰开揉碎，跟你聊聊。
黑盒审计 vs 白盒审计
先说说两种主流方式。我个人习惯把黑盒审计比作「闭着眼睛摸象」，白盒审计则是「开膛破肚看内脏」。
黑盒审计
你拿不到源码，只能通过APK/IPA文件、网络抓包、动态调试来搞。我在项目中遇到过不少甲方只给一个安装包，连开发文档都不给。这时候就得靠经验了。
- 静态分析：反编译APK，看AndroidManifest.xml、看so文件、看资源文件
- 动态分析：抓HTTP/HTTPS流量、Hook关键函数、调试JNI层
- 网络层：检查证书校验、看有没有中间人攻击的可能
- 本地存储：扒SharedPreferences、SQLite数据库、Keychain（iOS）
我的经验：黑盒审计最怕遇到「加固壳」。我曾经花了两天时间脱一个360加固，结果发现核心逻辑都在服务端。嗯，有时候得学会止损。
白盒审计
有源码就舒服多了。你可以直接看业务逻辑，找那些「看起来没问题但实际有坑」的地方。
- 代码审计：重点看加密算法、Token生成、权限校验
- 第三方SDK：检查有没有引入不安全的库，比如老版本的OkHttp
- 混淆检查：ProGuard/R8配置是否合理，关键类有没有被混淆
- 硬编码：API Key、Secret、数据库密码是不是直接写在代码里
注意：白盒审计不代表你能发现所有问题。有些漏洞是运行时才暴露的，比如条件竞争、内存破坏。所以我的建议是——黑盒白盒结合着来。
审计报告撰写规范
报告写得好不好，直接决定了你的审计价值。我见过太多「漏洞列表+截图」式的报告，说实话，这种报告甲方看完也就扔一边了。
一份合格的审计报告，至少包含以下内容：
- 执行摘要：给老板看的，用三句话讲清楚「有什么风险、多严重、怎么修」
- 审计范围：App版本、平台（Android/iOS）、审计时间、审计方法
- 漏洞详情：每个漏洞要有编号、位置、危害、复现步骤、修复建议
- 风险统计：按严重程度分类，高危几个、中危几个、低危几个
- 附录：工具列表、参考文档、测试账号等
核心原则：报告要让「不懂技术的人看得懂风险，懂技术的人看得懂修复」。
漏洞评级标准（CVSS）
CVSS v3.1是目前业界通用的漏洞评分系统。你想想看，如果没有统一标准，你说「这个漏洞很严重」，我说「还好吧」，那不就乱套了？
| 严重程度 | 分数范围 | 典型例子 |
|---|---|---|
| 严重 | 9.0 - 10.0 | 远程代码执行、未授权访问数据库 |
| 高危 | 7.0 - 8.9 | SQL注入、越权操作、敏感信息泄露 |
| 中危 | 4.0 - 6.9 | 弱加密算法、日志泄露、未使用HTTPS |
| 低危 | 0.1 - 3.9 | 信息泄露（非敏感）、调试接口未关闭 |
CVSS评分主要看三个维度：
- 可利用性：攻击难度高不高？需要物理接触吗？
- 影响程度：机密性、完整性、可用性哪个受损？
- 环境因素：这个漏洞在你的业务场景下有多危险？
避坑指南：我曾经把一个「本地SQLite数据库未加密」评成了高危，结果甲方反驳说「数据库里只有缓存数据」。后来我学乖了——评分前先确认业务上下文。
合规性检查
合规不是技术问题，是法律问题。你App做得再安全，如果违反了GDPR，照样被罚到破产。
GDPR（通用数据保护条例）
主要针对欧盟用户数据。核心要求：
- 数据最小化：只收集业务必需的数据
- 用户同意：收集前必须明确告知并获取同意
- 数据可删除：用户有权要求删除自己的数据
- 数据泄露通知：72小时内必须报告监管机构
PCI-DSS（支付卡行业数据安全标准）
如果你的App涉及信用卡支付，那必须过这一关。关键点：
- 加密存储：卡号、CVV、有效期必须加密
- 网络隔离：支付数据走独立通道
- 定期扫描：每季度做一次漏洞扫描
- 日志审计：所有访问支付数据的操作都要记录
注意：合规检查不是「一次性」的。法规在更新，你的App也在迭代。我建议每半年做一次合规复查。
实战：金融App安全审计
好了，理论说完了，咱们来点实际的。下面是我对一个金融App做完整审计的流程，你可以直接套用。
第一步：信息收集
拿到App后，先别急着反编译。先搞清楚：
- App是做什么的？转账？理财？借贷？
- 目标用户是谁？国内还是海外？
- 有没有合规要求？比如PCI-DSS？
第二步：静态分析
用jadx反编译APK，重点关注：
- AndroidManifest.xml：有没有exported的Activity？有没有debuggable=true？
- 网络请求：用的是HTTPS吗？证书校验怎么做的？
- 本地存储：有没有存明文密码？Token存哪了？
第三步：动态分析
用Frida Hook关键函数，抓包看流量：
- 登录接口：密码有没有加密？Token怎么生成的？
- 转账接口：有没有金额篡改的可能？
- 敏感操作：有没有二次验证？
第四步：漏洞验证
发现疑似漏洞后，一定要手动验证。举个例子：
// 假设发现了一个未授权的接口
// 用curl模拟请求
curl -X POST https://api.example.com/transfer \
-H "Content-Type: application/json" \
-d '{"amount": 10000, "to": "attacker_account"}'
// 如果返回200，说明存在未授权访问漏洞
// 如果返回401，说明有权限校验，继续找其他点第五步：报告输出
按照前面说的规范写报告。记得附上复现步骤和修复建议。
实战心得：金融App的审计，重点永远在「资金安全」和「用户隐私」上。其他漏洞可以往后放，但这两个方向必须查透。
知识体系总览
下面这张图，是我自己总结的安全审计知识体系。你照着这个框架走，基本不会漏掉关键点。
嗯，以上就是企业级安全审计的完整方法论。说白了，安全审计不是炫技，而是帮企业发现风险、降低损失。你按照这个框架走，至少能保证不遗漏关键环节。