常见的 App 安全问题

馥琳

常见的 App 安全问题

据2015年第三季度移动安全报告显示，Android 16个行业 TOP 10 应用漏洞类别和数量中，Webview远程代码执行占到了第一位，第二位是Webview文明存储密码。这些领域涵盖大家平时工作领域，我们所面临的漏洞是非常严峻的。
安全研发

作为开发人员，应该从以下两个方面来应对安全的问题。
常见安全问题分析

   
上图可看出Android研发要点约450个，包含组建安全、配置安全、策略安全、通信安全、权限欧洲、DOS安全、ROOT安全等等，今天从这里面挑一些重点讲一下。

• 组件安全问题。安全有四大原生的组建，第一个是Activity，首先是访问权限控制，组建处理不好会导致你的应用被恶意程序进行恶意的页面调用。作为研发人员，我们可以从以下三点来预防和避免这个问题：
     
  
  
  
  • 私有的Activity不应该被其他应用启动且应该确保相对是安全的；
    
  • 关于Intent的使用要谨慎处理接受的Intent，以及其携带的信息尽量不发送敏感信息，并进行数据校验。
    
  • 设置Android：exported属性，不需要被外部程序调用的组建应该添加android:exported=”false”属性。
    
  
  

第二个组建安全是Service劫持、拒绝服务。常见的漏洞有 Java 空指针异常导致拒绝服务和类型转换异常导致的拒绝服务两种。应对 Service 带来的安全问题给大家三点建议：一我们应用在内部尽量使用 Service 设为私有，如果确认这个服务是自己私有的服务，就把它确认为私有，不要作为一个公开的服务；针对 Service 接收到的五数据应该进行校验；内部的Service需要使用签名级别的 protectionle。

• 传输安全。本地校验用户验证码也非常重要，以后请大家开发中本地的数据校验尽量不要放在本地，尽量放在云端。对于数据的加密，建议所有的App和用户的客户端不要用一个共同的密钥，对于密钥生成的方法尽量根据用户的ID或者一些信息来生成出来，这样避免了大规模密钥的泄露。
  
• 第三方组件安全。之前做App应用，在研发后对应用做了很多安全防御。但是大概刚上线不到两天就暴露出漏洞了，究其原因是App项目中用了国内一家非常著名的SDK的推送平台，由于这个平台在发送推送广播的时候没有做数据的校验，导致了黑客可以利用这个推送广播进行伪装，给我发一些数据，最后导致应用在接收了广播之后，只要我点击这个广播应用就崩溃。因此我们除了做好自身应用的安全以外，要保证所引用的第三方，或者合作伙伴也是安全的。也就是说安全是一个团队性的。
  
• Webview的代码执行漏洞。安卓存在一个非常著名的远程代码执行的漏洞，由于我们程序没有正确地使用，大家可能在做GS和Java户调的时候会遇到这个问题，远程攻击者可以通过Java分设接口执行一些恶意的Java方法，最终导致App在使用Webview的时候遭到攻击。我们是可以做一些应对的，安卓系统通过Webview通过一个注册来调用Java功能，攻击者利用反射对他进行攻击，其实谷歌也看到了这个问题，因为这个问题毕竟比较大、也比较广，所以谷歌在API Level17以后这个问题就得到了遏制，对于小于17，或者17以下的能不使用就不使用，如果真的要使用可以增加过滤，对数据的传输做一下校验。
  
• 应用安全层。可以对代码进行一些混淆，如配置，如果觉得这还不够，也可以使用一些第三方的工具，比如APK文件。对于更加讲究安全性的经营类的企业，可以选择加固，使用脱壳程序，最后形成一个新的Dex包，最后完成对一个程序的加固。
  

安全编码规范
其实程序员的编码规范很重要。在Java中，对于一些重要的类、方法、变量，我们在定义的时候一定要想这么几个问题。

• 定义的类或者变量到底返回什么？
  
• 它们获得什么作为参数？
  
• 是否能够绕过安全线？
  
• 它是否含有能够绕过边界，从而绕过保护的方法变量？
  

有了这种思想之后，对于一些安全性的风险代码为了防止暴露，我们可以做一些操作，说限制对变量的访问，让每个量的方法都成为Final，尽量使你的类不要被克隆，如果一旦允许被克隆，它可能会绕过这个类轻易地复制类的属性。安卓中很多会使用到序列化，如果自己觉得这个类是有风险的，或者说安全性是很高的，尽量不要让它序列化。最后是避免硬编码影响数据。
Android M 和 N 的安全更新

