[转]Android安全防御 [很好 介绍和应对]

Android安全防御

标签: android安全app安全app防御
536人阅读 评论(15) 收藏 举报
分类:
 

目录(?)[+]html

  1. 各位大佬好今天谈一下我在实际项目开发中遇到的APP安全以及我作的防御
    1. 接下来细讲一下每一个安全监测的点文章最后给你们介绍一些监测工具你们能够玩玩
  2. 如今说一下安全检测的项目
    1. 1客户端安全测试包含
    2. 2敏感信息安全包含
    3. 3密码软键盘
    4. 4安全策略
    5. 5手势密码
    6. 6通讯安全
    7. 7业务安全
    8. 8这里我多介绍一个通常黑客进行攻击确定不会是用手机进行多用模拟器进行攻击如今的模拟器基本和手机同样咱们没法过滤全部的模拟器可是能够过滤免费的模拟器也就是必定程度上进行防御
    9. 9短信验证最好是作60秒倒计时
    10. 10App测试安全等级划分
    11. 11工具及相关资源
    12. 12说了以后会说一下代码检测
    13. 13在这简单提一下加密
 

各位大佬好,今天谈一下我在实际项目开发中遇到的APP安全以及我作的防御

  • Android开发者经常面临的一个问题就是防破解、 防二次打包。现现在,安全问题愈来愈重要,愈来愈多 的Android开发者也开始寻求安全的保护方案。首先说一下,我作的是保险行业的应用。因此有不少安全监测的东西要过。其实通常的公司,外包什么的不多管APP的安全的。即便你的应用中集成了微信支付宝的支付。也不须要你自身作什么太多的安全性的东西
  • 今天我根据绿盟和360监测出来的报告说一下(因为国企,因此是花钱请绿盟和360进行监测的。有大佬要笑了,固然这个检测不是码云上面的检测,后面我也会给新手说一下码云的检测)

接下来细讲一下每一个安全监测的点。文章最后给你们介绍一些监测工具,你们能够玩玩

这里先说一下APK加固
- 防止二次打包(盗版)
- 防止逆向分析
- 防止调试及注入
- 防止应用数据窃取
- 防止木马病毒
- 防篡改(APK篡改工具:APK改之理,AndroidKiller)
以上的防御均可以用APP加固来实现,这里先说一下最简单的反编译,相信不少人都用过反编译工具。其实咱们正常打包出来的apk就是一个压缩包,你解压缩或者反编译基本就拿到了你这个应用的源代码。反编译工具:dex2jar(ApkToolkit) jd-gui 等。我使用的是
对你的apk解压缩后,你能够看到以下:

当你对你的应用进行加固之后,你再尝试着去反编译,我这里以360加固为例,你反编译以后的获得东西以下
未加固APK:

加固APK:

这里你们百度确定能看到一些什么360脱壳圣战啊什么的文章介绍,我想说那是扯淡的。不相信的朋友能够按照那些文章去试试。这里介绍一下国内的几个加固商

固然还有其余的加固厂商,好比百度、腾讯、阿里、通付盾、网易易盾。这里你们喜欢用哪一个就用哪一个。腾讯和阿里虽然是IT巨头,可是毕竟有些厂商是专业作这个的。这里我就不作推荐了,有些加固自带崩溃日志,数据分析等等。使用加固后可对以上进行有效的防御。加固APK以后:篡改后没法正常运行、没法正常动态调试、反动态注入没法注入、反编译没法获取到原dex代码或完整的dex代码、So文件的总体加密,使用自定义连接器的技术,对SO文件进行总体的加密,彻底阻止 IDA等逆向工具的静态分析。java

