背景:APP端上安全在谈什么

APP的每个业务场景都有其既定的运行模式,若被人为破坏就可认为是不安全的。举个栗子,比如秒杀场景:大量用户在特定时间点,通过点击抢购来秒杀优惠商品,从而营造一种紧迫而有噱头的营销场景,但如果能通过非法手段自动抢购、甚至提前开始刷接口抢购,那就彻底破坏了业务的玩法,这就是一种不安全的运行模式。再比如常用的用户拉新场景:新客获取成本高达200左右,所有产品的拉新投入都蛮高,如何获得真正的新用户而不是羊毛党也是拉新必须处理的事,一般而言,新设备+新账户是新用户的基本条件,但新账户的成本其实不高,大部分是要靠新设备来识别的,但如果能通过非法手段不断模拟新设备,那拉新投入获取的可能大部分都是无效的羊毛党,这也可看做是一种不安全的运行场景,甚至还有二次篡改,构建马甲APP等各种场景。而APP端上安全要做的就是甄别并防范这种异常场景的发生,简而言之它就是:一种确保官方APP既定业务模型中运行的能力。

APP端上安全体系应该具备哪些能力

一个安全体系要具备哪些能力呢,简单说可分两块:甄别与防御。即一:甄别运行环境是否安全的能力,二:针对不同的场景作出不同的防御的能力,场景千变万化,所以防御手段也没有一剑破万法的能力,基本都要根据具体的风险场景,产出不同的应对方案,但是整体涉及的流程基本一致,如下:

要做的事情就是围绕四个阶段构建不同的能力。先看第一阶段:风险场景的假设,预判有哪些风险场景,从AppStore或者官方应用市场下载,安装、正常使用,这是理想中的运行模式,但不安分的用户千千万,异常场景也多变,不存在一剑破万法的说法,这里人为做了一些场景归类:

从实践来看,安全模型必须覆盖的场景包含上述四类,即

一: 运行的APP非官方应用

这种情况一般是非法用户为了谋求特定的权益,对原装APP进行魔改二次打包后发布,这对于一些广告类、离线付费类APP是一种毁灭性的打击,最常见的就是一些APP会在闪屏页面投放广告,从而获取收益,但一旦这个业务逻辑被篡改绕过,那么广告收益直接归零;还有些情况APP被碰瓷,魔改一些功能,跳转到非官方设定的网站,比如在比较火的APP添加劫持逻辑,跳转到一些黄赌网站,这给官方APP带来的负面影响是难易估量的,如果不能自证清白,甚至还会面临法律上的追责。

二:业务的运转模型被篡改

简单的讲就是没有按照产品的既定玩法进行,就像文章开头的秒杀场景【电商平台的茅台抢购】,如果能通过API直接组单,那APP里点击的那批用户无论如何也抢不过插件;再比如有些签到的场景是为了促活,如果通过自动签到工具自动打卡,那促活的目的也无法达到,这也是要重点防控的一个场景。

三:运行的设备非目标设备

这种场景主要影响一些拉新、优惠权益等,甚至直接影响整体运营策略,简单举个例子,拉新场景中会投放大量的新人免单、直减券,基本等于免费领取权益,比如我们都经历过的打车软件、外卖软件、新电商产品上线等。全国有无数的专业羊毛党专注于这一场景,他们掌握大量手机号,可以注册大量新账号,同时能通过虚拟机、应用多开、复刻设备等手段无限冒充新设备,如果不加反制,优惠策略一上线,各种券基本全被这批人掠夺,被这种手段折磨致死的产品数不胜数,也几乎是每个电商平台的噩梦。

四:一些核心逻辑的泄漏

这不是端上特有的风险,比如代码泄漏这种,各方都有这种风险,只不过端上风险更高,因为APP是要上架发出去的,虽然经历过各种混淆与保护,但是用户最终还是能拿到可执行的APP包的,里面各种的核心的逻辑、秘钥都有潜在泄漏的风险,一旦泄漏,也是一种毁灭性的打击,比如某些音视频软件特有滤镜、转场、特效,这些算法是一个产品的核心,一旦破解,产品优势不再,如果防止逻辑代码的泄漏与破解也是安全必须关注的点。

覆盖上述场景的意思是要提供甄别的能力,针对不同的场景,抽象特征值并搜集上报,建立特定的模型,推导C端操作环境是否安全,之后上线不同的应对策略:比如直接退出应用、标记为风险用户等。

建设方案