2015 年 8 月份谷歌发布了 Android 6.0 版本，其中很大一部分变化，是在用户权限授权上，谷歌意识到之前默认的授权有一定的问题，对于我们开发者来讲我们必须要掌握这一技能。谷歌列一些风险权限，比如说传感器、日历、变化、热像头、地理位置、麦克风等等，这些都是风险的权限。也就是说以后我们的 App 不能够随便地去拿一个权限，遇到这些风险权限的时候我们应该怎么办呢？我们就需要向用户申请。通常的做法谷歌在官方的文档中也给我们提供一个解决方案。
有了权限之后，在 2016 年 8 月份，谷歌发布了 Android 7.0 版本，其中做了一个权限的更新，除了之前获取信息之外，Android 7.0 开发者可以在不申请 Get 的情况下访问设备商的账户；可以通过限制对私有文件的访问，强化了应用间的访问；对应用间的共享安全做了一个拉开幅度改进；Android 7.0 对网络安全也进行了保护，移除了一些可以持久访问目标设备的标识。将不再使用用户签名的证书。还有完善了网络安全配置，开发人员可以更加放地进行一些网络安全配置。谷歌进行了设备加密机制，所有的设备必须要体工队密钥存储的硬件支持，系统存储空间和用户配置存储空间将会分开进行加密。
最后我想送给大家一句话：安全不是独行侠也是系统性的运维过程。以后我们想安全的时候，不能够老是考虑自身，而是应该把它放开、放远、放大去考虑，它是整个系统运维的过程。
Android 应用安全防护和逆向分析

---

