Android安全防护

版权声明:本文为博主原创文章,未经博主允许不得转载。 https://blog.csdn.net/u013409903/article/details/76686155

各位大佬好,今天谈一下我在实际项目开发中遇到的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等逆向工具的静态分析。

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

现在说一下安全检测的项目

1)客户端安全测试包含

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

  • 整体解决:以上客户端程序保护可通过代码混淆配合apk加固全部解决

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那种地步

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

    @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);
                        } 

当然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’(公钥和私钥不一样,但是同时产生)

  • 大家如果觉得还能看,顶下鼓励一下,谢谢。有不妥之处也欢迎大家评论

阅读更多
想对作者说点什么?

博主推荐

换一批

没有更多推荐了,返回首页