甄别与防御是体系的核心,建设方案主要是围绕这两个主题展开,虽说名称是“端上安全体系”,但只依靠端自己是无法解决所有问题的,也无法将价值发挥到最大,仍需多端系统配合来完成整个体系的搭建,分工的基本原则是:端上侧重特征信息的搜集,云端负责整体策略的执行,根据上述场景,搭建示意如下:

按层次跟功能大致分四块,端、网关、业务后台、数据风控中心:

  • 端是信息的来源,负责信息采集上报,是安全体系建设的基石,所以端上采集信息的真实性、为完整性至关重要,同时端上也可以执行部分风险低,但收益高的拦截略,比如对于一些已经侦测到的马甲包,在上报用户信息之后,可以选择Crash,对于一些机器点击类的签到、秒杀场景,可以主动拦截请求,降低带宽压力。
  • 网关是第二层,一般处理一些具体规则类的拦截与信息采集,比如有些简单的规则检验,Header里是否携带必备的校验字段,如多开标识、模拟器标志等,如果携带则可以在这一层直接拦截,并沉淀到数据中心,既保证了信息的采集,又能减轻业务后台的压力,尤其对于一些秒杀类的场景非常有效。
  • 业务后台跟数据平台可以一起看做第三层,负责更复杂的模型建设跟业务落地,比如在什么样的节点,才有什么样的策略,比如在组单的时候,业务后台可根据风控侧的判断决定用户的优惠力度等

针对各个具体的场景会有具体的建设方案,

如何应对非官方APP:APP包识别

非法人员总是出于自己的权益来破解官方APP,定制一些逻辑再二次打包发布,比如对一些付费类APP,含广告类工具APP等,通过破解代码,并二次打包后就可以官方造成冲击,甚至是毁灭性的打击,对于这种场景如何甄别,又如何处理呢?拿Android为例,检测手段有签名校验、文件校验、包完整性校验等,一旦检测到风险就可以做出响应处理,在处理方式上也需要根据不同产品不同场景随机变动,比如工具类APP就Crash阻断,而对于一些有用户体系类的APP则可以先回传用户信息,用作用户画像,再做响应的处理,而处理的手段也可以根据风险等级的不同再做定制,甄别的技术手段可能是死的,但获取的收益一定要灵活。

如何应对非理想设备:设备识别与设备指纹

非理想设备最经典的就是文章开头的场景,拉新拉来一堆老羊毛党,说到底其实就是对于用户设备的定位追踪能力不足,对于这种场景的如何应对?这里单独说说设备指纹,设备指纹主要解决的如何定位一台设备的问题,在理想情况下,一台设备只有一个身份信息,它不因APP卸载、升级、HOOK伪装所改变,这在现在的互联产品生态中是非常困难的,困难主要来源于两个方面:一技术上的、一是法规上的,从技术上来讲,以Android端为例,它是一个开源的系统,每一行代码都不可信,任何通过官方API拿到的信息都可以被HOOK篡改,而指纹很大程度依赖API获得的设备特征信息,如果这些信息都不可信,那指纹的可信程度也会降低。另一方面,从法规上来讲,现在注重保护个人隐私,不可以随意获取用户信息,这一点有利于用户【包括羊毛党】,但是对于运营方却是不利的,信息越少越难定位到,因此,在隐私合规的前提下,仍需要多维度的获取更多的用户信息,从更多的维度定位到该用户。

具体如何执行?以Android为例,定位一台设备的信息有MAC、IMEI、IMSI、序列号、AndroidID、IP+UA、OAID、各种设备型号等,虽然信息很多,但单独任何一条的可信度都不高,比如之前的某盾、某盟都曾用MAC地址作为指纹,甚至有些产品直接用IMEI作为指纹,但网上利用XPOSED来篡改的插件比比皆是,通过官方API获取的分分钟被破解,但是可以对多种信息进行整合生成一个唯一可信的ID,这种方式获取的ID的稳定性要比单一的稳定性要高,原理示意如下:

简单来说:只有篡改了全部的设备特征信息,才会导致设备指纹更新,这会大幅提高设备逃逸的难度。设备指纹的另一个难题是如何识别虚拟设备,这里特指模拟器,每个新开的模拟器都可以看做是新设备,如果不能识别,同样无法解决设备跟踪的问题,尤其对于国内的Android生态来讲,问题更加严重,各种游戏厂商都有对应的手游模拟器,不仅支持多开,还原生支持篡改各种设备特征信息,可以算得上助纣为虐,在模拟器甄别与防控的层面能做的有如下几种:

  • 通过特征信息甄别【容易绕过】
  • 通过CPU架构甄别【ARM与SimpleX86】
  • 限定APP的运行平台