App采用加固(加壳)的最终目的是为了防止盗版、反编译、动态调试以及恶意注入行为等,但加固后仍有被脱壳的风险,可能这个时候你们可能就有疑惑了,还有 必要进行加固吗?答案是确定的,咱们举个例子:咱们的房子都会安装防盗门,但全世界几乎天天都会有一些家庭失窃,但人们并无由于安装了防盗门还被小偷偷了东西,今后放弃安装防盗门,加固其实就比如防盗门,并不能百分百保证不被脱壳,固然加固技术也在不断的提升和更新,咱们须要选择一款安全性高的加固产品。咱们能够过滤掉绝大部分人的恶意攻击

如今说一下安全检测的项目

1)客户端安全测试包含

  • 客户端程序保护
    – 描述:判断是否能反编译为源代码,是否存在代码保护措施
    – 测试:是否能经过用反编译工具查看源代码
    – 建议:建议客户端进行加壳处理防止攻击者反编译客户端,同时混淆客户端代码,而且必定要对核心代码进行代码混淆。
  • 安装包签名
    – 描述:客户端安装包是否正确签名。经过签名,能够检测出安装包在签名后是否被修改过。
    – 检测:利用二次打包工具可否成功打包运行
    – 建议:客户端使用从属方证书进行签名后进行发布而不是使用第三方开发商的证书进行签名,以防开发商内部监管异常,证书滥用的状况出现。
  • 应用完整性校验
    – 描述:测试客户端程序安装后,在每次启动时是否对自身文件进行完整性校验。
    – 检测:修改资源文件,二次打包可否运行
    – 建议:建议客户端在每次开机启动时进行客户端自身的应用完整性校验,在验证逻辑中不使用MANIFEST.MF中的数据做为验证凭证,同时需验证是否有不属于该客户端版本的新文件添加,验证过程于服务器端完成。
  • 组件安全
    – 描述:测试客户端是否包含后台服务、Content Provider、第三方调用和广播等组件,Intent权限的设置是否安全。应用不一样组成部分之间的机密数据传递是否安全。程序是否窃取手机用户的隐私信息。
    – 建议:建议在开发客户端时不要暴露内部组件,若是有特殊需求也需进行权限控制,令使用这些组件时须要申请相应权限。android

  • 总体解决:以上客户端程序保护可经过代码混淆配合apk加固所有解决git

2)敏感信息安全包含

  • 私有目录下的文件权限
    – 描述:测试客户端私有目录下的文件权限是否设置正确,非root帐户是否能够读,写,执行私有目录下的文件。
    – 检测:

    – 建议:私有目录下文件不可读写
  • SQLite数据库文件的安全性
    – 描述:敏感信息是否明文存储
    – 检测:检测数据库里面的重要信息,好比帐号密码之类的是否明文存储
    – 建议:重要信息进行加密存储
  • Logcat日志
    – 描述:检测客户端对应的Logcat日志是否会打印一些用户或服务器的敏感信息。
    – 检测:用ddms工具寻找敏感信息输出
    – 建议:具备敏感信息的调试信息开关必定要关闭。
  • 总体解决:对于安卓开发来说,咱们解决敏感信息问题就是对重要数据进行加密存储,log日志不打印敏感信息。我是真的见过帐号密码保存在本地明文存储的,因此切记加密存储重要信息

3)密码软键盘

  • 键盘劫持测试
    – 描述:测试客户端程序在密码等输入框是否使用自定义软键盘。安卓应用中的输入框默认使用系统软键盘,手机安装木马后,木马能够经过替换系统软键盘,记录应用的密码。
    – 检测:这个应该经过看就能看出来
    – 建议:建议客户端开发自定义软键盘而不是使用系统软件盘以防止键盘劫持攻击。
  • 软键盘安全性测试
    – 描述:测试客户端是否使用随机布局的密码软键盘。
    – 检测:仍是眼睛看
    – 建议:建议客户端对自定义软键盘进行随机化处理,同时在每次点击输入框时都进行随机初始化。
  • 屏幕录像测试
    – 描述:测试经过连续截图,是否能够捕捉到用户密码输入框的密码。
    – 检测:经过连续截图,是否能够捕捉到用户密码输入框的密码。
    – 建议:建议客户端针对第三方或系统截屏编写抵抗逻辑,例如屏蔽和截屏相关的函数或是当客户端处于进程栈顶层时将截屏图片用纯黑色图片对象进行覆盖。
  • 总体解决:键盘劫持通常都是要自定义键盘的,并且自定义的键盘不要长的和系统键盘同样就行,每次点击输入框时都进行随机初始化却是不必。由于不少银行的也没有这样作,并且作起来我认为困难仍是有的。以手机银行例,大多数银行采用自绘键盘代替系统键盘,防止了系统键盘监听行为,但有些开发者忽略了截屏保护,这样连续快速截屏,或者视频录制就能够获取用户的密码。下面代码是防截屏、视频录制的代码

    getWindow().addFlags(WindowManager.LayoutParams.FLAG_SECURE);// 防止屏幕截屏

