app安全_app安全测试 - CSDN
  • 常见的 App 安全问题

    万次阅读 2016-12-23 15:32:36
    常见的 App 安全问题 据2015年第三季度移动安全报告显示,Android 16个行业 TOP 10 应用漏洞类别和数量中,Webview远程代码执行占到了第一位,第二位是Webview文明存储密码。这些领域涵盖大家平时工作领域,我们...

    常见的 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的测试接口息息相关,安全其实是方方面面的,我们不仅要关注应用漏洞,还有第三方接口漏洞也需要去关注。

    展开全文
  • Android APP安全测试入门

    千次阅读 2015-05-24 10:17:57
    背景 最近这两年移动端真是非常...有句古语:”工欲善其事,必先利其器”,我们要研究App安全,没有几款高大上的神器是会非常麻烦的,因此本文主要给大家分享一下笔者学到的一些基础知识,主要是一些移动端测试辅助工

    背景

    最近这两年移动端真是非常火,每个单位或多或少都会有那么几款App,对于我们Web安全攻城师来说,App安全也需要或多或少的了解一些。年初单位来了一位对App安全略有研究的小伙伴,某日闲来无事教了笔者几招,分享给大家。有句古语:”工欲善其事,必先利其器”,我们要研究App安全,没有几款高大上的神器是会非常麻烦的,因此本文主要给大家分享一下笔者学到的一些基础知识,主要是一些移动端测试辅助工具的使用。

    模拟器

    模拟器笔者经常使用有两款,一款是BlueStacks,这款个人感觉是做的非常不错的,一般安装操作App非常流畅,不会有卡死的情况。另外一款就是SDK模拟器(Software Development Kit)了,这款是特别高大上的,类似虚拟机vm一样,可以建立多个虚拟机,安装不同的android系统。

    BlueStacks

    下载地址:

    安装的时候会提示安装”给力助手”,给力助手是辅助操作的,可以安装电脑上下载的app安装包到模拟器,也可以卸载已经安装的,还有很多针对模拟器的设置功能,如图:

    BlueStacks安装之后,安装APP,打开App界面如图:

     

    功能方面使用都非常简单,本文就不做介绍了。

    Software Development Kit

    下载地址:

    下载之后打开包中的eclipse,然后进行模拟器Android镜像的下载,包中自带的镜像是Android 5.0的镜像,建议下载老版本的,方便测试App,新版的镜像部分App在安装的过程中可能会有不兼容的情况。
    SDK Android镜像的下载如下图所示:

     

    下载完Android镜像之后就可以安装虚拟机了,具体如下:

     

    抓包神器

    抓app包的方法有很多种,比如手机设置代理用BurpSuite进行抓包,或者可以用fidder抓包。我比较习惯用一款小工具smsniff进行抓包,使用起来比较方便,抓到的包再放到Burpsuite进行修改提交等。工具如图:

    这款工具比较小巧,占用资源较少,有些时候用burp等抓包会发生错误,或者直接导致虚拟机上的app无法连接网络,用这款就不会发生以上说的情况。

     

    SDK小工具

    SDK中自带了几款很不错的小工具,我比较常用的有adb和emulator。ADB是一个客户端-服务器端程序,其中客户端是你用来操作的电脑,服务器端是android设备。SDK包中默认就有这俩款小工具

    Adb

    Adb命令如下:
    adb devices 查看启动的虚拟机设备,如图:

    adb install,安装app到已经打开的虚拟机中,如图:

    这样就将本地下载的app安装到了已经启动android虚拟机中了。
    adb shell,登录设备shell,如图:

    adb push,将电脑上的文件发送的android虚拟机上;adb pull,将android虚拟机上的文件发送到电脑上,如图:

    Adb命令非常强大,以上只是列出了比较基础的几个,详细的大家可以百度。

    Emulator

    Emulator命令我目前常用的就两招,启动android虚拟机,以代理模式启动android虚拟机。命令分别如下:

    1
    2
    Emulator @xiaomi
    Emulator -http-proxy 127.0.0.1:8080 @xiaomi

    其中xiaomi是我新建的android虚拟机的名字,设置代理启动之后,就可以用burp进行抓包了。

     

    反编译工具

    反编译app主要用apktool和d2j-dex2jar.bat,我比较常用的是dex2jar。
    Apktool反编译命令如下:

    1
    apktool.jar d e:\Appsec\xxx.apk

    命令执行之后会在apktool.jar所在目录下生成一个app的目录。
    d2j-dex2jra.bat反编译方法如下:
    用rar打开apk文件,将其中的classes.dex解压出来,然后执行命令d2j-dex2jar.bat d:\Appsec\xx\classes.dex
    执行完成之后会在d2j-dex2jar.bat相同目录下生成一个.jar的文件,可以用jd-gui.exe直接打开.jar来查看app的源代码,如图:

     

    案例分享

    App安全测试,我只能测测简单的,大多是权限绕过类的,比如绕过锁屏密码、任意用户登录等。基本都是因为app代码设计缺陷或者权限验证不足导致的。

    任意用户登录

    某次测试一个app,RP比较好,发现一任意用户登录漏洞。在本地的配置文件中有登录用户的帐号和密码,APP设计比较奇葩,只是验证了用户登录邮箱,没有验证密码,导致通过修改本地的配置文件就可以实现任意用户登录,登录之后能够查看别人的订单等数据。在android虚拟机中安装的app都在/data/data目录下,大概的目录结构如下:

    app安装目录下的结构都是差不多的,主要有缓存文件、数据库目录、本地文件、配置文件等。比较重要的目录有databases、shared_prefs。分别保存了数据库文件和配置文件。
    言归正传,查看了安装app的shared_prefs目录,发现其中一个文件内容如下:


    可以看到有用户的登录邮箱和密码,将邮箱修改成存在的用户邮箱,密码随意输入,然后adb shell之后,用linux命令删除android虚拟机上已经存在的配置文件,再用adb push将修改后的文件发送到android虚拟机,再打开app发现已经用其它用户成功登录了。

     

    写在最后

    APP安全接触的不多,技术比较菜,因此本文分享的基本都是工具的使用,比较基础。非常感谢夕阳童鞋,是我的App安全启蒙老师


    转载:https://sobug.com/article/detail/7

    背景

    最近这两年移动端真是非常火,每个单位或多或少都会有那么几款App,对于我们Web安全攻城师来说,App安全也需要或多或少的了解一些。年初单位来了一位对App安全略有研究的小伙伴,某日闲来无事教了笔者几招,分享给大家。有句古语:”工欲善其事,必先利其器”,我们要研究App安全,没有几款高大上的神器是会非常麻烦的,因此本文主要给大家分享一下笔者学到的一些基础知识,主要是一些移动端测试辅助工具的使用。

    模拟器

    模拟器笔者经常使用有两款,一款是BlueStacks,这款个人感觉是做的非常不错的,一般安装操作App非常流畅,不会有卡死的情况。另外一款就是SDK模拟器(Software Development Kit)了,这款是特别高大上的,类似虚拟机vm一样,可以建立多个虚拟机,安装不同的android系统。

    BlueStacks

    下载地址:

    安装的时候会提示安装”给力助手”,给力助手是辅助操作的,可以安装电脑上下载的app安装包到模拟器,也可以卸载已经安装的,还有很多针对模拟器的设置功能,如图:

    BlueStacks安装之后,安装APP,打开App界面如图:

     

    功能方面使用都非常简单,本文就不做介绍了。

    Software Development Kit

    下载地址:

    下载之后打开包中的eclipse,然后进行模拟器Android镜像的下载,包中自带的镜像是Android 5.0的镜像,建议下载老版本的,方便测试App,新版的镜像部分App在安装的过程中可能会有不兼容的情况。
    SDK Android镜像的下载如下图所示:

     

    下载完Android镜像之后就可以安装虚拟机了,具体如下:

     

    抓包神器

    抓app包的方法有很多种,比如手机设置代理用BurpSuite进行抓包,或者可以用fidder抓包。我比较习惯用一款小工具smsniff进行抓包,使用起来比较方便,抓到的包再放到Burpsuite进行修改提交等。工具如图:

    这款工具比较小巧,占用资源较少,有些时候用burp等抓包会发生错误,或者直接导致虚拟机上的app无法连接网络,用这款就不会发生以上说的情况。

     

    SDK小工具

    SDK中自带了几款很不错的小工具,我比较常用的有adb和emulator。ADB是一个客户端-服务器端程序,其中客户端是你用来操作的电脑,服务器端是android设备。SDK包中默认就有这俩款小工具

    Adb

    Adb命令如下:
    adb devices 查看启动的虚拟机设备,如图:

    adb install,安装app到已经打开的虚拟机中,如图:

    这样就将本地下载的app安装到了已经启动android虚拟机中了。
    adb shell,登录设备shell,如图:

    adb push,将电脑上的文件发送的android虚拟机上;adb pull,将android虚拟机上的文件发送到电脑上,如图:

    Adb命令非常强大,以上只是列出了比较基础的几个,详细的大家可以百度。

    Emulator

    Emulator命令我目前常用的就两招,启动android虚拟机,以代理模式启动android虚拟机。命令分别如下:

    1
    2
    Emulator @xiaomi
    Emulator -http-proxy 127.0.0.1:8080 @xiaomi

    其中xiaomi是我新建的android虚拟机的名字,设置代理启动之后,就可以用burp进行抓包了。

     

    反编译工具

    反编译app主要用apktool和d2j-dex2jar.bat,我比较常用的是dex2jar。
    Apktool反编译命令如下:

    1
    apktool.jar d e:\Appsec\xxx.apk

    命令执行之后会在apktool.jar所在目录下生成一个app的目录。
    d2j-dex2jra.bat反编译方法如下:
    用rar打开apk文件,将其中的classes.dex解压出来,然后执行命令d2j-dex2jar.bat d:\Appsec\xx\classes.dex
    执行完成之后会在d2j-dex2jar.bat相同目录下生成一个.jar的文件,可以用jd-gui.exe直接打开.jar来查看app的源代码,如图:

     

    案例分享

    App安全测试,我只能测测简单的,大多是权限绕过类的,比如绕过锁屏密码、任意用户登录等。基本都是因为app代码设计缺陷或者权限验证不足导致的。

    任意用户登录

    某次测试一个app,RP比较好,发现一任意用户登录漏洞。在本地的配置文件中有登录用户的帐号和密码,APP设计比较奇葩,只是验证了用户登录邮箱,没有验证密码,导致通过修改本地的配置文件就可以实现任意用户登录,登录之后能够查看别人的订单等数据。在android虚拟机中安装的app都在/data/data目录下,大概的目录结构如下:

    app安装目录下的结构都是差不多的,主要有缓存文件、数据库目录、本地文件、配置文件等。比较重要的目录有databases、shared_prefs。分别保存了数据库文件和配置文件。
    言归正传,查看了安装app的shared_prefs目录,发现其中一个文件内容如下:


    可以看到有用户的登录邮箱和密码,将邮箱修改成存在的用户邮箱,密码随意输入,然后adb shell之后,用linux命令删除android虚拟机上已经存在的配置文件,再用adb push将修改后的文件发送到android虚拟机,再打开app发现已经用其它用户成功登录了。

     

    写在最后

    APP安全接触的不多,技术比较菜,因此本文分享的基本都是工具的使用,比较基础。非常感谢夕阳童鞋,是我的App安全启蒙老师!

    展开全文
  • App安全测试

    千次阅读 2018-08-13 17:27:38
    目录   一、安装包测试   1.1、关于反编译   1.2、关于签名   1.3、完整性校验   1.4、权限设置检查 ...五、数据通信安全 ...六、组件安全测试 ...目的是为了保护公司的知识产权和安全方面的考虑等...

    目录

     

    一、安装包测试

     

    1.1、关于反编译

     

    1.2、关于签名

     

    1.3、完整性校验

     

    1.4、权限设置检查

     

    二、敏感信息测试

     

    三、软键盘劫持

     

    四、账户安全

     

    五、数据通信安全

     

    六、组件安全测试

     

    七、服务端接口测试

     

    一、安装包测试

     

    1.1、关于反编译

     

    目的是为了保护公司的知识产权和安全方面的考虑等,一些程序开发人员会在源码中硬编码一些敏感信息,如密码。而且若程序内部一些设计欠佳的逻辑,也可能隐含漏洞,一旦源码泄漏,安全隐患巨大。

     

    为了避免这些问题,除了代码审核外,通常开发的做法是对代码进行混淆,混淆后源代码通过反软件生成的源代码是很难读懂的,测试中,我们可以直接使用反编译工具(dex2jar和jd-gui工具)查看源代码,判断是否进行了代码混淆,包括显而易见的敏感信息。

     

    1.2、关于签名

     

    这点IOS可以不用考虑,因为APP stroe都会校验。但Android没有此类权威检查,我们要在发布前校验一下签名使用的key是否正确,以防被恶意第三方应用覆盖安装等。可使用下列命令检查:

     

    jarsigner -verify -verbose -certs apk包路径

     

    若结果为“jar 已验证”,说明签名校验成功。

     

    1.3、完整性校验

     

    为确保安装包不会在测试完成到最终交付过程中因为知足者趾问题发生文件损坏,需要对安装包进行完整性校验,通常做法是检查文件的md5值,而且一般可以通过自动化做校验。

     

    1.4、权限设置检查

     

    一般用户对自己的隐私问题十 分敏感,因此,我们需要对APP申请某些特定权限的必要性进行检查,如访问通讯录等。对于没有必要的权限,一般都建议开发 直接支除。

     

    Android:直接检查manifest文件来读取应用所需要的全部权限,并结合需求进行校验此权限是否为必须的。manifest文件的修改也需要关注,在增加新权限前需要进行评估。

     

    IOS:没有类似manifest文件来查看,IOS的用户权限只有在用户使用APP到了需要使用的权限时,系统才会弹出提示框,提示用户当前APP需要访问照片、联系人列表等组件。我们可以扫描代码来查看项目工程中有哪些权限设置。通过搜索关键类名,如通讯录一般需要访问ABAddressBookRef,照片是UIImagePickerController等。如果是纯黑盒测试,则必须覆盖到所有代码路径才能保证没有遗漏,也可使用代码覆盖率测试判断是否覆盖。

     

    二、敏感信息测试

     

    数据库是否存储敏感信息,某些应用会把cookie类数据保存在数据库中,一旦此数据被他人获取,可能造成用户账户被盗用等严重问题,测试中在跑完一个包含数据库操作的测试用例后,我们可以直接查看数据库里的数据,观察是否有敏感信息存储在内。一般来说这些敏感信息需要用户进行注销操作后删除。如果是cookie类数据,建议设置合理的过期时间。

     

    日志是否存在敏感信息,一般开发在写程序的过程中会加入日志帮助高度,所有可能会写入一些敏感信息,通常APP的发布版不会使用日志,但也不排除特殊情况。

     

    配置文件是否存在敏感信息,与日志类似,我们需要检查配置文件中是否包含敏感信息。

     

    三、软键盘劫持

     

    如果用户安装了第三方键盘,可能存在劫持情况,对此,我们在一些特别敏感的输入地方可以做检查,例如金融类APP登录界面的用户名密码输入框等,看是否支持第三方输入法,一般建议使用应用内的软键盘。

     

    四、账户安全

     

    4.1、密码是否明文存储在后台数据库,在评审和测试中需要关注密码的存储。

     

    4.2、密码传输是否加密,测试中我们需要查看密码是否被 明文传输,如果是HTTP接口,我们可以使用FIddler等工具直接查看。

     

    4.3、账户锁定策略。对于 用户输入错误密码次数过多的情况,是否会将账户临时锁定,避免被暴力破解,

     

    4.4、同时会话情况。一些应用对同时会话会有通知功能,这样至少可以让用户知识他的账户可能已经被泄漏了。在一定程度上能免提升用户体验。

     

    4.5、注销机制。在客户端注销后,我们需要验证任何的来自该用户的,需要身份验证的接口调用都不能成功。

     

    五、数据通信安全

     

    5.1、关键数据是否散列或加密。密码在传输中必须是加密的,其他敏感信息传输前也需要进行散列或者加加密,以免被中间节点获取并恶意利用。

     

    5.2、关键连接是否使用安全通信,例如HTTPS。在获知接口设计后我们需要评估是否其中内容包含敏感信息,如果未使用安全通信,需要知会开发修改。

     

    5.3、是否对数字证书合法性进行验证。即便使用了安全通信,例如HTTPS,我们也需要在客户端代码中对服务端证书进行合法性校验。测试中可以使用Fiddler工具模拟中间人攻击方法。如果客户端对于Fiddler证书没有校验而能正常调用,则存在安全隐患。

     

    5.4、是否校验数据合法性。在一些情况下,我们需要有方法来确保服务端下发的明文数据不被篡改。通常开发侧的实现方式是对数据进行数字签名并在客户端进行校验。我们可以模拟后台返回进行相关的测试工作。此外,对于其他一些客户端未进行数据校验的接口,我们也需要有意识地思考如果不进行校验是否会产生问题,并通过模拟后台返回验证。

     

    六、组件安全测试

     

    这里主要是指Android平台各个组件是否能被 外部应用恶意调用从而带来一些安全问题。包括Activity、Service、ContentProvider、Broadcast等等。采用的测试方法是通过使用drozer工具结合查看代码的方式,具体使用方法可查看官方文档。

     

    七、服务端接口测试

     

    主要关注服务端接口是否存在以下问题

     

    7.1、SQL注入

     

    7.2、XSS跨站脚本攻击

     

    7.3、CSRF跨站请求伪造

     

    7.4、越权访问

     

    除了上述服务端问题外,我们还需要结合实际的需求,设计和代码,分析是否需求或设计本身就会带来安全问题。

     

    举个例子:如一个购物的应用,下单地的流程包含两个接口,接口A返回订单详情,其中包括订单号码和金额总价。调用接口A后用户在客户端看到一个订单页面。用户点击提交后调用接口B,客户端传给接口B的参数为接口A返回的订单号码和金额总价,接口B的后台根据传给接口B的金额总价从用户账户中扣款,扣款成功后即根据订单号码发货。

     

    这一设计有什么问题呢?那就是接口B完全信任了客户端传入的金额总价而未做校验。恶意用户可以直接调用接口B,传入伪造的金额和真实订单号,这样就能以便宜的价格购物。

     

    附录

     

    1.软件权限

     

    1)扣费风险:包括短信、拨打电话、连接网络等。

     

    2)隐私泄露风险:包括访问手机信息、访问联系人信息等。

     

    3)对App的输入有效性校验、认证、授权、数据加密等方面进行检测

     

    4)限制/允许使用手机功能接入互联网

     

    5)限制/允许使用手机发送接收信息功能

     

    6)限制或使用本地连接

     

    7)限制/允许使用手机拍照或录音

     

    8)限制/允许使用手机读取用户数据

     

    9)限制/允许使用手机写入用户数据

     

    10)限制/允许应用程序来注册自动启动应用程序

     

    2.数据安全性

     

    1)当将密码或其它的敏感数据输入到应用程序时,其不会被存储在设备中,同时密码也不会被解码。

     

    2)输入的密码将不以明文形式进行显示。

     

    3)密码、信用卡明细或其他的敏感数据将不被存储在它们预输入的位置上。

     

    4)不同的应用程序的个人身份证或密码长度必须至少在4-8个数字长度之间。

     

    5)当应用程序处理信用卡明细或其它的敏感数据时,不以明文形式将数据写到其他单独的文件或者临时文件中。以防止应用程序异常终止而又没有删除它的临时文件,文件可能遭受入侵者的袭击,然后读取这些数据信息。

     

    6)党建敏感数据输入到应用程序时,其不会被存储在设备中。

     

    7)应用程序应考虑或者虚拟机器产生的用户提示信息或安全警告

     

    8)应用程序不能忽略系统或者虚拟机器产生的用户提示信息或安全警告,更不能在安全警告显示前,利用显示误导信息欺骗用户,应用程序不应该模拟进行安全警告误导用户。

     

    9)在数据删除之前,应用程序应当通知用户或者应用程序提供一个“取消”命令的操作。

     

    10)应用程序应当能够处理当不允许应用软件连接到个人信息管理的情况。

     

    11)当进行读或写用户信息操作时,应用程序将会向用户发送一个操作错误的提示信息。

     

    12)在没有用户明确许可的前提下不损坏删除个人信息管理应用程序中的任何内容。

     

    13)如果数据库中重要的数据正要被重写,应及时告知用户。

     

    14)能合理的处理出现的错误。

     

    15)意外情况下应提示用户。

     

    3.通讯安全性

     

    1)在运行软件过程中,如果有来电、SMS、蓝牙等通讯或充电时,是否能暂停程序,优先处理通信,并在处理完毕后能正常恢复软件,继续其原来的功能。

     

    2)当创立连接时,应用程序能够处理因为网络连接中断,进而告诉用户连接中断的情况。

     

    3)应能处理通讯延时或中断。

     

    4)应用程序将保持工作到通讯超时,进而给用户一个错误信息指示有链接错误。

     

    5)应能处理网络异常和及时将异常情况通报用户。

     

    6)应用程序关闭网络连接不再使用时应及时关闭,断开。

     

    4.人机接口安全测试

     

    1)返回菜单应总保持可用。

     

    2)命令有优先权顺序。

     

    3)声音的设置不影响使用程序的功能。

     

    4)应用程序必须能够处理不可预知的用户操作,例如错误的操作和同时按下多个键。

     

    展开全文
  • 常见App安全问题

    千次阅读 2018-06-02 11:24:34
    常见的 App 安全问题据2015年第三季度移动安全报告显示,Android 16个行业 TOP 10 应用漏洞类别和数量中,Webview远程代码执行占到了第一位,第二位是Webview文明存储密码。这些领域涵盖大家平时工作领域,我们所...

    常见的 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,尽量使你的类不要被克隆,如果一旦允许被克隆,它可能会绕过这个类轻易地复制类的属性。安卓中很多会使用到序列化,如果自己觉得这个类是有风险的,或者说安全性是很高的,尽量不要让它序列化。最后是避免硬编码影响数据。

    黑无止境移动安全“漏洞”

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

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

    黑客在发动任何一次攻击的时候,都有成本。做防护就是为了增加黑客攻击的成本,无论是做代码混淆还是加固,成本提高了黑客有可能就会放弃攻击,但是他会寻找新的突破口。这就是下面要跟大家说的移动端里面业务逻辑设计缺陷,为什么业务逻辑设计缺陷会成为未来的一个主要的方向。

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

    业务逻辑漏洞之所以会出现是因为业务发展迅速、开发水平不一、第三方缺陷、内部监管不严格也会出现这种漏洞发生。业务逻辑漏洞最常见的就是账号登陆限制的问题。还有安全性的问题,也会发现密码重置,还有的是采用手机号+我的验证码,就造成了黑客可以利用验证码进行破解,以及常见的另一种安全问题是App端的客户端应用。

    随着我们业务的发展,发现在金融行业,以及在我们的社交领域另一种手势密码。手势密码安全其实还是可以的,但是手势密码有很多解锁,可以通过多种方式去对手势密码进行一个修改。最常见的有暴力破解,以及去修改这一个文件重置本地手势密码。



    展开全文
  • APP的登录认证与安全

    万次阅读 2018-09-28 17:13:07
    一、登录机制 粗略地分析, 登录机制主要分为登录验证、登录保持、登出三个部分。... 登录认保持是指客户端登录后, 服务器能够分辨出已登录的客户端,并为其持续提供登录权限的服务器。登出是指客户端主动退出登录...
  • APP安全问题

    2019-04-08 10:34:58
    数据安全: 未防御屏幕录制: 在一些涉及隐私的操作界面,禁止屏蔽录屏/截图事件。可以在一定程度上避免用户的信息泄露 解决: //禁止截屏 this.getWindow().addFlags(WindowManager.LayoutParams.FLAG_...
  • App安全二三事

    千次阅读 2018-06-04 18:22:33
    首先插播一条自己的广告——有些朋友可能都知道了,我最近创建了一个知识星球,在...App安全二三事 客户端防作弊,是一个很重要,但又很难做好的事情,矛与盾永远是道高一尺,魔高一丈。 为什么要安全 现在几...
  • 移动APP安全测试

    千次阅读 2018-11-06 16:07:34
    1 移动APP安全风险分析 1.1 安全威胁分析 安全威胁从三个不同环节进行划分,主要分为客户端威胁、数据传输端威胁和服务端的威胁。 1.2 面临的主要风险 1.3 Android测试思维导图   1.4 反编译工具 ...
  • 移动APP安全测试要点

    万次阅读 2018-08-02 15:46:44
    安全检测要点 Allowbackup漏洞 WebView漏洞 关键数据明文传输 任意账号注册 登录界面可被钓鱼劫持 有争议的整改建议 关键数据明文传输 登录界面钓鱼劫持 总结 评估思路 移动APP面临的威胁 ...
  • Android APP安全测试Checklist

    万次阅读 2018-04-19 11:15:27
    前言此文档旨在大家提供Android平台APP安全风险与漏洞相关的一般性Checklist,保障安全评估测试的基础质量与效率。配置安全发布状态检查该类漏洞的审查场景:发布的代码未启用代码混淆、未关闭调试模式、未关闭不必...
  • iOS app安全技术总结

    万次阅读 2018-02-14 09:54:33
    iOS app安全技术总结 很多开发者认为,iOS系统的封闭性使APP更加安全。事实上,根据国外某安全服务商的最新调查显示:iOS前100名的付费应用中有87%均遭黑客破解。内购破解、源代码破解、本地数据窃取等,为iOS应用...
  • Android APP安全测试

    千次阅读 2018-03-31 22:59:34
    移动APP面临的威胁:木马、病毒、钓鱼、破解、篡改、二次打包、账号窃取、广告植入、信息劫持等一、Android APP安全测试思路分析:1.安全测试工具2.基础环境3.数据安全4.程序安全5.数据传输6.业务安全二、APP面临的...
  • APP安全测试总结

    千次阅读 2018-05-16 11:42:57
    收集整理网上的资料以及自己测试过程中遇到的问题前言APP 安全一直是开发者头痛的事情,越来越多的安全漏洞,使得开发者越来越重视app安全,目前app安全主要有由以下几部分APP组件安全Android 包括四大组件:...
  • Android手机App安全漏洞整理

    千次阅读 2019-06-12 16:36:39
    APP安全漏洞整理 1.源码安全漏洞 1.1 代码混淆漏洞 当前APK文件的安全性是非常令人堪忧的。APK运行环境依赖的文件/文件夹 res、DEX、主配文件Lib 只有简单的加密或者甚至没有任何加密。诸如apktool这类工具可轻易...
  • 手机App安全性测试初探

    千次阅读 2014-01-10 17:46:25
    目前手机App测试还是以发现bug为主,主要测试流程就是服务器接口测试,客户端功能性覆盖,以及自动化配合的性能,适配,压测等,对于App安全性测试貌似没有系统全面统一的标准和流程,其实安全性bug也可以是bug的一...
  • APP安全防护常见问题分析

    千次阅读 2017-10-10 14:32:45
    常见的 App 安全问题 据2017年上半年移动安全报告显示,近五年安卓端病毒数量呈直线上升趋势。到2016年,这一数字已大幅上升至1743万,预计2017全年病毒量将接近2000万。亚洲仍然是病毒重灾区,而中国2017年上半年...
  • 作为专业的移动互联网APP安全服务提供商爱加密来说,很早就开始着手于APP安全领域,为开发者们提供安全检测、应用保护、渠道检测等专业服务,全方位的保护APP安全,防止盗版、山寨、二次打包、注入恶意代码等现象的...
  • 移动APP安全涉及事项

    千次阅读 2018-05-15 15:48:17
    移动APP安全补充 1、内存、缓存移动设备很容易受到安全漏洞的影响,因为很容易访问到内部的缓存信息。开发一个应用程序,设定清理周期,智能进行缓存清理或输入密码进行清理。黑客为了解析我们的代码逻辑,从日志...
  • 来谈谈个人对APP安全这方面的一些见解吧。 一:APP的安全主要有几方面? 1.代码安全:  对于很多个人开发者或者公司来说,有些功能代码是自己独有的东西。最怕的就是自己的代码被被人窃取。在android市场上,...
  • iOS APP安全杂谈之二

    千次阅读 2015-12-24 18:26:45
    0x00 序 ...自从上一篇文章发了以后,参加乌云众...但是我依然感到幸运,因为今天可以为IOS APP安全杂谈写个续集。 上一节我们主要说了三点:IOS APP本地文件安全;HTTP/HTTPS下通信数据安全性的思考;非安全从
1 2 3 4 5 ... 20
收藏数 336,266
精华内容 134,506
关键字:

app安全