这里简单介绍下通过CPU架构甄别方式,就目前的硬件市场,几乎99.9%以上的手机设备都是基于ARM处理,而模拟器大部分是面向x86平台设计的,采用的是simplex86架构,两者采用的不一样缓存机制,ARM采用的哈弗架构将指令存储跟数据存储分开,分为I-Cache(指令缓存)与D-Cahce(数据缓存),CPU无法直接修改I-Cache【同步延迟导致不一致】,但Simpled X86架构的模拟器只有一块缓存,这一点导致两者在运行Self-Modifying Code【自修改代码】时会有不同的表现,可以借助这个特性进行甄别,示意如下

至此,设备的定位与跟踪能力基本已经具备,在用户在领券的节点,就可以从更多维度判断他当前的设备是否有资格享受这个权益,保障业务按既定模型运转。

当然还有更多的场景,比如应用多开、应用分身等,都要具体问题具体分析,但思路一致:特征搜集、甄别、防控,因为所有的不轨行为一定有迹可循,

如何应对非设定业务场景:场景识别与校验

每种业务都有其既定的运行模式,只有照章办事,运营才能获取最大的收益,这里特指一些可以通过自己的参与获得收益的场景,比如秒杀、签到、预约摇号等。一般而言,在这类场景下,破坏者可钻的空子有两个方向,一个是便利:通过插件自动预约,免得用户自己操作,适合摇号、签到类【签到领积分】;一个是速度,通过插件直接API请求,抢跑下单,获得收益,适合限时秒杀类的场景【各大平台强茅台】。以秒杀为例,通过营造紧迫而又刺激的氛围可以让活动更有意思,但如果能直接刷接口/或者通过插件抢跑,那就会破坏其公平性,影响用户的参与感,造成资产及口碑受损,这类场景如何应对?其实要做的事情分两块:一 识别请求是从APP发出来 , 二 识别是真实用户操作的,这两快一般会整体考虑,非APP端的请求往往伴随着非用户触发,多归结于脚本,所以识别“人”与识别“场景”殊途同归,具体有哪些手段可以用呢?

  • 扩展核心API接口的能力,承载更多逻辑
  • 通过埋点、用户操作轨迹分析识别用户
  • 启用端上特有能力校验,如短信验证码、行程码分析

如何拓展API接口的能力?比如预约接口其基础能力就是预约,如不特殊处理,PC上就完全可以复制APP端发出的请求,进而通过脚本预约,如要加以限制就必须拓展端上API能力,让其携带更多端上独有特征,同时服务端可以完成校验,形成一个闭环,比较容易理解的就是让APP端与服务端协商一套加解密通信协议,并假定协议无法破解,避免接口直刷,从而确保请求是从APP发出的,即使不是从APP发出的,也能被甄别出来,进而提高APP与服务端通信阶段的安全性。当然,无法破解只是理论上,实际上只要舍得投入成本,暴力破解并不是问题,这种就需要通过更多元的手段,不断更新迭代,持续做攻防,例如,为了保证加密算法的保密性,可以将其用c实现,并通混淆、加固、防探测等手段保证这个策略的正确执行;暴力堆积加密的类型、节点,提升秘钥的更新频率也是一种应对手段,而且,惩罚手段上也可以多元,同直接拦截相比,隐秘的搜捕,诱捕也是一种灵活收益的手段。

其次,基于埋点、用户操作行为的大数据分析是另一种更高级的防御手段,对于识别用户操作场景更加科学,正常的用户轨迹与插件类的访问轨迹会有很大的差异,直刷的目标明确,主攻几个关键接口,但正常用户访问会有一系列的曝光、点击等行为,并且每次的点击也会有各种零零散散的活体特征可以采集,比如点击的点位置、数量、力度、频率等,这些维度为用户识别提供了更广的操作空间。基于以上几点的模型示意如下:

最后一点,启用端上特有的校验能力,这个已经是最终的防御手段,在实在没有办法的情况才会采用的,因为这种手段很影响用户体验,由于采用的是端上特有的能力,比如短信验证码,必须真机才能收到,这就从根本上避免了插件类的直刷,所以可靠性确实所有手段中最高的,但体验差,成本高,所以算是最后一道防线。

