开发者学堂课程【互联网安全-移动APP漏洞风险与解决方案：常见 APP 风险检测】与课程紧密联系，让用户快速学习知识
课程地址：https://developer.aliyun.com/learning/course/357/detail/4193
常见 APP 风险检测
内容介绍：
一、代码安全
二、数据安全
三、自动化漏洞检测
一、代码安全
技术风险
代码安全(逆向、 调试、重打包)
数据安全(存储、 传输、使用、验证)
环境特性(系统、 组件、权限、端口)
业务风险
逻辑漏洞(逻辑绕过、 校验)
策略
合规
遍地成熟的反编译工具
硬编码问题（密钥）
代码逻辑
篡改、重打包
首先是代码像安卓的就是用 Java写的， Java 的语言特性应该都比较了解，它的代码基本上是在编以后阅读可阅读性非常的高，
像图中例子就是一个 APP 里面的一个登录模块的一个代码，直接用一个页界一些非常多的一些通用的反编译软件基本上便利都有，像 APK改制立项 Jeb，最低盖都可以把APK拖到里面直接就自动化的就反编译出来了，反编译出来的代码非常整齐，从里面可以看到基本上的函数名，还有里面的一些方法的调用都非常的清楚，这一段可以直接去红框内容可以直接去看到在登陆的模块的实践方法。
发现DES算法的密钥，硬编码为"yrdAppKe", 用来加密手势密码:
.method static cons tractor <c11n1t> ()V
.1ocals 1
.prologae
.1ine 36
const-string vO, "y;dAppKe"
sput-object v0, Lcom/yirenda1/u1/1ockPattern/SetLocusPas sWordView; ->f:Lj ava/1eng/String
将手势密码 DES 加密后存在本地 LocusPassWordView.xml 文件中：
除此以外，现在有很多的开发就会觉得越来越多的开发可能在开发APP的时候就会考虑到 Java 代码的安全性的问题，可能就会把很多的一些代码逻辑比较核心的逻辑可能就会用C 的语言，比方说用JNI的方法写在 SO 里面，
另外就是 iOS 开发也是用 ultra C 写出来之后基本上就是以两进制的文件存储，但很多开发可能会觉得这已经是安全了，
实际上现在 ida 工具的使用直接，如果没有做经过任何的保护基本上这个 XO 文件用C 写的文件直接拖到里面也是可以看的非常清楚，像这一段里面的一些函数方法一些加密，加密方式都可以写得非常的明白，这里面提到的代码安全，最主要的攻击场景，
因为现在基本上的软件也是非常的多，而且基本上入门也没有太高的门槛，所以从攻击的角度来看最主要就是别人去反编译的一个 APP，然后我看到了里面的分析，里面的代码逻辑不管是加密的密钥也好，然后函数的调用方式也好，像我们之前去协助一个客户去处理去做一个外挂分析的时候，就会发现他们的 APP注册的时候，可能会需要用到邀请码，别人直接把他的 APP 里面把邀请码的那一段代码逻，直接COND 的然后跳过，重打薄一下直接就可以不需要邀请码就直接注册，所以像代码安全就是便于利用分析，
第二个重打薄篡改你的 APP，但是最简单现在对没大部分 APP 都会有的一个APP第3方SDK，都会有一个同样问题就是密钥硬编码的问题.
二、数据安全
存储区（公共、应用）
传输加密
存储加密
使用与验证
存储区
SD card
文件夹权限
UlFileSharingEnabled (iOS)
Keychain
存储方式
Shared Preferences
SQLite Databases
Internal Storage
External Storage
数据的安全保护的问题，数据保护最主要分为三类，一个是数据的存储是存在什么地方，一个是公用的地方，还是说一个私有的目录，然后私有的目录有没有做权限控制，哪些应用可以读取的时候它的读取方式是什么样子的，另外一个就是数据存储的加密问题，它存在本地敏感的数据是不是做了加密然后这个加密能不能被解开就像前面提到的，存在本地的手势密码文件，另外就是在数据的使用和验证有没有考虑的比较清楚。
其实存储的地方都比较通用的，比方说一个存储的SD卡基本上所有的应用对SD卡，直接只要去申请都可以具备这个权限，如果把一些比较敏感的东西存在SD卡里面，基本上其它应用不管是不是和应用都可以读到里面，内容甚至是不管是普通用户还是说非用户本身都可以拿得到这样子SD卡，比较通用的一些场景，
比方说如果说你的应用会下载一些缓存文件，包括说下载H5的渲染文件，然后会下载游戏的资源文件可能就存在SD卡里面，另外一个就是现在近期非常常见的就是很多应用的更新宝会放在SD卡里面，这个问题其实前面也有漏洞，产生前面已经有了这样的漏洞案例了就是把这个应用的更新包放到SD卡里面，如果你再去下载到SD卡里之后，去安装自己新的APP去覆盖原来的时候如果去安装的时候，你没有去做校验，那有可能说别的应用或者别人也去下了一个，把这个 APK 直接下到了指定的目录里面，那可能你装的时候就装了别的应用，就会导致这样的情况出现，
另外就是说如果你是存储在本地的私有目录，这个文件夹的权限设置或者是说别的 APP 来去读取，读取的时候不管是消息和权限的验证是不是已经做得足够充分，原来有个社交的 APP 在文件权限，
可能就没有考虑过之前他们在本地的一个 XML 文件，是存储用户的登录态，它可能本身的一个登录态也不会有太大的直接的风险影响，但是因为权限设置的原因导致别的APP也可以去更改里面的内容，可能别的应用就不断的去每次在用户启动的时候他就去改里面的改里面的文件，导致我们自己的APP去读取这个文件的时候就读取失败就一直无法运行，
另外像 iOS 里面会有一个共享文件夹，共享像现在的很多音乐 APP包括看电影的也好包括电子书，甚至是说里面别人给我收发文件的时候，我们会设置到这么一个方法，
这个方法就是说非越狱的 iOS 设备我再插上电脑时候，用户可以从那个共享文件夹里面去拖东西出来，如果这里面的内容我们再去做存储的时候去严格做限制了， iOS 比较通用的一个叫 Kitchen.
其实原来大部分的在非越狱的状态下，基本上还是一个比较安全的存储通道，但是在越狱的情况下 Kitchen 算，基本上就是比较通用的可读的东西了，所以在 Kitchen 里面我们尽量在考虑这个安全方式的时候就要直接去考虑到这个 APP，它是运行在一个不安全的一个开放的一个设备里面，我们就已经假设它是已经在一个越狱,所以注册的环境下面去运行 Kitchen 里面就不要去存储一些敏感的密钥，用户的手势密码或者是一些登录态的一些比较长期有效的登录态，
另外就是在存储这个内容我们在数据保护是非常多开发，也包括说我们自己内部的很多开发者也会遇到这样的问题就是在日志的保护，游戏王是安卓还是iOS打log的，
它打出来的log也是所有的应用都有权限的，很多的开发就已经习惯性地说我去打一些报错的log，或者是打cash然后我再从服务端再把它收上来，去分析这个APP的 Crash 的情况，
可能会经常在不经意之间把用户的一些敏感的信息也会打印出来，不管是用户的登录也好还有说他无法访问过的业务路径，比方说他访问过什么页面具体的页面然后访问过是具体的一些商品，或者是他做过什么样的操作可能都通过 log 的形式打印出来，
这个log其实也可以被其他的APP或其他的应用给采集到这样子就会有一些隐私的风险行为，此外像那个安卓的那个四大的存储方式，然后接存储方式不管是数据库也好还是需要 province 这个文件，不管是内外部的存储它其实用的不妥当都会有风险，然后具体的这些情况我们其实都已经把它详细地写在了几篇文章里面，
另外就是像数据的存储是做了加密然后考虑到说在设计到数据安全的时候除了存储，存储的地方以及它存储APP应用数据本身在做存储的时候要做加密以外，还要考虑到的就是在传输的时，传输的情况，传输时可能都会考虑到的敏感信息把它加密了再传，传到服务端再解密，我们先抛开那个具体用到什么，先抛开具体的加密的方法和加密的包括说对称还是非对称，还是说密钥本身的安全问题之外，我们还要去看的就是说像https的情况，我们之前也遇到过不少这样的案例，去跟开发者去聊的时候，很多的开发者认为说我这个去连接服务器与我用的是 https，所以我基本上不会有问题，
出现的一个这种漏洞案例也是太多了，包括不管是利用的还是说已经被检测出来的一个，就是说 bhtps 本身是否安全其实本身 htpsb 是 IC 协议非对称协议本身是安全的，
但是可能我们很多的人在用的时候，比方说像安卓虽然说在传输的时候用到了htps ，但是应用本身没有去强校验证书比如那意思就是说我的这个 htps 的包，如果在一个网段包括做公共 WiFi，还是说在一个大的局域网下面，我直接去可能去弄个代理，可以去甚至是说在路由直接去抓个包，是完全可以看得到 HD PS里面的数据情况的，因为这个应用没有校验证书的话那就是说我挂在任何，都能抓到这个手机本子发出去的数据包，这样肯定就会有问题的东西，大家可以看我们博客上面已经有非常显明的一个漏洞，展现这种漏洞基本上现在像这个漏洞现在看其实现在已经是被定义为高危的漏洞。
数据使用的情况，一个就是在网上拉的图就是之前有个聊天工具，可能说看照片我付钱，后来很多的博客就已经公开了这种各种各样的方法，包括说我直接去抓一个包，我自己就看到这张图片了，因为它是在本地再去做的渲染才去做的加密，另外现在很多的APP它可能本身就不仅仅只是一个 DeX 文件，然后他可能会有两个 DeX文件，
比方说我有一个主 DeX，然后运行的时候，运行到另外一个 Death ，如果在对这个 Death 的放置，已经在调用这个的时候安全问题是否已经考虑到了，也会有这个情况，另外说数据的劫持和篡改也是非常常见的问题，
包括现在很多不管是在游戏行业的一个脱机挂就是脱离了APP游戏的一个用户粘性，包括说现在很多的一些协议刷，在很多必须在考虑做活动APP本身的一些行为动态的时候，
如果被别人直接分析出你的协议直接从拿出来用脚本的形式，模拟基本上就没你这 APP，甚至说可以非常高频率的就是脱离一个人的交互行为来去做这种事情，可能就会考虑到更多的就是说我这个协议，怎么不去防止别人篡改或者说怎么去识别这个用户请求，就是从机器从这个应用发出去本身的。
三、自动化漏洞检测
很多的开发者包括说普通用户是很难去考虑到大大小小的安全问题和风险的，举个很简单的例子，像很多的开发者包括说我们之前接触到的一些不少的自己内部的开发者也好，像遇到之前一些非常常见的漏洞，像安卓四大组件引起的拒绝服务漏洞，之前遇到过一个什么案例像拒绝服务漏洞其实都是大部分现在比较通用的，就是本地的拒绝服务很多开发者或者是说用户其实也会不以为是这个拒绝服务漏洞，他要利用的时候他的条件是非常有限的，一个就是说它只能针对具体的某一台设备上的应用去产生，
APP有时越服漏洞那如果别人要去利用这个漏洞那它的利用场景非常有限他只能在我的手机上面才会有这个问题，才能到设备挂掉另外就是说它必须是一个应用，或者是用户本身自己去向应用去发起这一串利用代码，他才能会产生拒绝服务但是之前我们遇到过一个客户反馈的一个案例，说他们的应用最近那个新增用户数下降的非常厉害，然后发现了另外有一个市场上面有一个仿冒他们的应用，排名就越来越高，后来我们去分析那个仿冒应用，就发现它的代码里面就写了一串去利用这个原本的真实应用的一个拒绝服务，那他造成的场景就是说去跟他通过各种各样的方法，
比方说他去不管是通过最常见的这种短信推广还是说诱导下载，去诱导用户去下载了这个假的应用之后，那如果用户每次去访问这个真应用的时候，这个假的应用就会向这个真的应用去发了这一串导致拒绝服务的代码，那每次一个正常用户去点开原来那个真的应用，那这个真的应用就会不断的去挂那可能用户就以后就慢慢的就不用这个真的应用了，就会去用那个假的号码应用甚至说已经把真的应用给卸载掉了，
那假的应用可能就会有别的危害，包括说那个本身去窃取用户的隐私信息，去推广的一些恶意消费恶意链接之类的，所以在开发者和用户的角度，其实是很难的去怎么去评估，一共会有哪些有多少风险，
另外我的风险，究竟它会有哪些危害，怎么去修复，然后我们现在阿里聚安全本身也是有一个自动化的做了一个自动化的漏洞检测检测工具，它就可以直接我们去传的一个 APK 传上去了之后直接去提交扫描基本上根据你这个大小APP的大小我们就可以，根据你这个APP大小它大概的时间也是蛮快然后基本上扫描出来之后就可以看到漏洞数有多少个，
然后我这个类型的漏洞业界平均会有多少个，比方说我这是一个游戏类的比方说APP业绩会有56个漏洞，那可能平均每个 APP 56个，那可能我在 APP 有12个，
这个漏洞的分布情况高危中危低危，然后包括说我这个漏洞的细节在哪里，然后他在什么样的代码位置，然后我的修复方案是什么，有没有一些参考的文章都可以非常清楚的看得到。