4)安全策略

  • 密码复杂度
    – 描述:测试客户端程序是否检查用户输入的密码,禁止用户设置弱口令
    – 测试:修改设置用户名密码时,能够设置111111相似弱口令
    – 建议:建议在服务器编写检测密码复杂度的安全策略,并将其运用到帐号注册,密码修改等须要进行密码变动的场景,以防止攻击者经过弱密钥遍历帐户的方式进行暴力猜解。
  • 帐户锁定策略
    – 描述:测试客户端是否限制登陆尝试次数。防止木马使用穷举法暴力破解用户密码
    – 测试:错误密码登陆请求屡次(10次以上尚未就有问题了,通常都是3次)
    – 建议:建议在服务端编写帐户锁定策略的逻辑,当一天内屡次输入密码错误时进行帐号锁定以防止攻击者经过暴力猜解密码。
  • 会话安全设置
    – 描述:测试客户端在必定时间内无操做后,是否会使会话超时并要求从新登陆。超时时间设置是否合理。
    – 检测:客户端在必定时间内无操做(20分钟足够),是否会话超时登陆
    – 建议: 建议在客户端编写会话安全设置的逻辑,当10分钟或20分钟无操做时自动退出登陆状态或是关闭客户端。
  • 界面切换保护
    – 描述:检查客户端程序在切换到后台或其余应用时,是否能恰当响应(如清除表单或退出会话),防止用户敏感信息泄露
    – 检测:应用切换到后台但程序没有结束运行,再返回应用的时候是否有身份验证 ,手势密码或者登录密码。
    – 建议:建议客户端添加响应的逻辑,在进行进程切换操做时提示用户确认是否为本人操做。
  • 界面劫持保护
    – 描述:检查客户端是否对非正常的界面切换进行检测,并对用户进行提示。
    – 检测:界面被劫持时是否有提示
    – 建议: 因为Activity界面劫持攻击一般是将本身的页面附着在客户端之上,所以须要进行界面切换操做,所以使用界面切换保护的安全建议能够达到必定的效果。除此以外,由于Android进程栈的工做原理,建议开发客户端时针对进程栈进行相应的保护,可禁止其余进程放置于客户端之上。
  • UI信息泄露
    – 描述:检查客户端的各类功能,看是否存在敏感信息泄露问题。
    – 检测:好比登陆时,密码输入错误,APP是否会提示密码输入错误
    – 建议:建议用户名或密码输入错误均提示“用户名或密码错误”,若客户端同时还但愿保证客户使用的友好性,能够在登录界面经过舒适提示的方式提示输入错误次数,密码安全策略等信息,以防用户屡次输入密码错误致使帐号锁定。
  • 帐号登陆限制
    – 描述:测试可否在两个设备上同时登陆同一个账号。
    – 检测:测试可否在两个设备上同时登陆同一个账号。
    – 建议:建议在服务器进行帐号登录限制相应逻辑代码的编写,经过Session或数据库标志位的方式控制同一时间只有一个设备能够登录某一帐号。
  • 安全退出
    – 描述:验证客户端在用户退出登陆状态时是否会和服务器进行通讯以保证退出的及时性
    – 检测:客户端在用户退出登陆时,查看session是否可用
    建议:保证客户端和服务器同步退出,APP退出时服务器端的清除会话
  • 密码修改验证
    – 描述:验证客户端在进行密码修改时的安全性
    – 检测:是否存在原密码验证
    – 建议:建议在修改密码时,客户端及服务器系统增添原密码输入验证身份的逻辑,以防Cookie登录修改密码的攻击。
  • 私密问题验证
    – 描述:验证客户端是否存在忘记密码时的私密问题验证
    – 检测:相似于QQ的私密问题验证
    – 建议:我以为这个根据需求走,也不必定说这个就好。一个普通的APP这样搞,用户体验会不好。除非你作到了QQ那种地步github

  • 总体解决:无,一个一个搞吧,须要和后台配合着。这里只说一下界面劫持

    @Override
    protected void onPause() {
    // 若程序进入后台不是用户自身形成的,则须要弹出警示
    if (needAlarm) {
    // 弹出警示信息
    Toast.makeText(getApplicationContext(),
    "XX的登录界面被覆盖,请确认登录环境是否安全", Toast.LENGTH_SHORT).show();
    }
    super.onPause();
    }

    就是在登陆界面重写onPause方法。这个界面劫持只须要在登陆界面作防御。needAlarm是定义的变量,初始化为true,而后监听home键和返回键以及你自身登陆界面的其余activity的跳转。若是用户执行了监听的操做needAlarm赋值为false,说明是用户自身的操做,不是界面劫持。算法