如何应对核心逻辑的泄漏

这一块主要关注的是APP端的一些核心逻辑的破解或泄密,可以分两个方向,对外与对内,对外主要是APP包的逆向与破解,不法人员从发布上架的APP包中获取核心业务实现或其他敏感信息;而对内主要指工程安全,核心源码或秘钥的泄漏、误改等。

相应的防范策略也是分两块,对外的线上防破解可以从以下几点入手:

  • 利用代码混淆防APP逆向,一般而言官方会提供相应的能力,也可借助三方加固来提高混淆的力度
  • 核心源码、秘钥下沉,采用更难破解的方式实现,同时增加防外部调用的防范策略,比如Android采用C+混淆来处理
  • 为线上APP添加防调试与HOOK的能力,防止动态调试探测,
  • 添加防止代理与中间人劫持的能力,例如SSLPING等技术,避免被抓包探测
  • 从二次打包入手,添加签名、完整性检测的能力,防止被探测、篡改

而对内主要从工程安全角度推进,主要是做好代码的权责管理

  • 采用组件化开发模式,不同等级的基础能力、业务、核心逻辑做好隔离
  • 仓库单独部署,同时做好权责划分,代码、文档做好权限隔离
  • 加强秘钥、KEY的管控,开发与生产环境严格隔离

上述手段基本涵盖大部可预见的风险场景,即使未覆盖,也大概有类似的手段作为参考,无非就是抽象、搜集、判断、处理。

线上执行方案

最后一步是上线执行,上述的手段多种多样,但相互之间并非孤立运行,彼此可以相互穿插,灵活配合,不存在特定的章法,全看使用方的意图,如何探测,探测之后如何处理,是全杀还是放一部分,都看操刀者自己的运作,以应用多开场景为例,除了利用多开基础的多开检测手段,还可以配合设备指纹做更多的事情,有时虽然没有检测到多开,但是基于设备指纹的补刀,也能定位到问题设备,而在最后一步惩治处理中,不同处理手段也会获得不一样的收益:

类型 处理方式 最终收益优缺点
被动拦截 端上部署检测规则,检测到风险,100%在端上拦截处理【如Crash】 效果明显,但易被发现,徒增防御成本
被动捕获 检测到风险,在端上不处理,只上报,后端隐形标记或拦截 不易被发现,但长期运行收益比较局限
主动诱捕 人为制造有迹可循的漏洞,捕获后在端上不拦截或部分拦截,并上报,后端隐形标记 不易被发现,虚虚实实,操作空间更大,收益更大

理论上讲,APP技术层面不存在100%有效的安防策略,虚虚实实才是王道,敬畏,才是最有效的防御手段

总结与展望

目前国内APP的生态环境并不健康,甚至可以说野蛮,随着隐私策略收紧,APP所能获取的信息越来越少,安防也越来越难做,反之,刷子却越活越滋润,技术所面临的的挑战也更加棘手,安防注定是一个长期攻防的领域。最后,技术不能解决所有问题,最终还是要依赖法律的健全与全民意识提升。