CSDN 博客专家姜维（@尼古拉斯_赵四），分享的主题是《Android的应用防护策略和逆向分析》。防护从混淆和签名验证、反调试、Native方法手动注册、加固进行解析。逆向是分析工具、静态和动态两种方式做分析。
资源混淆，概念来自于腾讯，是为了解决微信APK包开发的问题。第二种方法是签名验证，很多人为了防止二次打包，做了一个签名验证，如果发现签名不一致的话就会封杀，当然这种方式只是一般的防护。最后一种是反调试检测，反调试检测是用于现在很多应用拿到一个参数进行调试，如果是动态分析的话会进行一些调试。

   
下面再来谈一下Native，这种方式也不是很多采用的，我们写过Native代码的话都知道，如果手头Java的应用，有一个特点就是Java-包名，方法一下就找到了，再对应一下Native的属性就可以了。这种方式比较敏感，所以这里边可以用手动注册，其实相当于现在有一些Java平台做的对Native的方法进行混淆。
最后一种方式，现在用得最多的安全策略就是加固，关于加固现在用的比较多的平台是梆梆、爱加密，还有娜迦以及BAT+360。它把原加密放到外壳里面，加密之后找个时机来释放它。
现在看看我们经常会逆向操作的工具，第一个可能用得比较多的是Apktools，第二种是Jadx，第三种可能是用得最多的是IDA。很多同学可能会遇到一些问题，如下图一个是QQ的、一个是微信的，他们抓住了Apktools的漏洞，他们把文件格式做了一些变动，导致会报一些异常，后面就不走了，它做了这些混淆，对于安卓本身系统去除文件没有任何影响，这里面要做的一个操作就是Apktools有源码，可以跟踪，把异常修复，修复之后就顺利了。

   
再来看一下静态方式分析，一般现在要掌握的就是Smail语法，静态方式在现阶段用动态方式没办法去做解决的方式去解决。比如说校验肯定需要用静态方式去分析，静态方式一般要求有三个点，要先学会搜索，最后可能加一些代码进行调试。搜索这一点说得很简单，但是它里面的东西还是很多，还是跟经验有关。
最近在写一个怎么把本地小视频分享到朋友圈里面，这个又借助另外一个突破口，你发送小视频的时候，那个页面肯定是有一个播放的，这边是一些邀请描述，上面是个发送，底下是一些可选项，就会发现你发送的这个小视频，定找到它的路径，你要先找到这个名字，可以把Activity的名字找出来，再到微信的源码里面去找，找到五个参数其实你就可以把本地的小视频的路径传到五个参数里面，就可以实现本地视频发送到朋友圈，微信做了一种校验，它的长度不能大于15秒，大小不能超过一兆，所以你本地应该是没有办法去做的。
还有一种方式，就是注入代码的方式，注入代码一般会找一些静态方式，静态方式如果也想达到这种效果，这时候比如说上面我们介绍清零的时候介绍了一个A方法，我们会在A方法的前面加一行日志，这里面注入代码一般会手动写一个Smail文件，这时候就可以定位，定位到签名校验的A方法，注入代码这种方式也是一种常用的。
动态方式用得也比较多，但是这种难度也是最大的，现在有两种方式，一种是Eclipes动态调试Smail代码。为什么这么做呢？它是一个完整的工程，动态调试就跟正常的Intent调试是一样的。第二种方式可能现在用得最多，也就是经常脱壳操作，就是IDA调试so代码，这个要解决一下反调试代码。再看看关键函数，这个就是Dex加密，最后有一点不管它前面怎么加密，它肯定加在里面运行的时候是解密之后的Dex，系统里面加载Dex的时候会用到下面这个函数，你只要在这个函数里面下个断点，得到这个函数有三个参数，表示这个Dex文件的长度，你可以在IDA里面写一个参数，把它挪到本地。有时候一些加固的平台不会调用这个函数，他会自己写一套，写一套之后他还会做一些操作，不敢怎么操作，都会先把Dex文件夹加入进去。我们只要在这几个函数里面下断点，再去得到他们的一些参数，这个过程中我现在说的是这样，真正操作的时候会发现很多问题，遇到很多挫折，我想说的是千万不要放弃，肯定会看到光明的。
最后再来看一下逆向的时候两个工具，首先第一个是Hook神器Xposed，它是Hook的，修改系统调试工具Mprop，这样在微信里面你发现有的人发地址，有的人发微信的时候底下的地理位置是假的。
在开发过程中，首先看一下Zip解压的漏洞，我们可以利用一些漏洞进行插件开发，从网上下载一些插件下来，它会做一些解压操作，这里面已经做了叙述，如果没有做叙述的话，安卓里面的解压文件是有类似于这样一种格式，以前可以范围它是返回到上级目录，我可以在Zip的环节写三个点点杠，利用应用本身的权限可以写一些数据，这样就比较危险了，修复的方案把文件名称的路径进行过滤。
第二个漏洞是最近做一些直播，游戏制博会录制屏幕，4.4以下的手机录了之后可以把编码重新再编一下，用现在的API去直接使用，当然这个API有一个问题，它需要授权。当然在授权的时候有一个文案说明，后面这个看左边的已经修复了，比如说现在一个应用名字写得非常非常地长，但是你会看到底下他并没有说刚开始你屏幕上录取的所有内容，我委托一个授权，右下角会有一个取消、立即开始，这就是一个简单的提示，一般用户会点击立即开始，这样就相当于授权了，你所有的操作都会被记录下来了，这种是操作之后会对文案做一个省略化。我们本身做一些应用需要做一些防护，比如说我们做一些银行的，还有社交的登陆界面，银行的个人信息、财务的信息什么东西，类似的页面如果不想被一些录制的应用的话，我们可以设置这样几个参数，这样设置完之后，我们的当前页面是不会被他们进行录制的，他们也获取不到相关的内容，这也是我们针对于第三方直播建立一种安全防护。
App安全增强——我来帮你写C++

---