5)手势密码

  • 手势密码复杂度
    – 描述:测试客户端手势密码复杂度,观察是否有点位数量判断逻辑
    – 检测:这个应该没有明确的,就是自身感觉吧
    – 建议:本身定标准吧数据库

  • 手势密码修改和取消
    – 描述:检测客户端在取消手势密码时是否会验证以前设置的手势密码,检测是否存在其余致使手势密码取消的逻辑问题
    – 检测:检测客户端在取消手势密码时是否会验证以前设置的手势密码,检测是否存在其余致使手势密码取消的逻辑问题
    – 建议:不该该存在其余致使手势密码取消的逻辑,客户端在取消手势密码时应验证以前设置的手势密码数组

  • 手势密码本地信息保存
    – 描述:检测在输入手势密码之后客户端是否会在本地记录一些相关信息,例如明文或加密过的手势密码。
    – 检测:找到存储文件,看其是否加密
    – 建议:应该进行加密浏览器

  • 手势密码锁定策略
    – 描述:测试客户端是否存在手势密码屡次输入错误被锁定的安全策略。防止木马使用穷举法暴力破解用户密码。由于手势密码的存储容量很是小,一共只有9!=362880种不一样手势,若手势密码不存在锁定策略,木马能够轻易跑出手势密码结果。手势密码在输入时一般以a[2][2]这种3*3的二维数组方式保存,在进行客户端同服务器的数据交互时一般将此二维数组中数字转化为相似手机数字键盘的b[8]这种一维形式,以后进行一系列的处理进行发送。

  • 手势密码抗攻击测试
    – 描述:验证是否能够经过插件绕过手势密码的验证页面

  • 总体解决:手势密码的后面两个检测我也没有遇到过。并且如今手势密码怎么说,可能我接触的不是不少吧。有兴趣的朋友能够找相关资料研究下