APP端上通用安全体系建设相关推荐

  1. 移动端开发——APP端上H5容器化建设

    1. 背景 当前移动端和前端的结合愈加紧密,尤其是在偏重活动运营的电商App中,受制于App版本审核,具备研发成本低.可灵活发布等特点的H5页面受到青睐,使其在APP端上承接了越来越多的业务.然而H5 ...

  2. 饿了么物流移动端业务可用性监控体系建设

    作者简介 锦洋,负责饿了么蜂鸟APP的架构.研发等工作.目前关注的技术方向为移动端监控.移动端架构.移动端性能优化等方向. 在这个重视稳定性的年代,很多公司在移动端性能监控上花了很大的力气,对业务可用 ...

  3. 用PHP开发APP端微信支付

    用PHP开发APP端微信支付的一点个人心得 最近因为公司需求,要开发APP端上的微信支付,看了微信文档,感觉还不错,没有遇到太大的坑,需要注意的点不算太多. 写一个记事文档,作为备忘录. APP支付流 ...

  4. 【Axure电商原型】电商APP高保真原型+移动端通用版电商app模板+用户中心+会员体系+内容推荐+社区体系+运营推广+订单流程+运营活动+订单管理+售后及服务+秒杀专区+特惠推荐+高保真移动端电商

    作品名称:Axure电商产品移动端交互原型 –   作品类型:模板类   软件版本:Axure 8.0 兼容9.0  备注:非代码真实系统,适用于交互设计师或者产品经理. Axure原型演示及下载地址 ...

  5. 全民K歌跨端体系建设

    点击上方 前端Q,关注公众号 回复加群,加入前端Q技术交流群 作者: Edwiin,原文链接:https://xie.infoq.cn/article/e284b3a19e7937dc209a3d34 ...

  6. 史上最长最全!围绕故障管理谈SRE体系建设

    本文转载自dbaplus社群 id:dbaplus 本文根据石鹏老师在[deeplus直播第227期]线上分享演讲内容整理而成.(文末有获取本期PPT&回放的方式,不要错过) 石鹏 美图SRE ...

  7. 微信支付api的服务器上,服务器微信支付接口笔记(与app端对接)

    到这里,准备工作就算完成了. 支付流程步骤详解: 步骤1:用户在商户APP中选择商品,提交订单,选择微信支付. 这一步,app将相关订单信息提交给商户 步骤2:商户后台收到用户支付单,调用微信支付统一 ...

  8. KIR: Kwai Instant Recommend --端上智能在快手上下滑推荐取得APP时长+1%的应用实践

    1.背景 1.1.端上智能 端上智能是相对于云计算人工智能应用(如推荐.搜索)的概念:如工业界成熟的推荐系统方案,几乎都是通过云计算的算力,在海量候选集中搜索用户感兴趣的Feed,并通过复杂的精排模型 ...

  9. vivo 服务端监控体系建设实践

    作者:vivo 互联网服务器团队- Chen Ningning 本文根据"2022 vivo开发者大会"现场演讲内容整理而成. 经过几年的平台建设,vivo监控平台产品矩阵日趋完善 ...

  10. prd移动端通用产品需求文档+Axure高保真app社交订餐通用prd文档+产品业务说明+PRD功能性需求+移动端公工通用模板说明+需求分析+竞品分析+产品结构图+产品业务流程图+产品信息图+餐饮系统

    作品介绍:prd移动端通用产品需求文档+Axure高保真app社交餐饮通用prd文档+产品业务说明+通用prd文档+移动端公工通用模板++全局说明+需求分析+竞品分析+产品结构图+产品业务流程图+产品 ...

最新文章

  1. 学计算机科学与技术的专业特长,计算机科学与技术专业简历范文介绍
  2. 中用BBP公式计算_【真课堂】7年级信息技术:数据计算
  3. ibatis3 一对一搞定
  4. 中文 CentOS 攻略
  5. 触类旁通:那些关于 TBL$OR$IDX$PART$NUM 的诡异案例和知识
  6. oracle一对多个值,Oracle一张表中实现对一个字段不同值和总值的统计(多个count)...
  7. ubuntu安装vmware-tools
  8. 串口转usb驱动c语言程序,usb serial驱动下载-usb serial converter驱动下载 官方版usb转串口驱动程序-win7/8/10/xp32/64位-IT猫扑网...
  9. STM32 部分重映射和完全重映射
  10. 经典!智能车牌识别称重系统解决方案
  11. Android 获取设备号
  12. 陶哲轩等人用编程方法,推翻了60年几何难题「周期性平铺猜想」
  13. peel在Linux生成excel,zplane -
  14. (转)从奴隶到程序员的十年历程
  15. html个人简历制作
  16. 计算机硬件系统(一)
  17. 彻底解决Chrome浏览器劫持后显示“由贵单位管理(Managed by your organization)” 的解决办法
  18. 对亮神基于白名单Mshta.exe 执行 payload 第五季复现
  19. js实现datadog hostMap
  20. 渝粤教育 陕西师范大学 200951教育科学研究方法作业(高起专、专升本)

热门文章

  1. MacOS系统下matplotlib中SimHei中文字体缺失报错的解决办法
  2. 为啥点击种子迅雷显示forum.php,迅雷无法解析种子怎么回事_迅雷种子无法解析解决教程...
  3. 软件测试全套教程,软件测试自学线路图
  4. Eclipse启动提示“subversive connector discovery”
  5. 怎么检查计算机网络是连接,电脑怎么查看网络连接
  6. IDEA中Debug的使用
  7. 量子计算机未来猜想,太厉害了吧?这台量子计算机能预测16种不同的未来​!...
  8. python对excel读写操作
  9. 合肥工业大学机器人技术期末_机器人技术试题及答案.doc
  10. 水仙花数,用scratch编程实现