花甲科技安全实验室负责人泮晓波发表《App安全增强》主题分享，现在大部分的移动端，如Android、IoT、iOS都会面临特别大的问题，如应用被逆向破解、升级迟缓、突发事件等。
从一个比较流行的Android系统的实例来说起，Android系统主要的代码全是Java，Java的代码很标准，大家可以根据所有的文档、各种逆向工具进行查阅，因此很容易被破解。但是针对C++的代码就没有那么地丰盛，C++难以破解的一点是在编译的过程中会比Java的过程中放弃更多的或者会丢掉更多的细节。
我们知道这个点之后，如果我们有办法把一个代码从Java写的转换成C++写的，那是不是更难被破解呢？这就是我今天要跟大家分享的一个方案。
如果我们在源代码层面上进行转换的话，我们需要处理所有编译其要处理的东西，语法、词法，甚至一个引号都需要我们控制，但是Java翻译不是一个很好的地方。源码搞不定，我们看一下在Java字节码上能不能做？Java字节码是基于一个站的。

      

   
Java的代码，把核心的部分转换成C++的代码，它是可以提高很多的安全性，可以全部转换，也可以只转换一个函数，提高安全性上是有很大的帮助。
一个Java的Native程序，或者是一个Dalvik里面，虚拟机对能引用的对象是有限制的，我们没有办法设置一万个对象，虚拟机对它有250个最多的限制。这个循环如果跑到250个，甚至300个时候，虚拟机需要处理垃圾收集的功能，这里面的函数要求把这个对象覆盖掉，我们函数里面生成的那段代码里面应用的函数就非常地有限。
我们今天说的是一个安全增强方案的技术实现，跟加固的比较上有一个很大的区别。我们的点不是魔术，我们的方案是把它转换，我把它转换成另外一种方式，原先是电能的，我把它转化成会发光的光能，我们可以转化成化学能，今天的方案里面，Java讲C++就是它的一个特别的实例。
在整个流程里面，我们会引入一个叫做动态的安全防护，因为刚才最后一点介绍的方式，我们是可以推送一个基础的版本，发现一笔再推送一个小的东西。这里有部分的代码换掉，可以达到升级动态，甚至是说一旦发现有黑客在攻击我们的代码，可以推送另外一个程序的版本达到一个直接跟他对抗的目的。
黑无止境移动安全“漏洞”

知道创宇高级安全顾问锅涛从攻击客的角度看看安全是怎么发生的，未来安全的主战场就在云这一块。未来移动市场肯定会成为我们整个生活的主角，因为移动是主角，就会对移动端安全信息的窃取，以及我们资产的窃取等，有主角的地方就有伤害。我们看到国外安全发展的趋势，尤其是国际上比较知名的Owasp。

   
从黑客攻击的角度去分析未来攻击主战场，因为硬应用大家通过查阅书籍、网上、社区搜集资料都可以进行多方面的避免。但是黑客攻击的时候，发现攻击想要拿到的数据，就要去平衡一下攻击的成本，如果完全分析带来混淆，我就带来混淆防止别人能够快速分离出代码之间的逻辑。但是黑客也知道你做了大量比较，也就会换思路，就会从一个人的程序设计缺陷的漏洞利用，因为黑客最终是要拿到移动端和最终的核心数据库连接的信息，用户的信息，以及通过缺陷进行资产盗窃。黑客的攻击已经从一个应用发展到了一个逻辑。
黑客在发动任何一次攻击的时候，都有成本。做防护就是为了增加黑客攻击的成本，无论是做代码混淆还是加固，成本提高了黑客有可能就会放弃攻击，但是他会寻找新的突破口。这就是下面要跟大家说的移动端里面业务逻辑设计缺陷，为什么业务逻辑设计缺陷会成为未来的一个主要的方向。

• 应用逻辑是神一般地存在，老的程序员也是在劫难逃，因为业务的发展造成了程序员没法快速地去准备代码。
  
• 安全开发人员也不能安全避免应用设计缺陷。
  
• App本身的漏洞，一半的比例在业务漏洞上，而自己的逻辑漏洞没有一个自动化的程序促使全员去发现它。
  
• 业务逻辑漏洞利用的就是开发人员本身人的缺陷，造成了它逃逸于各种防护，无论是代码混淆、加固等等。
  

业务逻辑漏洞之所以会出现是因为业务发展迅速、开发水平不一、第三方缺陷、内部监管不严格也会出现这种漏洞发生。业务逻辑漏洞最常见的就是账号登陆限制的问题。还有安全性的问题，也会发现密码重置，还有的是采用手机号+我的验证码，就造成了黑客可以利用验证码进行破解，以及常见的另一种安全问题是App端的客户端应用。
随着我们业务的发展，发现在金融行业，以及在我们的社交领域另一种手势密码。手势密码安全其实还是可以的，但是手势密码有很多解锁，可以通过多种方式去对手势密码进行一个修改。最常见的有暴力破解，以及去修改这一个文件重置本地手势密码。
在很多的平台，安全数据的发送都跟我们App的测试接口息息相关，安全其实是方方面面的，我们不仅要关注应用漏洞，还有第三方接口漏洞也需要去关注。

免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！