6)通讯安全

  • 通讯加密
    – 描述:验证客户端和服务器以前的通讯是否使用加密信道。
    – 检测:能够利用抓包软件进行查看
    – 建议:使用https或者是http+403端口进行通讯。

  • 关键数据加密和校验
    – 描述:测试客户端程序提交数据给服务端时,密码等关键字段是否进行了加密和校验,防止恶意用户嗅探和修改用户数据包中的密码等敏感信息。
    – 检测:抓包
    – 建议:建议帐号,密码,卡号,金额等进行加密处理,同时整个数据包进行二次加密,返回的敏感信息进行加密,同时返回数据包进行二次加密,而且使用增长随机因子的校验字段,而且肯定服务器逻辑标志位正确,在删除校验字段时服务器不响应提交的数据包。

  • 证书有效性验证
    – 描述:验证客户端和服务器之间是否存在双向验证的机制,同时确认此机制是否完善,服务器是否以白名单的方式对发包者的身份进行验证
    – 检测:抓包
    – 建议:建议客户端和服务器进行双向认证,而且服务器经过白名单的方式验证客户端证书以保证证书的有效性。

  • 访问控制
    – 描述:测试客户端访问的URL是否仅能由手机客户端访问。是否能够绕过登陆限制直接访问登陆后才能访问的页面,对须要二次验证的页面(如私密问题验证),可否绕过验证。
    – 检测:利用截包工具获取url,能用浏览器打开该url。
    – 建议:建议服务器进行相应的访问控制,控制对应页面仅能经过手机客户端访问。同时进行页面访问控制,防止绕过登录直接访问页面的非法访问。

  • 短信重放攻击
    – 描述:检测应用中是否存在数据包重放攻击的安全问题。是否会对客户端用户形成短信轰炸的困扰。
    – 建议:抓包
    – 建议:token和手机号一块儿,重放没法形成短信轰炸

7)业务安全

这个须要根据业务进行检测

8)这里我多介绍一个,通常黑客进行攻击确定不会是用手机进行,多用模拟器进行攻击。如今的模拟器基本和手机同样。咱们没法过滤全部的模拟器,可是能够过滤免费的模拟器,也就是必定程度上进行防御

  • 实践大多数免费的模拟器,都没有蓝牙的功能
BluetoothAdapter blueadapter = BluetoothAdapter
                                .getDefaultAdapter();
                        if ((blueadapter == null)
                                || (blueadapter.getAddress() == null && blueadapter
                                        .getName() == null)) {
                            MessageBox.promptDialog("请使用真实手机登录",
                                    LoginActivity.this);
                        }
  • 1
  • 2
  • 3
  • 4
  • 5
  • 6
  • 7
  • 8
  • 1
  • 2
  • 3
  • 4
  • 5
  • 6
  • 7
  • 8

固然else以后我是登陆操做,可是登陆前作了一些东西。这个就像消息推送同样,手机的惟一标识cid之类的绑定。这里只是给出个思路

9)短信验证,最好是作60秒倒计时。

10)App测试安全等级划分


11)工具及相关资源

12)说了以后会说一下代码检测

  • eclipse 使用插件findbugs
  • studio 使用lint
  • 至于码云,是你把代码上传上去,码云会为你检测你的代码。
  • 这个我随便截两张图给你们看一下,你们了解一下。一看大家就知道是什么了

    13)在这简单提一下加密

  • 加密分为对称加密和非对称加密

  • 区分对称加密和非对称加密。对称加密的加密密钥和解密密钥是相同的。非对称加密的加密密钥和解密密钥不一样
  • 对称加密
    – 特色:高效,存在密钥交换问题,安全度不如RSA,可是能胜任大部分加密
    – 明文P 加密方法E 密文E(P) 解密方法D 加密密钥K 解密密钥K’
    DK’(EK(P)) = P K = K’
    EK(P):这是加密

  • 对称加密是基于乘积加密的(乘积加密是结合了置换算法和转置算法,有兴趣能够了解一下)。而AES和DES都是基于乘积加密。AES加密比DES要高。可是如今也有3DES加密。

  • 非对称加密
    – 特色:安全性高,没有密钥交换问题,效率低
    – 明文P 加密方法E 密文E(P) 解密方法D 加密密钥K 解密密钥K’
    DK’(EK(P)) = P K != K’(公钥和私钥不同,可是同时产生)

  • 你们若是以为还能看,顶下鼓励一下,谢谢。有不妥之处也欢迎你们评论

 

 
10
0
 
 
 

 

相关文章
相关标签/搜索