目录介绍
- 01.整体概述介绍
- 1.1 项目布景
- 1.2 思考问题
- 1.3 规划方针
- 1.4 收益剖析
- 02.市道抓包的剖析
- 2.1 Https三要素
- 2.2 抓包中心原理
- 2.3 搞定CA证书
- 2.4 打破CA证书校验
- 2.5 怎样搞定加解密
- 2.6 Charles原理
- 2.7 抓包原理图
- 2.8 抓包中心流程
- 03.避免抓包思路
- 3.1 先看怎样抓包
- 3.2 设置装备文件
- 3.3 数据加密处理
- 3.4 避免黑科技抓包
- 04.防抓包实践开发
- 4.1 App安全装备
- 4.2 封闭署理
- 4.3 证书校验
- 4.4 双向认证
- 4.5 避免挂载抓包
- 4.6 数据加解密
- 4.7 证书确定
- 4.8 Sign签名
- 4.9 其他的办法
- 05.架构规划阐明
- 5.1 整体架构规划
- 5.2 要害流程图
- 5.3 稳定性规划
- 5.4 降级规划
- 5.5 异常规划阐明
- 06.防抓包功用自测
- 6.1 网络恳求测验
- 6.2 抓包测验
- 6.3 黑科技挂载测验
- 6.4 逆向破解测验
01.整体概述介绍
1.1 项目布景
- 通讯安全是App安全检测过程中非常重要的一项
- 针对该项的主要检测手段便是运用中间人署理机制对网络传输数据进行抓包、阻拦和篡改,以查验App在中心链路上是否有安全漏洞。
- 确保数据安全
- 经过charles等东西能够对app的网络恳求进行抓包,这样这些信息就会被铲除的提取出来,会被不法分子进行运用。
- 不想被竞争对手逆向抓包
- 不想自身App的数据被别人轻而易举地抓包获取到,然后进行相似事务或数据剖析、爬虫或网络进犯等破坏性行为。
1.2 思考问题
- 开发项目的时候,都需求抓包,很多情况下即使是Https也能正常抓包正常。那么问题来了:
- 抓包的原理是?任何Https的 app 都能抓的到吗?假如不能,哪些情况下能够抓取,哪些情况下抓取不到?
- 什么叫做中间人进犯?
- 运用HTTPS协议进行通讯时,客户端需求对服务器身份进行完好性校验,以承认服务器是实在合法的方针服务器。
- 假如没有校验,客户端或许与仿冒的服务器建立通讯链接,即“中间人进犯”。
1.3 规划方针
- 避免App被各种办法抓包
- 做好各种防抓包安全办法,避免各种黑科技抓包。
- 沉淀为技能库复用
- 现在只是针对App端有需求做防抓包办法,后期其他事务线或许也有这个需求。因而下沉为东西库,傻瓜式调用很有必要。
- 该库终极规划方针如下所示
- 第一点:有必要是低侵略性,对原有代码改动少,最简略的参加是一行代码设置即可。彻底解耦合。
- 第二点:能够动态灵敏装备,支撑装备禁止署理,支撑装备是否证书校验,支撑装备域名合法性过滤,支撑阻拦器加解密数据。
- 第三点:能够检测App是否在双开,挂载,Xposed进犯环境
- 第四点:能够灵敏设置加解密的key,能够灵敏替换加解密办法,比方现在采用RC4,另一个项目想用DES,能够灵敏更换。
1.4 收益剖析
- 抓包库收益
- 进步产品App的数据安全,有必要对数据传输做好安全保护办法和完好性校验,以避免自身数据在网络传输中裸奔,甚至是被三方歹意运用或进犯。
- 技能的收益
- 下沉为功用根底库,能够方便各个产品线运用,进步开发的效率。避免跟事务解耦合。傻瓜式调用,低成本接入!
02.市道抓包的剖析
2.1 Https三要素
- 要清楚HTTPS抓包的原理,首要需求先说清楚 HTTPS 完成数据安全传输的作业原理,主要分为三要素和三阶段。
- Http传输数据现在存在的问题
- 1.通讯运用明文,内容或许被窃听;2.不验证通讯方的身份,因而或许遭遇假装;3.无法证明报文的完好性,所以有或许遭到篡改。
- Https三要素别离是:
- 1.加密:经过对称加密算法完成。
- 2.认证:经过数字签名完成。(因为私钥只要 “合法的发送方” 持有,其他人假造的数字签名无法经过验证)
- 3.报文完好性:经过数字签名完成。(因为数字签名中运用了消息摘要,其他人篡改的消息无法经过验证)
- Https三阶段别离是:
- 1.CA 证书校验:CA 证书校验发生在 TLS 的前两次握手,客户端和服务端经过报文取得服务端 CA 证书,客户端验证 CA 证书合法性,然后承认 CA 证书中的公钥合法性(大多数场景不会做双向认证,即服务端不会认证客户端合法性,这儿先不考虑)。
- 2.密钥洽谈:密钥洽谈发生在 TLS 的后两次握手,客户端和服务端别离依据公钥和私钥进行非对称加密通讯,洽谈取得 Master Secret 对称加密私钥(不同算法的洽谈过程细节略有不同)。
- 3.数据传输:数据传输发生在 TLS 握手之后,客户端和服务端依据洽谈的对称密钥进行对称加密通讯。
- Https流程图如下
2.2 抓包中心原理
- HTTPS抓包原理
- Fiddler、Charles等抓包东西,其实都是采用了中间人进犯的计划: 将客户端的网络流量署理到MITM(中间人)主机,再经过一系列的面板或东西将网络恳求结构化地出现出来。
- 抓包Https有两个打破点
- CA证书校验是否合法;数据传递过程中的加密和解密。假如是要抓包,则需求打破这两点的技能,无非便是MITM(中间人)假造证书和运用自己的加解密办法。
- 抓包的作业流程如下
- 中间人截获客户端向主张的HTTPS恳求,佯装客户端,向实在的服务器主张恳求;
- 中间人截获实在服务器的回来,佯装实在服务器,向客户端发送数据;
- 中间人获取了用来加密服务器公钥的非对称秘钥和用来加密数据的对称秘钥,处理数据加解密。
2.3 搞定CA证书
- Https抓包中心CA证书
- HTTPS抓包的原理仍是挺简略的,简略来说,便是Charles作为“中间人署理”,拿到了服务器证书公钥和HTTPS衔接的对称密钥。
- 条件是客户端选择信赖并装置Charles的CA证书,否则客户端就会“报警”并中止衔接。这样看来,HTTPS仍是很安全的。
- 装置CA证书到手机中有必要洗白
- 抓包运用内置的 CA 证书要洗白,有必要装置到体系中。而 Android 体系将 CA 证书又分为两种:用户 CA 证书和体系 CA 证书(必要Root权限)。
- Android从7.0开始约束CA证书
- 只要体系(system)证书才会被信赖。用户(user)导入的Charles根证书是不被信赖的。相当于能够理解Android体系增加了安全校验!
- 怎样绕过CA证书这种约束呢?已知有以下四种办法
- 第一种办法:AndroidManifest 中装备 networkSecurityConfig,App 信赖用户 CA 证书,让体系对用户 CA 证书的校验给予经过。
- 第二种办法:调低 targetSdkVersion < 24,不过这种办法谷歌商场有约束,意味着抓 HTTPS 的包越来越难操作。
- 第三种办法:挂载App抓包,VirtualApp 这种多开运用能够作为宿主体系来运转其它运用,运用xposed避开CA证书校验。
- 第四种办法:Root手机,把 CA 证书装置到体系 CA 证书目录中,那这个假 CA 证书便是真正洗白了,难度较大。
2.4 打破CA证书校验
- App版别怎样让证书校验安全
- 1.设置targetSdkVersion大于24,去掉清单文件中networkSecurityConfig文件中的system和user装备,设置不信赖用户证书。
- 2.公钥证书固定。指 Client 端内置 Server 端真正的公钥证书。在 HTTPS 恳求时,Server 端发给客户端的公钥证书有必要与 Client 端内置的公钥证书共同,恳求才会成功。
- 证书固定的一般做法是,将公钥证书(.crt 或许 .cer 等格式)内置到 App 中,然后创建 TrustManager 时将公钥证书加进去。
- 那么怎样打破CA证书校验
- 第一种:JustTrustMe 破解证书固定。Xposed 和 Magisk 都有相应的模块,用来破解证书固定,完成正常抓包。破解的原理大致是,Hook 创建 SSLContext 等触及 TrustManager 相关的办法,将固定的证书移除。
- 第二种:依据 VirtualApp 的 Hook 机制破解证书固定。在 VirtualApp 中参加 Hook 代码,然后运用 VirtualApp 翻开方针运用进行抓包。详细看:VirtualHook
2.5 怎样搞定加解密
- 现在运用对称加密和解密恳求和呼应数据
- 加密和解密都是用相同密钥。只要一把密钥,假如密钥露出,内容就会露出。可是这一块逆向破解有些难度。而破解解密办法便是用密钥逆向解密,或许中间人假充运用自己的加解密办法!
- 加密后数据镇统筹了安全性吗
- 不必定安全。中间人假造自己的公钥和私钥,然后阻拦信息,进行篡改。
2.6 Charles原理
- Charles相似署理服务器
- Charles 经过将软件自身设置成体系的网络拜访署理服务器,使得一切的网络恳求都会走一遍 Charles 署理,然后 Charles 能够截取经过它的恳求,然后我们就能够对其进行网络包的剖析。
- 截取设备网络封包数据
- Charles对应设置:将署理功用翻开,并设置一个固定的端口。默认情况下,端口号为:8888 。
- 移动设备设置:在手机上设置 WIFI 的 HTTP 署理。注意这儿的条件是,Phone 和 Charles 署理设备链接的是同一网络(同一个ip地址和端口号)。
- 截取Https的网络封包
- 正常情况下,Charles 是不能截取Https的网络包的,这触及到 Https 的证书问题。
2.7 抓包原理图
- Charles抓包原理图
- Android上的网络抓包原来是这样作业的
- Charles抓包
2.8 抓包中心流程
- 抓包中心流程要害节点
- 第一步,客户端向服务器主张HTTPS恳求,charles截获客户端发送给服务器的HTTPS恳求,charles假装成客户端向服务器发送恳求进行握手 。
- 第二步,服务器发回相应,charles获取到服务器的CA证书,用根证书(这儿的根证书是CA认证中心给自己颁布的证书)公钥进行解密,验证服务器数据签名,获取到服务器CA证书公钥。然后charles假造自己的CA证书(这儿的CA证书,也是根证书,只不过是charles假造的根证书),假充服务器证书传递给客户端浏览器。
- 第三步,与普经过程中客户端的操作相同,客户端依据回来的数据进行证书校验、生成密码Pre_master、用charles假造的证书公钥加密,并生成HTTPS通讯用的对称密钥enc_key。
- 第四步,客户端将重要信息传递给服务器,又被charles截获。charles将截获的密文用自己假造证书的私钥解开,取得并核算得到HTTPS通讯用的对称密钥enc_key。charles将对称密钥用服务器证书公钥加密传递给服务器。
- 第五步,与普经过程中服务器端的操作相同,服务器用私钥解开后建立信赖,然后再发送加密的握手消息给客户端。
- 第六步,charles截获服务器发送的密文,用对称密钥解开,再用自己假造证书的私钥加密传给客户端。
- 第七步,客户端拿到加密信息后,用公钥解开,验证HASH。握手过程正式完成,客户端与服务器端就这样建立了”信赖“。
- 在之后的正常加密通讯过程中,charles怎样在服务器与客户端之间充任第三者呢?
- 服务器—>客户端:charles接收到服务器发送的密文,用对称密钥解开,取得服务器发送的明文。再次加密, 发送给客户端。
- 客户端—>服务端:客户端用对称密钥加密,被charles截获后,解密取得明文。再次加密,发送给服务器端。因为charles一向具有通讯用对称密钥enc_key,所以在整个HTTPS通讯过程中信息对其通明。
03.避免抓包思路
3.1 先看怎样抓包
- 运用Charles需求做哪些操作
- 1.电脑上需求装置证书。这个主要是让Charles充任中间人,颁布自己的CA证书。
- 2.手机上需求装置证书。这个是拜访Charles获取手机证书,然后装置即可。
- 3.Android项目代码设置兼容。Google 推出更加严厉的安全机制,运用默认不信赖用户证书(手机里自己装置证书),自己的app能够经过装备处理,相当于信赖证书的一种操作!
- 特别可知抓包的打破口会集以下几点
- 第一点:有必要链接署理,且跟Charles要具有相同ip。思路:客户端是否能够判别网络是否被署理了。
- 第二点:CA证书,这一块避免运用黑科技hook证书校验代码,或许具有修正CA证书权限。思路:会集在能够判别是否挂载。
- 第三点:假充中间人CA证书,在客户端client和服务端server之间篡改阻拦数据。思路:能够做CA证书校验。
- 第四点:为了能够在7.0上抓包,App往往装备清单文件networkSecurityConfig。思路:线上环境去掉该装备。
3.2 设置装备文件
- 一个是CA证书装备文件
- debug包为了能够抓包,需求装备networkSecurityConfig清单文件的system和user权限,只要这样才会信赖用户证书。
- 一个是查验证书装备
- 不论是权威机构颁布的证书仍是自签名的,打包一份到 app 内部,比方寄存在 asset 里。然后用这个KeyStore去引导生成的TrustManager来供给证书验证。
- 一个是查验域名合法性
- Android允许开发者重界说证书验证办法,运用HostnameVerifier类查看证书中的主机名与运用该证书的服务器的主机名是否共同。
- 假如重写的HostnameVerifier不对服务器的主机名进行验证,即验证失利时也继续与服务器建立通讯链接,存在发生“中间人进犯”的危险。
- 怎样查看CA证书的数据
- 证书验证网站 ;SSL装备查看网站
3.3 数据加密处理
- 网络数据加密的需求
- 为了项目数据安全性,对恳求体和呼应体加密,那必定要知道恳求体或呼应体在哪里,然后才能加密,其实都一样不论是加密url里面的query内容仍是加密body体里面的都一样。
- 对数据哪里进行加密和解密
- 现在对数据回来的data进行加解密。那么怎样做数据加密呢?现在项目中采用RC4加密和解密数据。
- 抓取到的内容为乱码
- 有的APP为了避免抓取,在回来的内容上做了层加密,所以从Charles上看到的内容是乱码。这种情况下也只能反编译APP,研究其加密解密算法进行解密。难度极大!
3.4 避免黑科技抓包
- 依据Xposed(或许)黑科技破解证书校验
- 这种办法能够查看是否有Xposed环境,大概的思路是运用ClassLoader去加载固定包名的xp类,或许手动抛出异常然后捕获去判别是否包括Xposed环境。
- 依据VirtualApp挂载App打破证书拜访权限
- 这个VirtualApp相当所以一个宿主App(能够把它想像成桌面级App),它打破证书校验。然后再完成挂载App的抓包。判别是否是双开环境!
04.防抓包实践开发
4.1 App安全装备
- 增加装备文件
- android:networkSecurityConfig=”@xml/network_security_config”
- 装备networkSecurityConfig抓包阐明
- 中间人署理之一切能够获取到加密密钥便是因为我们手机上装置并信赖了其署理证书,这类证书装置后都会被归结到用户证书一类,而不是体系证书。
- 那我们能够选择只信赖体系内置的体系证书,而屏蔽掉用户证书(Android7.0以后就默认是只信赖体系证书了),就能够避免数据被解密了。
- 完成App防抓包安全装备办法有两种:
- 一种是Android官方供给的网络安全装备;另一种也能够经过设置网络结构完成(以okhttp为例)。
- 第一种:详细能够看清单装备文件,相当于base-config标签下去掉 这组标签。
- 第二种:需求给okhttpClient装备 X509TrustManager 来监听校验服务端证书有用性。遍历设备上信赖的证书,经过证书别名将用户证书(别名中含有user字段)过滤掉,只将体系证书增加到验证列表中。
- 该计划长处和缺点剖析阐明
- 长处:network_security_config装备简略,对整个app网络收效,无需修正代码;代码完成对经过该网络结构恳求的收效,能兼容7.0以前体系。
- 缺点:network_security_config装备办法,7.0以前的体系装备不收效,依然能够经过署理东西进行抓包。okhttp装备的办法只能对运用该网络结构进行数据传输的接口收效,并不能对整个app收效。
- 破解:将手机进行root,然后将署理证书放置到体系证书列表内,就能够绕过代码或装备查看了。
4.2 封闭署理
-
charles 和 fiddler 都运用署理来进行抓包,对网络客户端运用无署理形式即可避免抓包,如
OkHttpClient.Builder() .proxy(Proxy.NO_PROXY) .build()
-
no_proxy实际上便是type属性为direct的一个proxy目标,这个type有三种
- direct,http,socks。这样因为是直连,所以不走署理。所以charles等东西就抓不到包了,这样必定程度上确保了数据的安全,这种办法只是经过署理抓不到包。
-
通常情况下上述的办法有用,可是无法防住运用 VPN 导流进行的抓包
- 运用VPN抓包的原理是,先将手机恳求导到VPN,再对VPN的网络进行Charles的署理,绕过了对App的署理。
-
该计划长处和缺点剖析阐明
- 长处:完成简略方便,无体系版别兼容问题。
- 缺点:该计划比较粗犷,将一切署理都切断了,关于有合理诉求需求运用网络署理的场景无法满足。
- 破解:运用ProxyDroid全局署理东西经过iptables对恳求进行强制转发,能够有用绕过署理检测。
4.3 证书校验(单向认证)
- 下载服务器端公钥证书
- 为了避免上面计划或许导致的“中间人进犯”,能够下载服务器端公钥证书,然后将公钥证书编译到Android运用中一般在assets文件夹保存,由运用在交互过程中去验证证书的合法性。
- 怎样设置证书校验
- 经过OkHttp的API办法 sslSocketFactory(sslSocketFactory,trustManager) 设置SSL证书校验。
- 怎样设置域名合法性校验
- 经过OkHttp的API办法 hostnameVerifier(hostnameVerifier) 设置域名合法性校验。
- 证书校验的原理剖析
- 按CA证书去验证的,若不是CA可信赖的证书,则无法经过验证。
- 单向认证流程图
- 该计划长处和缺点剖析阐明
- 长处:安全性比较高,单向认证校验证书在代码中是方便的,安全性相对较高。
- 缺点:CA证书存在过期的问题,证书晋级。
- 破解:证书确定破解比较复杂,比方老牌的JustTrustMe插件,经过hook各网络结构的证书校验办法,替换原有逻辑,使校验失效。
4.4 双向认证
- 什么叫做双向认证
- SSL/TLS 协议供给了双向认证的功用,即除了 Client 需求校验 Server 的实在性,Server 也需求校验 Client 的实在性。
- 双向认证的原理
- 双向认证需求 Server 支撑,Client 有必要内置一套公钥证书 + 私钥。在 SSL/TLS 握手过程中,Server 端会向 Client 端恳求证书,Client 端有必要将内置的公钥证书发给 Server,Server 验证公钥证书的实在性。
- 用于双向认证的公钥证书和私钥代表了 Client 端身份,所以其是隐秘的,一般都是用 .p12 或许 .bks 文件 + 密钥进行寄存。
- 代码层面怎样做双向认证
- 双向校验便是自界说生成客户端证书,保存在服务端和客户端,当客户端主张恳求时在服务端也校验客户端的证书合法性,假如不是可信赖的客户端发送的恳求,则回绝呼应。
- 服务端依据自身运用语言和网络结构装备相应证书校验机制即可。
- 双向认证流程图
- 该计划长处和缺点剖析阐明
- 长处:安全性非常高,运用三方东西不易破解。
- 缺点:服务端需求存储客户端证书,一般服务端会对应多个客户端,就需求别离存储和校验客户端证书,增加校验成本,下降呼应速度。该计划比较合适对安全等级要求比较高的事务(如金融类事务)。
- 破解:因为在服务端也做校验,在服务端安全的情况下很难被攻破。
4.5 避免挂载抓包
- Xposed是一个牛逼的黑科技
- Xposed + JustTrustMe 能够破解绕过校验CA证书。那么这样CA证书的校验就形同虚设了,对App的危险性也很大。
- App多开运转在多个环境上
- 多开App的原理相似,都是以新进程运转被多开的App,并hook各类体系函数,使被多开的App认为自己是一个正常的App在运转。
- 一种是从多开App中直接加载被多开的App,如平行空间、VirtualApp等,另一种是让用户新装置一个App,但这个App本质上便是一个壳,用来加载被多开的App。
- VirtualApp是一个牛逼的黑科技
- 它破坏了Android 体系自身的阻隔办法,能够进行免root hook和其他黑科技操作,你能够用这个做很多在原来APP里做不到工作,于此一起Virtual App的安全要挟也不言而喻。
- 怎样判别是否具有Xposed环境
- 第一种办法:获取当前设备一切运转的APP,依据装置包名对运用进行检测判别是否有Xposed环境。
- 第二种办法:经过自造异常来检测堆栈信息,判别异常堆栈中是否包括Xposed等字符串。
- 第三种办法:经过ClassLoader查看是否现已加载了XposedBridge类和XposedHelpers类来检测。
- 第四种办法:获取DEX加载列表,判别其中是否包括XposedBridge.jar等字符串。
- 第五种办法:检测Xposed相关文件,经过读取/proc/self/maps文件,查找Xposed相关jar或许so文件来检测。
- 怎样判别是否是双开环境
- 第一种办法:经过检测app私有目录,多开后的运用途径会包括多开软件的包名。还有一种思路遍历运用列表假如出现相同的包名,则被认为双开了。
- 第二种办法:假如同一uid下有两个进程对应的包名,在”/data/data”下有两个私有目录,则该运用被多开了。
- 判别了具有xposed或许多开环境怎样处理App
- 现在运用VirtualApp挂载,或许Xposed黑科技去hook,前期能够先用埋点计算。测验学而思App发现挂载在VA上是推出App。
4.5 数据加解密
- 针对数据加解密入口
- 现在在网络恳求类里增加阻拦器,然后在阻拦器中处理request恳求和response呼应数据的加密和解密操作。
- 主要是加密什么数据
- 在request恳求数据阶段,假如是get恳求加密url数据,假如是post恳求则加密url数据和requestBody数据。
- 在response呼应数据阶段,
- 怎样进行加密:主张恳求(加密)
- 第一步:获取恳求的数据。主要是获取恳求url和requestBody,这一块需求对数据一块处理。
- 第二步:对恳求数据进行加密。采用RC4加密数据
- 第三步:依据不同的恳求办法结构新的request。运用 key 和 result 生成新的 RequestBody 主张网络恳求
- 怎样进行解密:接收回来(解密)
- 第一步:常规解析得到 result ,然后运用RC4东西,传入key去解密数据得到解密后的字符串
- 第二步:将解密的字符串组装成ResponseBody数据传入到body目标中
- 第三步:运用response目标去结构新的response,然后最终回来给App
4.7 证书确定
-
证书确定是Google官方比较引荐的一种校验办法
- 原理是在客户端中预先设置好证书信息,握手时与服务端回来的证书进行比较,以确确保书的实在性和有用性。
-
怎样完成证书确定
-
有两种完成办法:一种经过network_security_config.xml装备,另一种经过代码设置;
//第一种办法:装备文件 api.zuoyebang.cn 38JpactkIAq2Y49orFOOQKurWxmmSFZhBCoQYcRhK90= 9k1a0LRMXouZHRC8Ei+4PyuldPDcf3UKgO/04cDM90K=
//第二种办法:代码设置 fun sslPinning(): OkHttpClient { val builder = OkHttpClient.Builder() val pinners = CertificatePinner.Builder() .add(“api.zuoyebang.cn”, “sha256//89KpactkIAq2Y49orFOOQKurWxmmSFZhBCoQYcRh00L=”) .add(“api.zuoyebang.com”, “sha256//a8za0LRMXouZHRC8Ei+4PyuldPDcf3UKgO/04cDM1o=09”) .build() builder.apply { certificatePinner(pinners) } return builder.build() }
-
-
该计划长处和缺点剖析阐明
- 长处:安全性高,装备办法也比较简略,并能完成动态更新装备。
- 缺点:网络安全装备无法完成证书证书的动态更新,另外该装备也受Android体系影响,对7.0以前的体系不支撑。代码装备相对灵敏些。
- 破解:证书确定破解比较复杂,比方老牌的JustTrustMe插件,经过hook各网络结构的证书校验办法,替换原有逻辑,使校验失效
4.8 Sign签名
- 先说一下布景和问题
- api.test.com/getbanner?k…
- 这种办法简略粗犷,经过调用getbanner办法即可获取轮播图列表信息,可是这样的办法会存在很严重的安全性问题,没有进行任何的验证,我们都能够经过这个办法获取到数据,导致产品信息泄露。
- 在写开放的API接口时是怎样确保数据的安全性的?
- 恳求来历(身份)是否合法?恳求参数被篡改?恳求的唯一性(不行复制)?
- 问题的处理计划想象
- 处理计划:为了确保数据在通讯时的安全性,我们能够采用参数签名的办法来进行相关验证。
- 最终决议的处理计划
- 调用接口之前需求验证签名和有用时刻,要生成一个sign签名。先拼接-后转码-再加密-再发恳求!
- sign签名校验实践
- 需求对恳求参数进行签名验证,签名办法如下:key1=value1&key2=value2&key3=value3&secret=yc 。对这个字符串进行md5一下。
- 然后被sign后的接口就变成了:api.test.com/getbanner?k…
- 为什么在获取sign的时候主张运用secret参数?secret仅作加密运用,增加在参数中主要是md5,为了确保数据安全请不要在恳求参数中运用。
- 服务端对sign校验
- 这样恳求的时候就需求合法正确签名sign才能够获取数据。这样就处理了身份验证和避免参数篡改问题,假如恳求参数被人拿走,没事,他们永远也拿不到secret,因为secret是不传递的。再也无法假造合法的恳求。
- 怎样确保恳求的唯一性
- api.test.com/getbanner?k…
- 经过stamp时刻戳用来验证恳求是否过期。这样就算被人拿走完好的恳求链接也是无效的。
- Sign签名安全性剖析:
- 经过上面的事例,安全的要害在于参与签名的secret,整个过程中secret是不参与通讯的,所以只要确保secret不泄露,恳求就不会被假造。
05.架构规划阐明
5.1 整体架构规划
- 如下所示
5.2 要害流程图
5.3 稳定性规划
- 关于恳求和呼应的数据加解密要注意
- 在网络上交流数据(网络恳求数据)时,或许会遇到不行见字符,不同的设备对字符的处理办法有一些不同。
- Base64对数据内容进行编码来合适传输。准确说是把一些二进制数转成一般字符用于网络传输。通通变成可见字符,这样出错的或许性就大下降了。
5.4 降级规划
-
能够一键装备AB测验开关
.setMonitorToggle(object : IMonitorToggle { override fun isOpen(): Boolean { //todo 是否降级,假如降级,则不运用该功用。留给AB测验开关 return false } })
5.5 异常规划阐明
- base64加密和解密导致过错问题
- Android 有自带的Base64完成,flag要选Base64.NO_WRAP,否则末尾会有换行影响服务端解码。导致解码失利。
5.6 Api文档
-
关于初始化装备
NotCaptureHelper.getInstance().config = CaptureConfig.builder() //设置debug形式 .setDebug(true) //设置是否禁用署理 .setProxy(false) //设置是否进行数据加密和解密, .setEncrypt(true) //设置cer证书途径 .setCerPath("") //设置是否进行CA证书校验 .setCaVerify(false) //设置加密和解密key .setEncryptKey(key) //设置参数 .setReservedQueryParam(OkHttpBuilder.RESERVED_QUERY_PARAM_NAMES) .setMonitorToggle(object : IMonitorToggle { override fun isOpen(): Boolean { //todo 是否降级,假如降级,则不运用该功用。留给AB测验开关 return false } }) .build()
-
设置okHttp装备
NotCaptureHelper.getInstance().setOkHttp(app,okHttpBuilder)
-
怎样设置自己的加解密办法
NotCaptureHelper.getInstance().encryptDecryptListener = object : EncryptDecryptListener { /** * 外部完成自界说加密数据 */ override fun encryptData(key: String, data: String): String { LoggerReporter.report("NotCaptureHelper", "encryptData data : $data") val str = data.encryptWithRC4(key) ?: "" LoggerReporter.report("NotCaptureHelper", "encryptData str : $str") return str } /** * 外部完成自界说解密数据 */ override fun decryptData(key: String, data: String): String { LoggerReporter.report("NotCaptureHelper", "decryptData data : $data") val str = data.decryptWithRC4(key) ?: "" LoggerReporter.report("NotCaptureHelper", "decryptData str : $str") return str } }
5.7 防抓包功用自测
- 网络恳求测验
- 正常恳求,测验网络功用是否正常
- 抓包测验
- 装备fiddler,charles等东西
- 手机上设置署理
- 手机上装置证书
- 单向认证测验:进行网络恳求,会提示SSLHandshakeException即ssl握手失利的过错提示,即表明app端的单向认证成功。
- 数据加解密:进行网络恳求,看一下恳求参数和呼应body数据是否加密,假如看不到实际json实体则表明加密成功。