CN112039852A - 一种核心接口保护的方法、存储介质、电子设备及*** - Google Patents
一种核心接口保护的方法、存储介质、电子设备及*** Download PDFInfo
- Publication number
- CN112039852A CN112039852A CN202010789856.7A CN202010789856A CN112039852A CN 112039852 A CN112039852 A CN 112039852A CN 202010789856 A CN202010789856 A CN 202010789856A CN 112039852 A CN112039852 A CN 112039852A
- Authority
- CN
- China
- Prior art keywords
- interface
- data
- request
- core
- remote service
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Granted
Links
Images
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L63/00—Network architectures or network communication protocols for network security
- H04L63/04—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks
- H04L63/0428—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks wherein the data content is protected, e.g. by encrypting or encapsulating the payload
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L63/00—Network architectures or network communication protocols for network security
- H04L63/12—Applying verification of the received information
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/01—Protocols
- H04L67/02—Protocols based on web technology, e.g. hypertext transfer protocol [HTTP]
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/50—Network services
- H04L67/56—Provisioning of proxy services
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
- H04L9/08—Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
- H04L9/0816—Key establishment, i.e. cryptographic processes or cryptographic protocols whereby a shared secret becomes available to two or more parties, for subsequent use
- H04L9/085—Secret sharing or secret splitting, e.g. threshold schemes
Landscapes
- Engineering & Computer Science (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Computer Security & Cryptography (AREA)
- Computer Hardware Design (AREA)
- Computing Systems (AREA)
- General Engineering & Computer Science (AREA)
- Storage Device Security (AREA)
Abstract
本发明公开了一种核心接口保护的方法、存储介质、电子设备及***,涉及网络通信技术领域。该方法包括:创建远程服务进程;当APP要发起网络请求时,基于预设的总接口函数,确定发起请求的方式;当确定为代理形式时,APP将核心接口请求以HTTP GET请求形式发至远程服务进程;远程服务进程基于预设的接口拆分函数,将核心接口拆分为两类接口,利用第一类接口请求核心接口的接口数据,其中对于核心数据使用不准确数据;利用第二类接口请求准确的核心数据的解密秘钥;将接口数据通过代理形式返给APP,将解密出的准确核心数据,通过进程间通信返给APP。本发明能够有效防止黑客破解核心接口获取核心数据,保障核心接口的网络请求安全性。
Description
技术领域
本发明涉及网络通信技术领域,具体来讲是一种核心接口保护的方法、存储介质、电子设备及***。
背景技术
目前,随着网络通信技术的进步和宽带网络的提速,信息安全已经越来越重要,特别是对于服务器的一些核心接口,我们希望能够有一些保护手段来防止黑客进行破解或者盗刷。
但是,现有的客户端APP(Application,应用程序)通常都只有APP一个进程,所有的网络请求都是基于APP的网络库来进行访问,那么黑客可通过抓包工具或者通过编写的hook工具,来获取网络库的请求发送接口,从而可以分析请求了服务器的哪些接口以及接口参数,进而黑客可以模拟网络请求实现盗刷的功能。另外,现有的网络接口访问是基于https来保护数据,但是目前也都可以通过抓包工具来破解协议加密的功能,或者通过hook工具来查看APP有那些网络请求,安全性低。
因此,如何有效的对核心接口实现保护,避免黑客破解核心接口,从而保障核心接口的网络请求安全性,是本领域技术人员亟待解决的问题。
发明内容
本发明的目的是为了克服上述背景技术的不足,提供一种核心接口保护的方法、存储介质、电子设备及***,能够有效防止黑客破解核心接口获取核心数据,从而保障核心接口的网络请求安全性。
为达到以上目的,第一方面,本发明实施例提供一种核心接口保护的方法,其包括:
客户端创建远程服务进程,所述远程服务进程用于协助客户端的APP发送核心接口请求并返回请求数据;
当客户端的APP要发起网络请求时,基于预设的总接口函数,确定发起请求的方式;所述总接口函数用于判断网络请求是否为核心接口请求,若是,则确定发起请求的方式为代理形式,否则,确定为非代理形式;
当发起请求的方式确定为代理形式时,APP将核心接口请求以HTTP GET请求形式发送至所述远程服务进程;所述远程服务进程收到请求后,基于预设的接口拆分函数,将核心接口拆分为第一类接口和第二类接口,并利用所述第一类接口向服务器请求核心接口的接口数据,服务器返回的接口数据中,对于核心数据使用不准确数据,而准确的核心数据进行加密处理;同时利用所述第二类接口向服务器请求准确的核心数据的解密秘钥;
所述远程服务进程基于所述第一类接口获取到服务器返回的接口数据后,通过代理形式返回给APP;所述远程服务进程基于所述第二类接口获取到服务器返回的解密秘钥后,利用该解密秘钥解密出准确的核心数据,并通过进程间通信的方式返回给APP;
当发起请求的方式确定为非代理形式时,使用APP中的网络库进行网络请求功能。
作为一个优选的实施方案,所述远程服务进程收到请求后,基于预设的接口拆分函数,将核心接口拆分为第一类接口和第二类接口,并利用所述第一类接口向服务器请求核心接口的接口数据,具体步骤包括:
创建核心接口请求的基础类,所述基础类用于定义核心接口请求所需的功能接口;所述功能接口包括:头数据获取接口getHeader(),用于获取核心接口请求的请求头数据;body数据获取接口getBody(),用于获取核心接口请求的body数据;以及接口拆分函数list<CoreRequestBase*>splist(),用于将核心接口拆分为第一类接口和第二类接口,其返回值返回多个接口请求的实例列表;
所述远程服务进程收到请求后,基于所述接口拆分函数list<CoreRequestBase*>splist(),将核心接口拆分为第一类接口和第二类接口;
利用拆分后的第一类接口向服务器发送核心接口的接口数据请求,并通过调用getHeader()和getBody(),分别获取核心接口请求的头数据和body数据,其中,服务器返回的body数据中,对于核心数据使用不准确数据,而准确的核心数据进行加密处理。
作为一个优选的实施方案,当拆分后的第一类接口不止一个接口时,每个第一类接口用于向服务器请求核心接口的部分接口数据,所有第一类接口请求的部分接口数据能组合成完整的核心接口的接口数据;当拆分后的第二类接口不止一个接口时,每个第二类接口用于向服务器请求部分解密秘钥,所有第二类接口请求的部分解密秘钥能组合成完整的解密秘钥。
作为一个优选的实施方案,所述远程服务进程创建完成后,APP将该APP的进程ID以及所述远程服务进程的进程ID,通过进程间通信的方式发送给所述远程服务进程;且APP生成账号密码信息,并经加密后通过进程间通信的方式发送给所述远程服务进程;
所述远程服务进程利用所述第二类接口向服务器请求准确的核心数据的解密秘钥,具体步骤包括:
所述远程服务进程利用所述第二类接口向服务器发送解密秘钥请求,并携带所述账号密码信息、APP的进程ID以及远程服务进程的进程ID,且整个请求的所有数据均经加密后发送给服务器;
所述服务器收到解密秘钥请求后,利用解密后的所述账号密码信息、APP的进程ID以及远程服务进程的进程ID,进行客户端合法性的验证,若验证通过,则生成准确的核心数据的解密秘钥,并经加密后通过所述第二类接口返回给远程服务进程。
作为一个优选的实施方案,该方法还包括以下步骤:
当客户端的APP启动后,APP将创建一个检测线程,所述检测线程用于每当APP有网络请求要发生时都会检测一次当前***是否已设置***代理;
若已设置***代理,则APP只请求非核心接口的准确数据,对核心接口则只请求不准确的核心数据,而准确的核心数据则不请求;同时服务器对于所有的核心数据只返回不准确的数据;
若未设置***代理,则客户端将按照第一方面实施例中所述的方法进行操作。
作为一个优选的实施方案,所述APP将核心接口请求以HTTP GET请求形式发送至所述远程服务进程,具体步骤包括:
APP通过HTTP CONNECT方式请求与远程服务进程进行链接通信,并将核心接口的域名和端口发送给远程服务进程;当APP与远程服务进程链接成功后,APP将核心接口整个请求以加密的形式发送一个HTTP GET请求到所述远程服务进程中;所述远程进程收到请求后解密出请求。
作为一个优选的实施方案,该方法还包括以下步骤:
所述远程服务进程创建完成后,所述远程服务进程与APP共同完成共享秘钥的生成,所述共享秘钥用于两者之间数据交互的加解密;且所述远程服务进程与APP之间的所有数据交互均基于所述共享秘钥进行加密处理。
第二方面,本发明实施例提供一种核心接口保护的***,其包括:
客户端,所述客户端包括:
远程服务进程创建模块,其用于创建远程服务进程,所述远程服务进程用于协助客户端的APP发送核心接口请求并返回请求数据;
请求方式判定模块,其用于当客户端的APP要发起网络请求时,基于预设的总接口函数,确定发起请求的方式;所述总接口函数用于判断网络请求是否为核心接口请求,若是,则确定发起请求的方式为代理形式,否则,确定为非代理形式;
代理请求模块,其用于当发起请求的方式确定为代理形式时,控制APP将核心接口请求以HTTP GET请求形式发送至所述远程服务进程;控制远程服务进程收到请求后,基于预设的接口拆分函数,将核心接口拆分为第一类接口和第二类接口,并利用所述第一类接口向服务器请求核心接口的接口数据,所述接口数据中,对于核心数据使用不准确数据,而准确的核心数据进行加密处理;并控制远程服务进程利用所述第二类接口向服务器请求准确的核心数据的解密秘钥;
代理数据返回模块,其用于控制远程服务进程基于所述第一类接口获取到服务器返回的接口数据后,通过代理形式返回给APP;控制远程服务进程基于所述第二类接口获取到服务器返回的解密秘钥后,利用该解密秘钥解密出准确的核心数据,并通过进程间通信的方式返回给APP;
非代理请求模块,其用于当发起请求的方式确定为非代理形式时,使用APP中的网络库进行网络请求功能;
服务器,所述服务器包括:
数据返回模块,其用于收到远程服务进程通过所述第一类接口发来的请求后,向远程服务进程返回核心接口的接口数据,返回的接口数据中,对于核心数据使用不准确数据,而准确的核心数据进行加密处理;收到远程服务进程通过所述第二类接口发来的请求后,生成准确的核心数据的解密秘钥,并经加密后通过所述第一类接口返回给远程服务进程。
第三方面,本发明实施例还提供一种存储介质,其上存储有计算机程序,所述计算机程序被处理器执行时实现第一方面实施例中的方法。
第四方面,本发明实施例还提供一种电子设备,包括存储器和处理器,存储器上储存有在处理器上运行的计算机程序,所述处理器执行所述计算机程序时实现第一方面实施例中的方法。
本发明的有益效果在于:
本发明中通过在客户端创建一个远程服务进程,该远程服务进程与客户端中的APP是两个彼此独立的进程,即使黑客利用hook工具hook了APP进程,其也只能拦截APP的功能,而无法拦截到独立的远程服务进程。并且,该远程服务进程会开启一个网络代理功能,来协助APP发送核心接口请求并返回请求数据。基于该远程服务进程来代理请求核心接口,保障了核心接口的网络请求的安全性,也可以保障接口数据不被抓包工具所获取。因为核心接口请求在另一个独立的远程服务进程中发起,所以黑客通过hook客户端的APP程序,也无法获取到核心接口的数据。
除此之外,远程服务进程通过代理形式向服务器进行请求时,会基于预设的接口拆分函数,将传统核心接口拆分为第一类接口和第二类接口。通过第一类接口向服务器请求到核心数据不准确的接口数据,同时,通过第二类接口向服务器请求到准确的核心数据的解密秘钥,利用该解密秘钥可得到准确的核心数据。因此,客户端APP只有同时获取到上述两个数据,才能得到完整的且准确的核心接口的数据,这样就保障了核心接口的数据是经过了更为复杂的逻辑获取到的,进一步提高了盗刷的门槛,并且是无法通过抓包或者hook来获取所有准确的数据,有效防止了黑客破解核心接口获取核心数据,进而保障了核心接口的网络请求安全性。
附图说明
为了更清楚地说明本发明实施例中的技术方案,下面对实施例对应的附图作一简单地介绍,显而易见地,下面描述中的附图是本发明的一些实施例,对于本领域普通技术人员来讲,在不付出创造性劳动的前提下,还可以根据这些附图获得其他的附图。
图1为本发明实施例中一种核心接口保护的方法的流程图;
图2为本发明实施例中一种核心接口保护的***的结构框图。
图中:10-客户端,11-远程服务进程创建模块,12-请求方式判定模块,13-代理请求模块,14-代理数据返回模块,15-非代理请求模块;20-服务器,21-数据返回模块。
具体实施方式
针对现有技术中,对于核心接口的核心数据,非常容易被黑客通过抓包工具或者通过编写的hook工具破解,存在核心接口的网络请求安全性低的问题。本发明旨在提供一种核心接口保护的方法、存储介质、电子设备及***,能够有效防止黑客破解核心接口获取核心数据,从而保障核心接口的网络请求安全性。
为达到上述技术效果,本发明的主要设计思路为:
客户端创建远程服务进程,所述远程服务进程用于协助客户端的APP发送核心接口请求并返回请求数据;
当客户端的APP要发起网络请求时,基于预设的总接口函数,确定发起请求的方式;所述总接口函数用于判断网络请求是否为核心接口请求,若是,则确定发起请求的方式为代理形式,否则,确定为非代理形式;
当发起请求的方式确定为代理形式时,APP将核心接口请求以HTTP GET请求形式发送至所述远程服务进程;所述远程服务进程收到请求后,基于预设的接口拆分函数,将核心接口拆分为第一类接口和第二类接口,并利用所述第一类接口向服务器请求核心接口的接口数据,服务器返回的接口数据中,对于核心数据使用不准确数据,而准确的核心数据进行加密处理;同时利用所述第二类接口向服务器请求准确的核心数据的解密秘钥;
所述远程服务进程基于所述第一类接口获取到服务器返回的接口数据后,通过代理形式返回给APP;所述远程服务进程基于所述第二类接口获取到服务器返回的解密秘钥后,利用该解密秘钥解密出准确的核心数据,并通过进程间通信的方式返回给APP;
当发起请求的方式确定为非代理形式时,使用APP中的网络库进行网络请求功能。
综上所述,由于该方案中,通过创建一个独立的远程服务进程,来代理APP发送核心接口请求并返回请求数据,使得核心接口请求在一个独立的代理的远程服务进程中发起,所以黑客通过hook客户端的APP程序,也无法获取到核心接口的数据,保障了核心接口的网络请求的安全性,也可以保障接口数据不被抓包工具所获取。并且,远程服务进程通过代理形式向服务器进行请求时,将传统的单个核心接口请求,基于预设的接口拆分函数拆分为两类接口(第一类接口和第二类接口)请求。通过第一类接口向服务器请求到核心数据不准确的接口数据,同时,通过第二类接口向服务器请求到准确的核心数据的解密秘钥,利用该解密秘钥可得到准确的核心数据。因此,客户端APP只有同时获取到上述两个数据,才能得到完整的且准确的核心接口的数据,这样就保障了核心接口的数据是经过了更为复杂的逻辑获取到的,进一步提高了盗刷的门槛,并且是无法通过抓包或者hook来获取所有准确的数据,有效防止了黑客破解核心接口获取核心数据,进而保障了核心接口的网络请求安全性。
为使本发明要解决的技术问题、技术方案和优点更加清楚,下面将结合说明书附图以及具体的实施例对本发明的技术方案进行详细的说明。
但需说明的是:接下来要介绍的示例仅是一些具体的例子,而不作为限制本发明的实施例必须为如下具体的步骤、数值、条件、数据、顺序等。本领域技术人员可以通过阅读本说明书来运用本发明的构思来构造本说明书中未提到的更多实施例。
实施例一
参见图1所示,本实施例提供了一种核心接口保护的方法,该方法包括以下步骤:
步骤S1、客户端创建远程服务进程,该远程服务进程用于协助客户端的APP发送核心接口请求并返回请求数据,转入步骤S2。
本发明的实施例中,在客户端会创建一个远程服务进程,该远程服务进程与客户端中的APP是两个独立的进程,使用进程间通信来进行数据交互,由于两个进程是彼此独立的,即使黑客利用hook工具hook了APP进程,其也只能拦截APP的功能,而无法拦截到独立的远程服务进程。并且,该远程服务进程会开启一个网络代理功能,来协助APP发送核心接口请求并返回请求数据。基于该远程服务进程来代理请求核心接口,保障了核心接口的网络请求的安全性,也可以保障接口数据不被抓包工具所获取。因为核心接口请求在另一个独立的远程服务进程中发起,所以黑客通过hook客户端的APP程序,也无法获取到核心接口的数据。
进一步地,作为一种优选的实施方式,在步骤S1之后,即远程服务进程创建完成后,该远程服务进程与APP可共同完成共享秘钥的生成,该共享秘钥用于两者之间数据交互的加解密。也就是说,本实施例中,一旦远程服务进程创建完成,该远程服务进程就会与APP共同生成共享秘钥。生成完共享秘钥后,后续远程服务进程与APP之间交换的所有数据则都基于对称加密算法使用共享秘钥来加解密。基于该共享秘钥,就保障了APP和远程服务进程才能够解密对方的数据,其他hook程序或者抓包程序都无法解密数据,从而进一步确保了接口数据的安全性。
具体来说,在一种可选的实施方式中,该远程服务进程与APP共同完成共享秘钥的生成,具体可包括以下操作:
(1)、远程服务进程在启动后,使用非对称算法生成一对秘钥(公钥和私钥);同时APP也会使用同样的非对称算法生成一对秘钥(公钥和私钥);
(2)、远程服务进程与APP通过进程间通信来交换彼此的公钥信息;交换后,远程服务进程和APP都基于各自的私钥和对方的公钥生成共享秘钥,此共享秘钥则是后续双方数据交互的加解密秘钥。
基于上述操作,实际应用中,可通过编写class Encrypt的类函数,来实现共享秘钥的生成。其具体内容可包括:
步骤S2、当客户端的APP要发起网络请求时,基于预设的总接口函数,确定发起请求的方式;所述总接口函数用于判断网络请求是否为核心接口请求,若是,则确定发起请求的方式为代理形式,转入步骤S3;否则,确定为非代理形式,转入步骤S6。
本发明实施例中,当APP要发起网络请求时,首先会基于预设的总接口函数,来确定发起请求的方式是代理形式还是非代理形式。该总接口函数会根据网络请求是否为核心接口请求,来确定发起请求的方式,若是核心接口请求,则确定为代理形式发;若是非核心接口请求(如普调接口请求),则确定为非代理形式(即使用APP中的网络库进行网络请求功能)发。由于对于核心接口请求,APP是通过远程服务进程代理的形式发出的,这样就可以保障APP中没有发生过对核心接口的直接请求,从而任何的hook工具都无法hook到APP对核心接口的请求。同时对于大量盗刷接口的行为,本实施例使用远程服务进程代理的形式,可以起到服务器来识别客户端行为的作用,因为对于盗刷的黑客来说,由于其是使用服务器模拟大量客户端的请求,所以其无法使用代理的形式来盗刷大量的请求,因此通过代理的形式,表明核心接口必须通过客户端的一个代理来请求,才能够正确访问,有效避免了大量盗刷接口的行为。
具体来说,本实施例中预设的总接口函数为virtual bool sendRequest(list<CoreRequestBase*>*reqeust)。此函数内部会判断,当前的请求列表中,每个请求是使用代理发送还是不使用代理发送。通过遍历参数request,来对每个请求进行判断,是使用代理发送还是非代理发送。其中判断标准则是根据是否为核心接口请求的结果result来判断。其执行代码可为:
if(result){//根据是否为核心接口请求的结果result来判断
reutrn proxySend(request);//如果是核心接口请求,则通过代理发送请求,参数request则是需要发送的接口实例
}else{
return noProxySend(request);//如果是非核心接口请求,则通过非代理发送请求,参数request则是需要发送的接口实例。
}
步骤S3、当发起请求的方式确定为代理形式时,APP将核心接口请求以HTTP GET请求形式发送至所述远程服务进程;所述远程服务进程收到请求后,基于预设的接口拆分函数,将核心接口拆分为第一类接口和第二类接口,并利用所述第一类接口向服务器请求核心接口的接口数据,服务器返回的接口数据中,对于核心数据使用不准确数据,而准确的核心数据进行加密处理;同时利用所述第二类接口向服务器请求准确的核心数据的解密秘钥,转入步骤S4。
本发明实施例中,当客户端的APP发起核心接口请求时,为了能利用远程服务进程通过代理形式向服务器进行代理请求,该APP需要先将核心接口通过代理的形式发送给远程服务进程。具体来说,步骤S3中,APP将核心接口请求以HTTP GET请求形式发送至所述远程服务进程,具体步骤包括:
S311、APP通过HTTP CONNECT方式请求与远程服务进程进行链接通信,并将核心接口的域名和端口发送给远程服务进程;
S312、当APP与远程服务进程链接成功后,APP将核心接口整个请求以加密的形式发送一个HTTP GET请求到远程服务进程中(加密秘钥可使用上文中共同生成的共享秘钥来加密或其他协商好的加密秘钥);远程进程收到请求后解密出请求(解密秘钥也可使用上文中共同生成的共享秘钥来解密或其他协商好的解密秘钥)。
另外,可以理解的是,由于此时APP已与远程服务进程建立了代理关系,所以远程服务进程与APP之间具有两条通信通道的功能,一条通道是基于进程间通信,另一条通道是基于HTTP协议的代理功能。这两条通信通道为后续的请求数据的返回,提供了保障基础。
本发明实施例中,远程服务进程通过代理形式向服务器进行请求时,将传统的单个核心接口请求,利用预设的接口拆分函数拆分为两类接口(第一类接口和第二类接口)请求。通过第一类接口向服务器请求核心接口的接口数据,该接口数据中,对于核心数据使用不准确数据,而对准确的核心数据进行加密处理;同时,通过第二类接口向服务器请求准确的核心数据的解密秘钥,利用该解密秘钥可得到准确的核心数据。因此,客户端APP只有同时获取到上述两个数据,才能得到完整的且准确的核心接口的数据,这样就保障了核心接口的数据是经过了更为复杂的逻辑获取到的,进一步提高了盗刷的门槛,并且是无法通过抓包或者hook来获取所有准确的数据,有效防止了黑客破解核心接口获取核心数据,进而保障了核心接口的网络请求安全性。除此之外,拆分的验证接口,也能更好的便于服务器对客户端的验证,且验证接口与核心接口是分开的,还便于服务器进行解耦和功能独立。
并且,为了不影响现有APP的功能,保障APP能够正确的使用核心接口,使得APP的开发者不需要考虑核心接口的拆分功能,避免所有APP开发者需要去了解核心接口的拆分逻辑。因此,本实施例中将核心接口的拆分放到独立的远程服务进程中,从而可以达到对APP进程是透明的,从而不会影响到APP的功能开发。
具体来说,本实施例中远程服务进程通过第一类接口向服务器请求核心接口的接口数据后,服务器会返回该核心接口的正常数据,其中对于核心数据返回的是一个虚假的不准确数据,对于一些盗刷的客户端能够获取到该数据并进行展示,但是其数据并不准确。例如对于客户端中某直播类APP来说,其想要获取一个直播间的当前观看人数数量的信息(当前观看人数数量则认为是核心数据),那么服务器在核心接口的接口数据中返回的观看人数数量(核心数据),其数量是一个虚假的不准确数量,同时服务器会将真实的准确观看人数数量以加密的形式存储到返回的接口数据中,由于核心数据是加密数据,因此未获得解密秘钥的客户端无法进行解密。
基于上述设计原理,进一步地,作为一种优选的实施方式,步骤S3中,所述远程服务进程收到请求后,基于预设的接口拆分函数,将核心接口拆分为第一类接口和第二类接口,并利用所述第一类接口向服务器请求核心接口的接口数据,具体步骤包括:
S321、创建核心接口请求的基础类,如class CoreRequestBase,该基础类用于定义核心接口请求所需的功能接口,其中封装了核心接口的所有数据。具体来说,该基础类定义的功能接口包括:头数据获取接口getHeader(),用于获取核心接口请求的请求头数据;body数据获取接口getBody(),用于获取核心接口请求的body数据;以及接口拆分函数list<CoreRequestBase*>splist(),用于将核心接口拆分为第一类接口和第二类接口,其返回值返回多个接口请求的实例列表。当然,作为可选的,还可以在该基础类中定义秘钥设置接口set(string key),用于设置秘钥。举例来说,创建的核心接口请求的基础类,其代码可如下:
S322、所述远程服务进程收到请求后,基于基础类中定义的接口拆分函数list<CoreRequestBase*>splist(),将核心接口拆分为第一类接口和第二类接口;
S323、利用拆分后的第一类接口向服务器发送核心接口的接口数据请求,并通过调用getHeader()和getBody(),分别获取核心接口请求的头数据和body数据,其中,服务器返回的body数据中,对于核心数据使用不准确数据,而准确的核心数据进行加密处理。
更进一步地,作为一种优选的实施方式,在步骤S1之后,即远程服务进程创建完成后,APP会将该APP的进程ID以及远程服务进程的进程ID,通过进程间通信的方式发送给远程服务进程;并且,APP还会生成一个账号密码信息,并经加密后通过进程间通信的方式传递给远程服务进程,远程服务进程进行解密后,可获得客户端的账号密码信息。在上述操作的基础上,步骤S3中,远程服务进程利用所述第二类接口向服务器请求准确的核心数据的解密秘钥,具体步骤包括:
远程服务进程利用拆分后的第二类接口向服务器发送解密秘钥请求,并携带客户端的账号密码信息、APP的进程ID以及远程服务进程的进程ID,且整个请求的所有数据均经加密后发送给服务器,例如加密秘钥可以客户端的账号信息做为秘钥;
服务器收到解密秘钥请求后,先利用解密后的客户端的账号密码信息、APP的进程ID以及远程服务进程的进程ID,进行客户端合法性的验证,若验证通过(即客户端合法),服务器则生成一个准确的核心数据的加密秘钥,由于使用对称加密算法,所以加密秘钥也是解密秘钥,服务器将该加密秘钥(即解密秘钥)进行加密(例如以客户端的账号信息做为秘钥进行加密)后通过所述第二类接口返回给远程服务进程;若验证未通过(即客户端不合法),服务器则返回错误提示信息。
另外,可以理解的是,实际应用中为了进一步提高接口逻辑的复杂度,将核心接口拆分为第一类接口和第二类接口时,拆分后的第一类接口、第二类接口均包括至少一个接口,即第一类接口可为一个接口、两个接口或者多个接口,第二类接口可为一个接口、两个接口或者多个接口。当拆分后的第一类接口不止一个接口时,每个第一类接口用于向服务器请求核心接口的部分接口数据,所有第一类接口请求的部分接口数据能组合成完整的核心接口的接口数据;同理,当拆分后的第二类接口不止一个接口时,每个第二类接口用于向服务器请求部分解密秘钥,所有第二类接口请求的部分解密秘钥能组合成完整的解密秘钥。这种将第一类接口和第二类接口再次拆分成多个接口的方式,能进一步提高接口逻辑的复杂度,提升接口核心数据的安全性。
S4、远程服务进程基于所述第一类接口获取到服务器返回的接口数据后,通过代理形式返回给APP;所述远程服务进程基于所述第二类接口获取到服务器返回的解密秘钥后,利用该解密秘钥解密出准确的核心数据,并通过进程间通信的方式返回给APP,转入步骤S5。
可以理解的是,由于远程服务进程是代理,所以其会将服务器发来的接口数据通过代理的方式返回给APP,从而APP会收到自己想要请求的数据。但为了防止黑客通过hook客户端的APP程序,获取到核心接口的接口数据,因此,通过代理方式返回给APP的接口数据中,有关核心数据为不准确的数据。但与此同时,APP还会通过进程间通信的方式,从远程服务进程收到另一份解密后准确的核心数据。APP只有通过上述两个通道同时获取到上述两个数据,才能得到完整的且准确的核心接口的数据,这样就保障了核心接口的数据是经过了更为复杂的逻辑获取到的,并且是无法通过抓包或者hook来获取所有准确的数据,有效防止了黑客破解核心接口获取核心数据,进而保障了核心接口的网络请求安全性。
S5、APP根据远程服务进程通过代理形式返回的数据,以及通过进程间通信的方式返回的数据,得到完整且准确的接口数据。
进一步地,作为可选的实施方式,步骤S4中,远程服务进程利用所述解密秘钥解密出准确的核心数据后,可基于共享秘钥仅对准确的核心数据进行加密后,直接将加密的准确的核心数据通过进程间通信的方式返回给APP。远程服务进程还可在解密出准确的核心数据后,拷贝一份服务器返回的接口数据(该接口数据中核心数据为不准确的数据),并使用解密出的准确的核心数据只替换接口数据中不准确的核心数据,从而得到一份完整且准确的接口数据;然后基于共享秘钥对该份完整且准确的接口数据进行加密,并通过进程间通信的方式返回给APP。
在此基础上,步骤S5中,APP可根据共享秘钥解密出两个返回数据,并得到完整且准确的接口数据。其具体操作包括:若远程服务进程进程间通信的方式返回给APP的,仅是准确的核心数据,则APP会将该准确的核心数据替换接口数据中不准确的核心数据(通过代理的方式返回的),从而得到一份完整且准确的接口数据;若远程服务进程进程间通信的方式返回给APP的,是一份已经进行过核心数据替换的完整且准确的接口数据,则APP会将该数据覆盖掉通过代理的方式返回的接口数据(该接口数据中核心数据为不准确的数据),从而得到一份完整且准确的接口数据。
S6、当发起请求的方式确定为非代理形式时,使用APP中的网络库进行网络请求功能。
实施例二
本实施例提供的一种核心接口保护的方法,其基本步骤与实施例一相同,不同之处在于,作为一种优选的实施方式,该方法还包括以下操作:
当客户端的APP启动后,APP会创建一个独立的检测线程,该检测线程用于每当APP有网络请求要发生时都会检测一次当前***是否已设置***代理,且该检测线程会在整个APP的生命周期中持续执行;
若已设置***代理,则APP会告知客户端当前已开启了***代理,从而APP只请求普调接口(非核心接口)的准确数据,对核心接口则只请求不准确的核心数据,而准确的核心数据则不请求,也不会创建远程服务进程;同时,APP也会告知服务器当前客户端开启了***代理,使服务器对于所有的核心数据只返回不准确的数据,从而实现了一种双端(客户端、服务器端)保护的效果;
若未设置***代理,则客户端将按照实施例一中方法进行操作。
可以理解的是,本实施例在APP启动后,会创建独立的检测线程用来检测***是否已设置***代理,如果当前已经设置了***代理,那么客户端则不会创建远程服务进程,而只有在未设置***代理时,客户端才会创建远程服务进程来作为代理,这样避免在已经有代理的情况下,暴露作为代理的远程服务进程,***的代理则会屏蔽掉远程服务进程,进而导致出现异常,因为远程服务进程的代理是在***代理之后设置的,所以为了规避这种情况,避免出现异常,就需要在创建远程服务进程之前检测***的代理。
另外,本实施例中,检测线程是每次有网络请求发生时去检测,比惯用手段每间隔几秒去检测一次更好,这样的检测策略性能更好,减少了不必要的检测操作,降低了***负荷。具体实现来说,以Android***为例,检测方法的实现代码可如下:
String Host=android.net.Proxy.getDefaultHost();//通过***API获取代理的域名
int Port=android.net.Proxy.getDefaultPort();//通过***API获取代理的端口号。
如果当前Host(代理的域名)不为空并且Port(代理的端口号)不为空,则表明当前开启了***代理。
进一步考虑到Android***的兼容性,上述检测方法的实现可能存在一些机型上会获取失败,所以还提供了另一套检测方法的实现,其检测方法的实现代码可如下:
String Host=System.getProperty("http.proxyHost");
String Port=System.getProperty("http.proxyPort");
通过读取***属性信息来获取信息,如果当前Host不为空并且Port不为空,则表明当前开启了***代理。
实施例三
基于同一发明构思,如图2所示,本发明第三实施例提供一种核心接口保护的***,其包括:
客户端10,所述客户端10包括:
远程服务进程创建模块11,其用于创建远程服务进程,该远程服务进程用于协助客户端的APP发送核心接口请求并返回请求数据;
请求方式判定模块12,其用于当客户端的APP要发起网络请求时,基于预设的总接口函数,确定发起请求的方式;所述总接口函数用于判断网络请求是否为核心接口请求,若是,则确定发起请求的方式为代理形式,否则,确定为非代理形式;
代理请求模块13,其用于当发起请求的方式确定为代理形式时,控制APP将核心接口请求以HTTP GET请求形式发送至所述远程服务进程;控制远程服务进程收到请求后,基于预设的接口拆分函数,将核心接口拆分为第一类接口和第二类接口,并利用所述第一类接口向服务器请求核心接口的接口数据,所述接口数据中,对于核心数据使用不准确数据,而准确的核心数据进行加密处理;并控制远程服务进程利用所述第二类接口向服务器请求准确的核心数据的解密秘钥;
代理数据返回模块14,其用于控制远程服务进程基于所述第一类接口获取到服务器返回的接口数据后,通过代理形式返回给APP;控制远程服务进程基于所述第二类接口获取到服务器返回的解密秘钥后,利用该解密秘钥解密出准确的核心数据,并通过进程间通信的方式返回给APP;
非代理请求模块15,其用于当发起请求的方式确定为非代理形式时,使用APP中的网络库进行网络请求功能;
服务器20,所述服务器20包括:
数据返回模块21,其用于收到远程服务进程通过所述第一类接口发来的请求后,向远程服务进程返回核心接口的接口数据,返回的接口数据中,对于核心数据使用不准确数据,而准确的核心数据进行加密处理;收到远程服务进程通过所述第二类接口发来的请求后,生成准确的核心数据的解密秘钥,并经加密后通过所述第一类接口返回给远程服务进程。
前述方法实施例中的各种变化方式和具体实例同样适用于本实施例的***,通过前述方法的详细描述,本领域技术人员可以清楚的知道本实施例中***的实施方法,所以为了说明书的简洁,在此不再详述。
实施例四
基于同一发明构思,本发明第四实施例提供一种计算机可读存储介质,其上存储有计算机程序,该程序被处理器执行时实现如本发明任意实施例所提供的一种核心接口保护的方法,该方法包括:
客户端创建远程服务进程,该远程服务进程用于协助客户端的APP发送核心接口请求并返回请求数据;
当客户端的APP要发起网络请求时,基于预设的总接口函数,确定发起请求的方式;所述总接口函数用于判断网络请求是否为核心接口请求,若是,则确定发起请求的方式为代理形式,否则,确定为非代理形式;
当发起请求的方式确定为代理形式时,APP将核心接口请求以HTTP GET请求形式发送至远程服务进程;远程服务进程收到请求后,基于预设的接口拆分函数,将核心接口拆分为第一类接口和第二类接口,并利用所述第一类接口向服务器请求核心接口的接口数据,服务器返回的接口数据中,对于核心数据使用不准确数据,而准确的核心数据进行加密处理;同时利用所述第二类接口向服务器请求准确的核心数据的解密秘钥;
远程服务进程基于所述第一类接口获取到服务器返回的接口数据后,通过代理形式返回给APP;远程服务进程基于所述第二类接口获取到服务器返回的解密秘钥后,利用该解密秘钥解密出准确的核心数据,并通过进程间通信的方式返回给APP;
当发起请求的方式确定为非代理形式时,使用APP中的网络库进行网络请求功能。
本发明实施例的计算机存储介质,可以采用一个或多个计算机可读的介质的任意组合。计算机可读介质可以是计算机可读信号介质或者计算机可读存储介质。计算机可读存储介质例如可以是但不限于:电、磁、光、电磁、红外线、或半导体的***、装置或器件,或者任意以上的组合。计算机可读存储介质的更具体的例子(非穷举的列表)包括:具有一个或多个导线的电连接、便携式计算机磁盘、硬盘、随机存取存储器(RAM)、只读存储器(ROM)、可擦式可编程只读存储器(EPROM或闪存)、光纤、便携式紧凑磁盘只读存储器(CD-ROM)、光存储器件、磁存储器件、或者上述的任意合适的组合。在本文件中,计算机可读存储介质可以是任何包含或存储程序的有形介质,该程序可以被指令执行***、装置或者器件使用或者与其结合使用。
计算机可读的信号介质可以包括在基带中或者作为载波一部分传播的数据信号,其中承载了计算机可读的程序代码。这种传播的数据信号可以采用多种形式,包括但不限于电磁信号、光信号或上述的任意合适的组合。计算机可读的信号介质还可以是计算机可读存储介质以外的任何计算机可读介质,该计算机可读介质可以发送、传播或者传输用于由指令执行***、装置或者器件使用或者与其结合使用的程序。
计算机可读介质上包含的程序代码可以用任何适当的介质传输,包括但不限于:无线、电线、光缆、RF等等,或者上述的任意合适的组合。
可以以一种或多种程序设计语言或其组合来编写用于执行本发明操作的计算机程序代码,所述程序设计语言包括面向对象的程序设计语言,诸如Java、Smalltalk、C++,还包括常规的过程式程序设计语言—诸如“C”语言或类似的程序设计语言。程序代码可以完全地在用户计算机上执行、部分地在用户计算机上执行、作为一个独立的软件包执行、部分在用户计算机上部分在远程计算机上执行、或者完全在远程计算机或服务器上执行。在涉及远程计算机的情形中,远程计算机可以通过任意种类的网络,包括局域网(LAN)或广域网(WAN),连接到用户计算机,或者,可以连接到外部计算机(例如利用因特网服务提供商来通过因特网连接)。
实施例五
基于同一发明构思,本发明第五实施例还提供一种电子设备,包括存储器和处理器,存储器上储存有在处理器上运行的计算机程序,所述处理器执行所述计算机程序时实现第一、第二实施例中的所有方法步骤或部分方法步骤。
所称处理器可以是中央处理单元(Central Processing Unit,CPU),还可以是其他通用处理器、数字信号处理器(Digital Signal Processor,DSP)、专用集成电路(Application Specific Integrated Circuit,ASIC)、现成可编程门阵列(Field-Programmable Gate Array,FPGA)或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件等。通用处理器可以是微处理器或者该处理器也可以是任何常规的处理器等,所述处理器是所述计算机装置的控制中心,利用各种接口和线路连接整个计算机装置的各个部分。
所述存储器可用于存储所述计算机程序和/或模块,所述处理器通过运行或执行存储在所述存储器内的计算机程序和/或模块,以及调用存储在存储器内的数据,实现所述计算机装置的各种功能。所述存储器可主要包括存储程序区和存储数据区,其中,存储程序区可存储操作***、至少一个功能所需的应用程序(比如声音播放功能、图像播放功能等)等;存储数据区可存储根据手机的使用所创建的数据(比如音频数据、视频数据等)等。此外,存储器可以包括高速随机存取存储器,还可以包括非易失性存储器,例如硬盘、内存、插接式硬盘,智能存储卡(Smart Media Card,SMC),安全数字(Secure Digital,SD)卡,闪存卡(Flash Card)、至少一个磁盘存储器件、闪存器件、或其他易失性固态存储器件。
总体来说,本发明实施例提供的一种核心接口保护的方法、存储介质、电子设备及***,通过创建一个独立的远程服务进程,来代理APP发送核心接口请求并返回请求数据。由于核心接口请求在一个独立的代理的远程服务进程中发起,所以黑客通过hook客户端的APP程序,也无法获取到核心接口的数据,保障了核心接口的网络请求的安全性,也可以保障接口数据不被抓包工具所获取。并且,远程服务进程通过代理形式向服务器进行请求时,将传统的单个核心接口请求,拆分为两类接口请求。通过第一类接口向服务器请求到核心数据不准确的接口数据,同时,通过第二类接口向服务器请求到准确的核心数据的解密秘钥,利用该解密秘钥可得到准确的核心数据。因此,客户端APP只有同时获取到上述两个数据,才能得到完整的且准确的核心接口的数据,这样就保障了核心接口的数据是经过了更为复杂的逻辑获取到的,进一步提高了盗刷的门槛,并且是无法通过抓包或者hook来获取所有准确的数据,有效防止了黑客破解核心接口获取核心数据,进而保障了核心接口的网络请求安全性。
本领域内的技术人员应明白,本发明的实施例可提供为方法、***、或计算机程序产品。因此,本发明可采用完全硬件实施例、完全软件实施例、或结合软件和硬件方面的实施例的形式。而且,本发明可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器和光学存储器等)上实施的计算机程序产品的形式。
本发明是参照根据本发明实施例的方法、设备(***)、和计算机程序产品的流程图和/或方框图来描述的。应理解可由计算机程序指令实现流程图和/或方框图中的每一流程和/或方框、以及流程图和/或方框图中的流程和/或方框的结合。可提供这些计算机程序指令到通用计算机、专用计算机、嵌入式处理机或其他可编程数据处理设备的处理器以产生一个机器,使得通过计算机或其他可编程数据处理设备的处理器执行的指令产生用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的装置。
这些计算机程序指令也可存储在能引导计算机或其他可编程数据处理设备以特定方式工作的计算机可读存储器中,使得存储在该计算机可读存储器中的指令产生包括指令装置的制造品,该指令装置实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能。
这些计算机程序指令也可装载到计算机或其他可编程数据处理设备上,使得在计算机或其他可编程设备上执行一系列操作步骤以产生计算机实现的处理,从而在计算机或其他可编程设备上执行的指令提供用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的步骤。
注意:上述的具体实施例仅是例子而非限制,且本领域技术人员可以根据本发明的构思从上述分开描述的各个实施例中合并和组合一些步骤和装置来实现本发明的效果,这种合并和组合而成的实施例也被包括在本发明中,在此不一一描述这种合并和组合。
本发明实施例中提及的优点、优势、效果等仅是示例,而非限制,不能认为这些优点、优势、效果等是本发明的各个实施例必须具备的。另外,本发明实施例公开的上述具体细节仅是为了示例的作用和便于理解的作用,而非限制,上述细节并不限制本发明实施例必须采用上述具体的细节来实现。
本发明实施例中涉及的器件、装置、设备、***的方框图仅作为例示性的例子,并且不意图要求或暗示必须按照方框图示出的方式进行连接、布置、配置。如本领域技术人员将认识到的,可以按任意方式连接、布置、配置这些器件、装置、设备、***。诸如“包括”、“包含”、“具有”等等的词语是开放性词汇,指“包括但不限于”,且可与其互换使用。本发明实施例所使用的词汇“或”和“和”指词汇“和/或”,且可与其互换使用,除非上下文明确指示不是如此。本发明实施例所使用的词汇“诸如”指词组“诸如但不限于”,且可与其互换使用。
本发明实施例中的步骤流程图以及以上方法描述仅作为例示性的例子,并且不意图要求或暗示必须按照给出的顺序进行各个实施例的步骤。如本领域技术人员将认识到的,可以按任意顺序进行以上实施例中的步骤的顺序。诸如“其后”、“然后”、“接下来”等等的词语不意图限制步骤的顺序;这些词语仅用于引导读者通读这些方法的描述。此外,例如使用冠词“一个”、“一”或者“该”对于单数的要素的任何引用不被解释为将该要素限制为单数。
另外,本发明各个实施例中的步骤和装置并非仅限定于某个实施例中实行,事实上,可以根据本发明的概念来结合本文中的各个实施例中相关的部分步骤和部分装置,以构思新的实施例,而这些新的实施例也包括在本发明的范围内。
本发明实施例中的各个操作可以通过能够进行相应的功能的任何适当的手段而进行。该手段可以包括各种硬件和/或软件组件和/或模块,包括但不限于硬件的电路或处理器。
本发明实施例的方法包括用于实现上述的方法的一个或多个动作。方法和/或动作可以彼此互换而不脱离权利要求的范围。换句话说,除非指定了动作的具体顺序,否则可以修改具体动作的顺序和/或使用而不脱离权利要求的范围。
本领域技术人员可以不脱离由所附权利要求定义的教导的技术而进行对在此所述的技术的各种改变、替换和更改。此外,本公开的权利要求的范围不限于以上所述的处理、机器、制造、事件的组成、手段、方法和动作的具体方面。可以利用与在此所述的相应方面进行基本相同的功能或者实现基本相同的结果的当前存在的或者稍后要开发的处理、机器、制造、事件的组成、手段、方法或动作。因而,所附权利要求包括在其范围内的这样的处理、机器、制造、事件的组成、手段、方法或动作。
提供所公开的方面的以上描述以使本领域的任何技术人员能够做出或者使用本发明。对这些方面的各种修改对于本领域技术人员而言是非常显而易见的,并且在此定义的一般原理可以应用于其他方面而不脱离本发明的范围。因此,本发明不意图被限制到在此示出的方面,而是按照与在此公开的原理和新颖的特征一致的最宽范围。
为了例示和描述的目的已经给出了以上描述。此外,此描述不意图将本发明的实施例限制到在此公开的形式。尽管以上已经讨论了多个示例方面和实施例,但是本领域技术人员将认识到其某些变型、修改、改变、添加和子组合。且本说明书中未作详细描述的内容属于本领域专业技术人员公知的现有技术。
Claims (10)
1.一种核心接口保护的方法,其特征在于,包括以下步骤:
客户端创建远程服务进程,所述远程服务进程用于协助客户端的APP发送核心接口请求并返回请求数据;
当客户端的APP要发起网络请求时,基于预设的总接口函数,确定发起请求的方式;所述总接口函数用于判断网络请求是否为核心接口请求,若是,则确定发起请求的方式为代理形式,否则,确定为非代理形式;
当发起请求的方式确定为代理形式时,APP将核心接口请求以HTTP GET请求形式发送至所述远程服务进程;所述远程服务进程收到请求后,基于预设的接口拆分函数,将核心接口拆分为第一类接口和第二类接口,并利用所述第一类接口向服务器请求核心接口的接口数据,服务器返回的接口数据中,对于核心数据使用不准确数据,而准确的核心数据进行加密处理;同时利用所述第二类接口向服务器请求准确的核心数据的解密秘钥;
所述远程服务进程基于所述第一类接口获取到服务器返回的接口数据后,通过代理形式返回给APP;所述远程服务进程基于所述第二类接口获取到服务器返回的解密秘钥后,利用该解密秘钥解密出准确的核心数据,并通过进程间通信的方式返回给APP;
当发起请求的方式确定为非代理形式时,使用APP中的网络库进行网络请求功能。
2.如权利要求1所述一种核心接口保护的方法,其特征在于,所述远程服务进程收到请求后,基于预设的接口拆分函数,将核心接口拆分为第一类接口和第二类接口,并利用所述第一类接口向服务器请求核心接口的接口数据,具体步骤包括:
创建核心接口请求的基础类,所述基础类用于定义核心接口请求所需的功能接口;所述功能接口包括:
头数据获取接口getHeader(),用于获取核心接口请求的请求头数据;
body数据获取接口getBody(),用于获取核心接口请求的body数据;
接口拆分函数list<CoreRequestBase*>splist(),用于将核心接口拆分为第一类接口和第二类接口,其返回值返回多个接口请求的实例列表;
所述远程服务进程收到请求后,基于所述接口拆分函数list<CoreRequestBase*>splist(),将核心接口拆分为第一类接口和第二类接口;
利用拆分后的第一类接口向服务器发送核心接口的接口数据请求,并通过调用getHeader()和getBody(),分别获取核心接口请求的头数据和body数据,其中,服务器返回的body数据中,对于核心数据使用不准确数据,而准确的核心数据进行加密处理。
3.如权利要求2所述的一种核心接口保护的方法,其特征在于:
当拆分后的第一类接口不止一个接口时,每个第一类接口用于向服务器请求核心接口的部分接口数据,所有第一类接口请求的部分接口数据能组合成完整的核心接口的接口数据;
当拆分后的第二类接口不止一个接口时,每个第二类接口用于向服务器请求部分解密秘钥,所有第二类接口请求的部分解密秘钥能组合成完整的解密秘钥。
4.如权利要求1所述一种核心接口保护的方法,其特征在于:
所述远程服务进程创建完成后,APP将该APP的进程ID以及所述远程服务进程的进程ID,通过进程间通信的方式发送给所述远程服务进程;且APP生成账号密码信息,并经加密后通过进程间通信的方式发送给所述远程服务进程;
所述远程服务进程利用所述第二类接口向服务器请求准确的核心数据的解密秘钥,具体步骤包括:
所述远程服务进程利用所述第二类接口向服务器发送解密秘钥请求,并携带所述账号密码信息、APP的进程ID以及远程服务进程的进程ID,且整个请求的所有数据均经加密后发送给服务器;
所述服务器收到解密秘钥请求后,利用解密后的所述账号密码信息、APP的进程ID以及远程服务进程的进程ID,进行客户端合法性的验证,若验证通过,则生成准确的核心数据的解密秘钥,并经加密后通过所述第二类接口返回给远程服务进程。
5.如权利要求1所述的一种核心接口保护的方法,其特征在于,该方法还包括以下步骤:
当客户端的APP启动后,APP将创建一个检测线程,所述检测线程用于每当APP有网络请求要发生时都会检测一次当前***是否已设置***代理;
若已设置***代理,则APP只请求非核心接口的准确数据,对核心接口则只请求不准确的核心数据,而准确的核心数据则不请求;同时服务器对于所有的核心数据只返回不准确的数据;
若未设置***代理,则客户端将按照权利要求1中所述的方法进行操作。
6.如权利要求1所述一种核心接口保护的方法,其特征在于,所述APP将核心接口请求以HTTP GET请求形式发送至所述远程服务进程,具体步骤包括:
APP通过HTTP CONNECT方式请求与远程服务进程进行链接通信,并将核心接口的域名和端口发送给远程服务进程;
当APP与远程服务进程链接成功后,APP将核心接口整个请求以加密的形式发送一个HTTP GET请求到所述远程服务进程中;所述远程进程收到请求后解密出请求。
7.如权利要求1所述的一种核心接口保护的方法,其特征在于,该方法还包括以下步骤:所述远程服务进程创建完成后,所述远程服务进程与APP共同完成共享秘钥的生成,所述共享秘钥用于两者之间数据交互的加解密;且所述远程服务进程与APP之间的所有数据交互均基于所述共享秘钥进行加密处理。
8.一种存储介质,其上存储有计算机程序,其特征在于:所述计算机程序被处理器执行时实现权利要求1至7任一项所述的方法。
9.一种电子设备,包括存储器和处理器,存储器上存储有在所述处理器上运行的计算机程序,其特征在于:所述处理器执行所述计算机程序时实现权利要求1至7任一项所述的方法。
10.一种核心接口保护的***,其特征在于,包括:
客户端,所述客户端包括:
远程服务进程创建模块,其用于创建远程服务进程,所述远程服务进程用于协助客户端的APP发送核心接口请求并返回请求数据;
请求方式判定模块,其用于当客户端的APP要发起网络请求时,基于预设的总接口函数,确定发起请求的方式;所述总接口函数用于判断网络请求是否为核心接口请求,若是,则确定发起请求的方式为代理形式,否则,确定为非代理形式;
代理请求模块,其用于当发起请求的方式确定为代理形式时,控制APP将核心接口请求以HTTP GET请求形式发送至所述远程服务进程;控制远程服务进程收到请求后,基于预设的接口拆分函数,将核心接口拆分为第一类接口和第二类接口,并利用所述第一类接口向服务器请求核心接口的接口数据,所述接口数据中,对于核心数据使用不准确数据,而准确的核心数据进行加密处理;并控制远程服务进程利用所述第二类接口向服务器请求准确的核心数据的解密秘钥;
代理数据返回模块,其用于控制远程服务进程基于所述第一类接口获取到服务器返回的接口数据后,通过代理形式返回给APP;控制远程服务进程基于所述第二类接口获取到服务器返回的解密秘钥后,利用该解密秘钥解密出准确的核心数据,并通过进程间通信的方式返回给APP;
非代理请求模块,其用于当发起请求的方式确定为非代理形式时,使用APP中的网络库进行网络请求功能;
服务器,所述服务器包括:
数据返回模块,其用于收到远程服务进程通过所述第一类接口发来的请求后,向远程服务进程返回核心接口的接口数据,返回的接口数据中,对于核心数据使用不准确数据,而准确的核心数据进行加密处理;收到远程服务进程通过所述第二类接口发来的请求后,生成准确的核心数据的解密秘钥,并经加密后通过所述第一类接口返回给远程服务进程。
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN202010789856.7A CN112039852B (zh) | 2020-08-07 | 2020-08-07 | 一种核心接口保护的方法、存储介质、电子设备及*** |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN202010789856.7A CN112039852B (zh) | 2020-08-07 | 2020-08-07 | 一种核心接口保护的方法、存储介质、电子设备及*** |
Publications (2)
Publication Number | Publication Date |
---|---|
CN112039852A true CN112039852A (zh) | 2020-12-04 |
CN112039852B CN112039852B (zh) | 2022-08-05 |
Family
ID=73582766
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
CN202010789856.7A Active CN112039852B (zh) | 2020-08-07 | 2020-08-07 | 一种核心接口保护的方法、存储介质、电子设备及*** |
Country Status (1)
Country | Link |
---|---|
CN (1) | CN112039852B (zh) |
Citations (11)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20030177384A1 (en) * | 2002-03-14 | 2003-09-18 | International Business Machines Corporation | Efficient transmission of IP data using multichannel SOCKS server proxy |
US20040236940A1 (en) * | 2003-03-25 | 2004-11-25 | Pioneer Corporation | Contents supplying system, method and program |
CN102456193A (zh) * | 2010-10-28 | 2012-05-16 | ***股份有限公司 | 移动存储设备、基于该设备的数据处理***和方法 |
US20130152180A1 (en) * | 2011-12-07 | 2013-06-13 | Azuki Systems, Inc. | Device using secure processing zone to establish trust for digital rights management |
CN106982186A (zh) * | 2016-01-16 | 2017-07-25 | 周念东 | 一种联机安全密钥保护方法和*** |
CN108351945A (zh) * | 2015-10-16 | 2018-07-31 | 德国电信股份有限公司 | 用于保护机密电子数据的方法和*** |
US20180375828A1 (en) * | 2017-06-26 | 2018-12-27 | Open Text Corporation | Systems and methods for providing communications between on-premises servers and remote devices |
CN109635573A (zh) * | 2018-11-12 | 2019-04-16 | 北京海泰方圆科技股份有限公司 | 数据分布式加解密的***、方法、装置、电子设备及介质 |
CN109787954A (zh) * | 2018-12-12 | 2019-05-21 | 四川商通实业有限公司 | 一种php接口安全过滤方法及*** |
CN109889468A (zh) * | 2017-12-06 | 2019-06-14 | 腾讯科技(武汉)有限公司 | 网络数据的传输方法、***、装置、设备及存储介质 |
CN111475314A (zh) * | 2020-04-03 | 2020-07-31 | 深信服科技股份有限公司 | 一种网络请求的处理方法、装置、设备及存储介质 |
-
2020
- 2020-08-07 CN CN202010789856.7A patent/CN112039852B/zh active Active
Patent Citations (11)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20030177384A1 (en) * | 2002-03-14 | 2003-09-18 | International Business Machines Corporation | Efficient transmission of IP data using multichannel SOCKS server proxy |
US20040236940A1 (en) * | 2003-03-25 | 2004-11-25 | Pioneer Corporation | Contents supplying system, method and program |
CN102456193A (zh) * | 2010-10-28 | 2012-05-16 | ***股份有限公司 | 移动存储设备、基于该设备的数据处理***和方法 |
US20130152180A1 (en) * | 2011-12-07 | 2013-06-13 | Azuki Systems, Inc. | Device using secure processing zone to establish trust for digital rights management |
CN108351945A (zh) * | 2015-10-16 | 2018-07-31 | 德国电信股份有限公司 | 用于保护机密电子数据的方法和*** |
CN106982186A (zh) * | 2016-01-16 | 2017-07-25 | 周念东 | 一种联机安全密钥保护方法和*** |
US20180375828A1 (en) * | 2017-06-26 | 2018-12-27 | Open Text Corporation | Systems and methods for providing communications between on-premises servers and remote devices |
CN109889468A (zh) * | 2017-12-06 | 2019-06-14 | 腾讯科技(武汉)有限公司 | 网络数据的传输方法、***、装置、设备及存储介质 |
CN109635573A (zh) * | 2018-11-12 | 2019-04-16 | 北京海泰方圆科技股份有限公司 | 数据分布式加解密的***、方法、装置、电子设备及介质 |
CN109787954A (zh) * | 2018-12-12 | 2019-05-21 | 四川商通实业有限公司 | 一种php接口安全过滤方法及*** |
CN111475314A (zh) * | 2020-04-03 | 2020-07-31 | 深信服科技股份有限公司 | 一种网络请求的处理方法、装置、设备及存储介质 |
Non-Patent Citations (1)
Title |
---|
石念峰: "开放网络环境下电子档案访问控制技术研究", 《档案管理》 * |
Also Published As
Publication number | Publication date |
---|---|
CN112039852B (zh) | 2022-08-05 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US12010228B2 (en) | Systems, methods, and devices for secure blockchain transaction and subnetworks | |
KR102443857B1 (ko) | 암호화키를 사용한 신뢰 실행 환경의 어드레싱 기법 | |
US10432611B2 (en) | Transaction processing method and client based on trusted execution environment | |
CN110214440B (zh) | 计算***,传送受保护数据的方法和可读存储介质 | |
US9853957B2 (en) | DRM protected video streaming on game console with secret-less application | |
US20180309746A1 (en) | Technologies for token-based authentication and authorization of distributed computing resources | |
JP4366037B2 (ja) | 暗号化された媒体へのアクセス権を制御・行使するシステム及び方法 | |
US8850216B1 (en) | Client device and media client authentication mechanism | |
CN104639516B (zh) | 身份认证方法、设备及*** | |
CN104581214B (zh) | 基于ARM TrustZone***的多媒体内容保护方法和装置 | |
KR102489790B1 (ko) | 서명키를 사용한 신뢰 실행 환경의 어드레싱 기법 | |
CN106487765B (zh) | 授权访问方法以及使用该方法的设备 | |
CN106571951B (zh) | 审计日志获取方法、***及装置 | |
US20100318784A1 (en) | Client identification for transportation layer security sessions | |
EP3198498B1 (en) | A challenge-response method and associated computing device | |
CN110011950B (zh) | 一种视频流地址的鉴权方法及装置 | |
TWI679551B (zh) | 進程的身份認證方法和裝置 | |
CN111741268B (zh) | 视频的传输方法、装置、服务器、设备和介质 | |
EP4092984A1 (en) | Data processing method and apparatus, device and medium | |
CN110235134B (zh) | 使用洁净室供应来寻址可信执行环境 | |
CN103237010B (zh) | 以加密方式提供数字内容的服务器端 | |
US20230132485A1 (en) | System for Thin Client Devices in Hybrid Edge Cloud Systems | |
WO2008053279A1 (en) | Logging on a user device to a server | |
CN113395406A (zh) | 一种基于电力设备指纹的加密认证方法及*** | |
CN115580413A (zh) | 一种零信任的多方数据融合计算方法和装置 |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
PB01 | Publication | ||
PB01 | Publication | ||
SE01 | Entry into force of request for substantive examination | ||
SE01 | Entry into force of request for substantive examination | ||
GR01 | Patent grant | ||
GR01 | Patent grant | ||
EE01 | Entry into force of recordation of patent licensing contract |
Application publication date: 20201204 Assignee: Yidu Lehuo Network Technology Co.,Ltd. Assignor: WUHAN DOUYU YULE NETWORK TECHNOLOGY Co.,Ltd. Contract record no.: X2023980041383 Denomination of invention: A method, storage medium, electronic device, and system for protecting core interfaces Granted publication date: 20220805 License type: Common License Record date: 20230908 |
|
EE01 | Entry into force of recordation of patent licensing contract |