CN116684161A - 程序运行方法、装置、电子设备及存储介质 - Google Patents

Abstract

本申请提供一种程序运行方法、装置、电子设备及存储介质，涉及安全防护领域。该方法包括：在运行程序过程中，若触发受保护的函数，则执行受保护的函数中的检测逻辑；其中，受保护的函数包括检测逻辑和函数体；检测逻辑为在安全防护模块启动后，从代理程序中获取并加载在函数体的预设位置上；在利用检测逻辑检测通过的情况下，运行函数体。装置用于执行上述方法。本申请通过在需要被保护的敏感函数中加载检测逻辑，使得在程序运行的过程中，触发到受保护的函数时就可通过检测逻辑对该函数进行安全防护，以此提高安全防护的准确度。

Description

程序运行方法、装置、电子设备及存储介质

技术领域

本申请涉及安全防护领域，具体而言，涉及一种程序运行方法、装置、电子设备及存储介质。

背景技术

随着互联网的普及，网络攻击和安全威胁变得越来越普遍和严重。为了应对这些威胁，安全防护技术也在不断发展和创新。目前市面上应用较广的安全防护技术有Web应用程序防火墙(WAF)和开源的应用程序安全防护软件(OpenRASP)。但这些技术存在误报率高、攻击被绕过、不易配置等问题，使得安全防护的准确度不高。

发明内容

本申请实施例的目的在于提供一种程序运行方法、装置、电子设备及存储介质，用以对函数级别的对象进行安全防护，以此提高安全防护的准确度。

第一方面，本申请实施例提供一种程序运行方法，该方法包括：在运行程序过程中，若触发受保护的函数，则执行受保护的函数中的检测逻辑；其中，受保护的函数包括检测逻辑和函数体；检测逻辑为在安全防护模块启动后，从代理程序中获取并加载在函数体的预设位置上；在利用检测逻辑检测通过的情况下，运行函数体。

本申请实施例通过在需要受保护的函数中添加检测逻辑，以使在程序运行过程中，若触发到受保护的函数，则先执行受保护的函数中的检测逻辑，只有检测逻辑通过，才执行受保护的函数中的函数体。在这个过程中，通过对需要进行保护的函数加载检测逻辑，保证了在程序运行过程中，函数运行的安全性，以此提高安全防护的准确度。

在一些实施例中，该方法还包括：若检测逻辑检测到传入受保护的函数的参数存在攻击行为，则对攻击行为进行拦截，并停止运行函数体。

本申请实施例通过检测逻辑检测传入受保护的函数的参数是否存在攻击行为，若存在，则对攻击进行拦截，并阻断受保护的函数执行自身逻辑，即停止运行受保护的函数的函数体，保证了能够运行的受保护的函数都是安全的。

在一些实施例中，执行受保护的函数中的检测逻辑，包括：通过检测逻辑读取预先配置的白名单，白名单中包括跳过检测的函数请求信息；若白名单包括受保护的函数对应的函数请求信息，则跳过检测逻辑，并执行函数体。

本申请实施例通过设置白名单来判断当前触发的受保护的函数是否能不执行检测，若能，则直接执行函数体。在这个过程中，通过配置白名单对受保护的函数执行免检测过程，避免出现防护过于严格导致正常功能无法使用的情况，以此提高程序运行的性能。

在一些实施例中，执行受保护的函数中的检测逻辑，包括：通过检测逻辑读取预先配置的黑名单，黑名单中包括禁止访问的函数请求信息；若黑名单包括受保护的函数对应的函数请求信息，则禁止受保护的函数执行。

本申请实施例通过设置黑名单来判断当前触发的受保护的函数是否被禁止访问，若是，则不执行函数体。在这个过程中，通过配置黑名单对受保护的函数禁止访问，以降低了函数运行的风险，在提高函数的安全性和性能的基础上，确保程序的正常运行。

在一些实施例中，在安全防护模块启动后，该方法还包括：通过保护线程检测受保护的函数的防护开启情况；其中，保护线程在程序运行的过程中被启动；若防护开启情况为未正常开启，则重新从代理程序中获取并加载检测逻辑在函数体的预设位置上。

本申请实施例通过保护线程检测被保护的函数的防护情况，并根据防护情况决定是否需要重新加载检测逻辑，保证了受保护的函数一直处于防护正常开启的状态，进一步保证了受保护的函数的安全性。

在一些实施例中，若触发受保护的函数，则执行受保护的函数中的检测逻辑之前，该方法还包括：在安全防护模块启动后，读取配置文件；其中，配置文件包括函数所在类名、函数名和检测逻辑标识；根据函数所在类名和函数名确定受保护的函数的函数体；根据检测逻辑标识确定代理程序中与检测逻辑标识对应的检测逻辑，并将检测逻辑写入函数体的预设位置上。

本申请实施例通过配置文件的形式对需要保护的函数进行配置，由于配置文件可更改和易于操作的特性，操作人员能够通过操作配置文件实现对想要保护的函数的配置。再有，在配置文件配置受保护的函数对应的检测逻辑的标识，以使能通过检测逻辑标识找到与受保护的函数对应的检测逻辑，保证了被加载到受保护的函数中的检测逻辑与受保护的函数是一一对应的关系，进一步保证了安全防护的准确度。

在一些实施例中，配置文件还包括参数索引；执行受保护的函数中的检测逻辑，包括：根据检测逻辑对参数索引对应的受保护的函数的参数进行检测。

本申请实施例通过在配置文件中配置受保护的函数的参数索引，以使检测逻辑能针对性的对受保护的函数中的参数进行检测，保证了安全防护的准确度。

第二方面，本申请实施例提供一种程序运行装置，该装置包括：触发模块，用于在运行程序过程中，若触发受保护的函数，则执行受保护的函数中的检测逻辑；其中，受保护的函数包括检测逻辑和函数体；检测逻辑为在安全防护模块启动后，从代理程序中获取并加载在函数体的预设位置上；运行模块，用于在利用检测逻辑检测通过的情况下，运行函数体。

第三方面，本申请实施例提供一种电子设备，包括：处理器、存储器、存储介质和总线，其中，所述处理器和所述存储器通过所述总线完成相互间的通信；所述存储器存储有可被所述处理器执行的程序指令，所述处理器调用所述程序指令能够执行第一方面的方法步骤。

第四方面，本申请实施例提供一种非暂态计算机可读存储介质，包括：所述计算机可读存储介质存储计算机指令，所述计算机指令使所述计算机执行第一方面的方法步骤。

本申请的其他特征和优点将在随后的说明书阐述，并且，部分地从说明书中变得显而易见，或者通过实施本申请实施例了解。本申请的目的和其他优点可通过在所写的说明书、权利要求书、以及附图中所特别指出的结构来实现和获得。

附图说明

为了更清楚地说明本申请实施例的技术方案，下面将对本申请实施例中所需要使用的附图作简单地介绍，应当理解，以下附图仅示出了本申请的某些实施例，因此不应被看作是对范围的限定，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他相关的附图。

图1为本申请实施例提供的一种程序运行方法的流程示意图；

图2为本申请实施例提供的一种程序运行时加载代理程序的时序图；

图3为本申请实施例提供的一种程序运行装置结构示意图；

图4为本申请实施例提供的电子设备结构示意图。

具体实施方式

为使本申请实施例的目的、技术方案和优点更加清楚，下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行清楚、完整地描述，应当理解，本申请中附图仅起到说明和描述的目的，并不用于限定本申请的保护范围。另外，应当理解，示意性的附图并未按实物比例绘制。本申请中使用的流程图示出了根据本申请的一些实施例实现的操作。应该理解，流程图的操作可以不按顺序实现，没有逻辑的上下文关系的步骤可以反转顺序或者同时实施。此外，本领域技术人员在本申请内容的指引下，可以向流程图添加一个或多个其他操作，也可以从流程图中移除一个或多个操作。

另外，所描述的实施例仅仅是本申请一部分实施例，而不是全部的实施例。通常在此处附图中描述和示出的本申请实施例的组件可以以各种不同的配置来布置和设计。因此，以下对在附图中提供的本申请的实施例的详细描述并非旨在限制要求保护的本申请的范围，而是仅仅表示本申请的选定实施例。基于本申请的实施例，本领域技术人员在没有做出创造性劳动的前提下所获得的所有其他实施例，都属于本申请保护的范围。

需要说明的是，本文所使用的所有的技术和科学术语与属于本申请的技术领域的技术人员通常理解的含义相同；本文中所使用的术语只是为了描述具体的实施例的目的，不是旨在于限制本申请；本申请的说明书和权利要求书及上述附图说明中的术语“包括”和“具有”以及它们的任何变形，意图在于覆盖不排他的包含。

在本申请实施例的描述中，技术术语“第一”“第二”等仅用于区别不同对象，而不能理解为指示或暗示相对重要性或者隐含指明所指示的技术特征的数量、特定顺序或主次关系。在本申请实施例的描述中，“多个”的含义是两个以上，除非另有明确具体的限定。

在本申请实施例的描述中，术语“和/或”仅仅是一种描述关联对象的关联关系，表示可以存在三种关系，例如A和/或B，可以表示：单独存在A，同时存在A和B，单独存在B这三种情况。另外，本文中字符“/”，一般表示前后关联对象是一种“或”的关系。

为了便于理解本申请实施例提供的技术方案，下面以服务器作为执行主体为例，对本申请实施例提供的程序运行方法的应用场景进行介绍。服务器具体可以为应用服务器，也可以为Web服务器。

为了便于理解，对本申请实施例提供的技术方案中涉及到的专业技术进行介绍。

JAVA语言：java是一种面向对象的编程语言，支持封装、继承和多态等特性，有利于提高代码的可重用性、可扩展性和可维护性。程序通过Java虚拟机(JVM)运行，可以在不同的操作系统上运行，实现了跨平台的特性。且提供了丰富的安全机制和类库，如安全管理器、加密解密、数字签名等，可以保障程序的安全性。在使用过程中，由于java语言及其类库是开放的，拥有庞大的开发者社区和丰富的资源，可以快速获取解决方案和技术支持。

JavaAgent：是Java虚拟机提供的一个工具，可以在运行时修改或增强Java应用程序的字节码，实现对Java程序的动态监控、诊断、调优等功能。JavaAgent通常使用JavaInstrumentation API来实现，它可以在Java应用程序启动之前通过配置jvm参数指定一个Jar包加载，也可以项目运行时使用attach机制调用一个jar包加载，这个Jar包中包含了JavaAgent的实现代码和相关的配置信息。当Java应用程序启动时，JVM会先加载JavaAgent，并利用它来修改或增强应用程序的字节码。

Javassist：是一个用于在运行时动态编辑Java字节码的开源库，它提供了一些简单易用的API，使得Java开发人员能够在运行时修改字节码，实现类似于AOP、动态代理、代码注入等高级功能，从而提高了Java应用程序的灵活性和可维护性。

图1为本申请实施例提供的一种程序运行方法的流程示意图，如图1所示，该方法包括：

步骤101，服务器在运行程序过程中，若触发受保护的函数，则执行受保护的函数中的检测逻辑；其中，受保护的函数包括检测逻辑和函数体；检测逻辑为在安全防护模块启动后，从代理程序中获取并加载在函数体的预设位置上。

在具体实施过程中，受保护的函数指需要进行逻辑检测的函数。检测逻辑为开发人员或运维人员预先根据受保护的函数的特征进行编写的逻辑代码，用于对受保护的函数进行安全防护。应当知道的是，一个受保护的函数对应一个检测逻辑。函数体指受保护的函数原始的方法体，即函数的自身逻辑。

受保护的函数可以是程序中任意一个函数，也可以是存在安全风险的函数，还可以是用户指定需要进行保护的函数，具体需要对哪种类型的函数进行保护，可根据实际情况进行选择，本申请对此不作具体限定。但应当知道的是，为了保证程序运行性能和安全性，通常情况下主要是对存在安全风险的函数进行保护。示例性的，受保护的函数可以是文件写入函数(java.io.FileOutputStream#FileOutputStream)和任意命令执行函数(java.lang.ProcessBuilder#start)。

应当知道的是，一个程序包括多个函数，但在程序运行过程中，并不是该程序中所有的函数都可能被执行到。因此，受保护的函数只有在程序运行过程中被触发时，才会执行受保护的函数中的检测逻辑，当受保护的函数未被触发时，则不执行检测逻辑。

由于在触发到受保护的函数时，需要先通过检测逻辑对受保护的函数检测通过后，再执行受保护的函数的函数体，因此检测逻辑从代理程序中获取并加载在函数体的首行位置，以保证先通过检测逻辑，再执行函数体。

步骤102，服务器在利用检测逻辑检测通过的情况下，运行函数体。

在具体实施过程中，触发受保护的函数后，利用检测逻辑检测受保护的函数的防护情况，当检测通过时，运行函数体。

本申请实施例通过在需要受保护的函数中添加检测逻辑，以使在程序运行过程中，若触发到受保护的函数，则先执行受保护的函数中的检测逻辑，只有检测逻辑通过，才执行受保护的函数中的函数体。在这个过程中，通过对需要进行保护的函数加载检测逻辑，保证了在程序运行过程中，函数运行的安全性，以此提高安全防护的准确度。

在一些实施例中，该方法还包括：服务器若检测逻辑检测到传入受保护的函数的参数存在攻击行为，则对攻击行为进行拦截，并停止运行函数体。

在具体实施过程中，受保护的函数包括参数列表，用于接收传入受保护的函数的参数。通常，只有存在参数传递的情形下，才会有攻击行为的产生，因此针对函数的安全防护，主要对传入的参数进行安全检测。需要说明的是，一个函数可包括多个参数，因此，在利用检测逻辑进行检测时，可以对受保护的函数中的一个参数进行检测，也可以对受保护的函数中的多个参数进行检测。

当检测逻辑检测到传入受保护的函数的参数存在攻击行为，则抛出异常，并拦截该攻击行为，停止函数体的运行。同时，记录拦截的传入受保护的函数的相关参数信息和对应的请求接口到日志中，以实现对攻击行为的统计和分析。另外，为了便于用户获知拦截情况，在拦截成功后返回一个特定的页面进行提醒。

需要说明的是，攻击行为包括SQL注入、WEBSHELL上传、XSS、文件包含、命令执行等。

本申请实施例通过检测逻辑检测传入受保护的函数的参数是否存在攻击行为，若存在，则对攻击进行拦截，并阻断受保护的函数执行自身逻辑，即停止运行受保护的函数的函数体，保证了能够运行的受保护的函数都是安全的。

在一些实施例中，服务器执行受保护的函数中的检测逻辑，包括：服务器通过检测逻辑读取预先配置的白名单，白名单中包括跳过检测的函数请求信息；若白名单包括受保护的函数对应的函数请求信息，则跳过检测逻辑，并执行函数体。

在具体实施过程中，当程序在运行过程中，可能存在以下问题：

1)由于已有的检测逻辑写的过于严谨，导致程序在正常使用情况下出现误报，使得用户不能正常使用程序的某个功能。再有，针对不同的用户，对于同一个功能的需求是不同的，若事先已经为该功能的方法编写了固定的检测逻辑，则部分客户的需求将得不到满足。例如：用户在进行文件上传时，已有的检测逻辑中写有禁止JPG类型的图片进行上传的规则，但有些用户需要上传JPG类型的图片，若不对已有的检测逻辑进行修改，则用户将不能成功上传图片。

2)由于攻击手段也在不断迭代更新，使得当出现新的攻击方式时，已有的检测逻辑并不能对新的攻击进行防护。因此，需要在出现新的攻击方式的情况下新增或者完善已有的检测逻辑，从而能够抵御更多类型的攻击。

基于上述问题的出现，本申请通过配置白名单和黑名单进行解决，在白名单中配置可跳过检测的对象。配置白名单遵循如下规则：

1)必须遵循XML编写规范，文件后缀为.xml；

2)配置文件中的标签允许进行自定义；

3)配置成功的文件存储位置根据集成的项目进行设置。

在本申请的实施例中，通过在白名单中配置可以跳过检测的函数请求信息，其中，函数请求信息指触发该函数所需的请求参数信息。请求信息中包括提交方式、访问路径、触发该函数所调用的接口信息、传入函数的参数信息等。示例性的，用户实现登录功能，在登录页面输入账号密码，点击登录按钮实现登录。在登录过程中，服务器解析用户提交的请求信息，获取请求信息中的提交方式(post、get)、账号、密码、调用的接口、访问路径等内容作为函数请求信息对函数进行访问。

当触发了受保护的函数，执行检测逻辑时，检测逻辑通过读取白名单中的内容判断当前触发的受保护的函数的函数请求信息是否在白名单内，若在，则跳过检测逻辑，并执行受保护的函数的函数体。

应当知道的是，由于函数请求信息中包括多种类型的参数信息，因此，预先配置的白名单可根据程序中各类函数的实际运行情况从多维度进行配置。例如：白名单中配置的信息可以包括受保护的函数的访问路径、调用受保护的函数的接口信息、传入受保护的函数的参数信息等，并且，白名单中设置的信息可以只包括上述信息的一种，也可以包括上述信息的多种。具体为，白名单中可配置跳过检测的文件类型、跳过检测的文件路径以及跳过检测的文件上传接口等。示例性的，白名单可配置如下：

由于白名单以配置文件形式进行配置，并保存在磁盘中，为了使得检测逻辑能够正确读取到预先配置的白名单，需要在检测逻辑中编写读取白名单的读取逻辑，以通过读取逻辑将白名单从磁盘读取到缓存中，以实现判断白名单中是否包括受保护的函数的函数请求信息，判断的过程为将白名单中配置的信息与缓存中缓存的受保护的函数的函数请求信息进行比对。读取逻辑需要继承抽象类AbstractInitConfig，并且重写继承的抽象类AbstractInitConfig中的方法，示例性的：

需要说明的是，白名单可以存在，也可以不存在，当白名单存在时，可以只配置一个白名单，也可以配置多个白名单。因此，在实际应用中，可根据实际情况对白名单进行设置，本申请对此不作具体限定。再有，不论白名单是否存在，在执行检测逻辑时，都会执行读取白名单的读取逻辑，若存在白名单，则读取白名单后再执行后续逻辑，若不存在白名单，则直接执行后续逻辑。

本申请实施例通过设置白名单来判断当前触发的受保护的函数是否能不执行检测，若能，则直接执行函数体。在这个过程中，通过配置白名单对受保护的函数执行免检测过程，避免出现防护过于严格导致正常功能无法使用的情况，以此提高程序运行的性能。

在一些实施例中，服务器执行受保护的函数中的检测逻辑，包括：服务器通过检测逻辑读取预先配置的黑名单，黑名单中包括禁止访问的函数请求信息；若黑名单包括受保护的函数对应的函数请求信息，则禁止受保护的函数执行。

在具体实施过程中，由于可以配置白名单允许跳过检测的规则，同理，也可以配置黑名单实现禁止访问的规则。配置黑名单遵循的规则请参见配置白名单遵循的规则，此处不再赘述。

示例性的，黑名单可配置如下：

同理，由于黑名单以配置文件形式进行配置，为了使得检测逻辑能够正确读取到预先配置的黑名单，需要在检测逻辑中编写读取黑名单的读取逻辑。应当知道的是，读取黑名单的读取逻辑与读取白名单的读取逻辑一样，具体读取逻辑请参见上述实施例，此处不再赘述。

需要说明的是，黑名单可以存在、也可以不存在，当黑名单存在时，可以只配置一个黑名单，也可以配置多个黑名单，因此，在实际应用中，可根据实际情况对黑名单进行设置，本申请对此不作具体限定。

再有，黑名单和白名单可同时配置在一个配置文件中，在检测逻辑通过读取逻辑进行读取时，可同时读取到白名单和黑名单，而在具体读取过程中，可先对白名单进行读取，再对黑名单进行读取，也可先对黑名单进行读取，再对白名单进行读取，具体读取顺序可根据实际情况进行设定，本申请对此不作具体限定。

本申请实施例通过设置黑名单来判断当前触发的受保护的函数是否被禁止访问，若是，则不执行函数体。在这个过程中，通过配置黑名单对受保护的函数禁止访问，以降低了函数运行的风险，在提高函数的安全性和性能的基础上，确保程序的正常运行。

在一些实施例中，在安全防护模块启动后，该方法还包括：通过保护线程检测受保护的函数的防护开启情况；其中，保护线程在程序运行的过程中被启动；若防护开启情况为未正常开启，则重新从代理程序中获取并加载检测逻辑在函数体的预设位置上。

在具体实施过程中，在安全防护模块启动后，从代理程序获取并加载检测逻辑到受保护的函数中时，可能存在加载失败或者加载成功的检测逻辑失效的情况，以使受保护的函数的防护并未生效。因此，本申请实施例通过保护线程定时检测受保护的函数的防护开启情况。

在检测时，保护线程通过调用受保护的函数，以检测受保护的函数的防护开启情况。此时，保护线程调用受保护的函数后，受保护的函数会向保护线程返回一个防护标识，保护线程通过防护标识确认受保护的函数的防护是否成功。并且，需要将防护开启情况写入日志，以对受保护的函数的防护开启情况进行记录和追踪。除此之外，为了便于用户想知道受保护的函数的防护开启情况，可通过页面展示的方式将每一个受保护的函数的防护开启情况进行展示。需要说明的是，保护线程在程序运行的过程中被启动。

由于一个程序中可能包括多个受保护的函数，而每一个受保护的函数的防护开启情况都需要进行检测，因此，为了保证程序中所有的受保护的函数的防护都正常开启，保护线程会定时对所有受保护的函数进行检测，定时可以是每10分钟对受保护的函数进行检测，也可以是每20分钟对受保护的函数进行检测，具体时间可根据实际情况进行设置，本申请对此不作具体限定。

在保护线程检测到某一个受保护的函数的防护开启失败时，会重新从代理程序中获取并加载该受保护的函数对应的检测逻辑到函数体的预设位置上，以保证检测逻辑生效，使得受保护的函数的防护成功开启。

本申请实施例通过保护线程检测被保护的函数的防护情况，并根据防护情况决定是否需要重新加载检测逻辑，保证了受保护的函数一直处于防护正常开启的状态，进一步保证了受保护的函数的安全性。

在一些实施例中，若触发受保护的函数，则执行受保护的函数中的检测逻辑之前，该方法还包括：服务器在安全防护模块启动后，读取配置文件；其中，配置文件包括函数所在类名、函数名和检测逻辑标识；服务器根据函数所在类名和函数名确定受保护的函数的函数体；服务器根据检测逻辑标识确定代理程序中与检测逻辑标识对应的检测逻辑，并将检测逻辑写入函数体的预设位置上。

在具体实施过程中，在触发受保护的函数之前，需要确定哪些函数是需要被保护的。在本申请的实施例中，通过配置文件的方式对受保护的函数进行确定。具体为，通过在配置文件中配置函数所在类名和函数名，并根据函数所在类名和函数名确定受保护的函数的函数体。

配置文件为预先进行编写的文件，配置文件遵循XML编写规范。应当知道的是，配置文件的格式除了设置为XML格式外，还可设置为键值对、JSON、YAML、TOML等，具体可根据实际情况进行设置，本申请对此不作具体限定。配置文件中除了包括函数所在类名、函数名和检测逻辑标识外，还可以包括函数对应的参数类型、参数索引等内容。其中，函数所在类名指代受保护的函数所属的类；检测逻辑标识用于标识受保护的函数对应的检测逻辑；由于函数可能会没有参数或者会存在多个参数，因此，当受保护的函数没有参数时，参数索引不进行设置，当受保护的函数拥有多个参数时，参数索引指受保护的函数中的第几个参数。

需要说明的是，由于不同的类之间会存在相同的函数(方法)，因此，在配置文件中配置函数所在类名时需要配置函数所在的全限定类名，以区分不同类中相同的函数。若不同的类之间不存在相同的函数(方法)，则使用非限定类名即可。具体可根据实际情况进行配置，本申请对此不作具体限定。

再有，除了根据函数所在类名和函数名确定受保护的函数的函数体外，还可根据函数所在类名、函数名、函数对应的参数类型、参数索引等确定受保护的函数的函数体，具体如何确定，可根据实际情况进行设置，本申请对此不作具体限定。

示例性，配置文件可配置如下：

由于配置文件中包括检测逻辑标识，因此服务器可根据检测逻辑标识确定代理程序中与检测逻辑标识对应的检测逻辑，并将检测逻辑写入函数体的预设位置上。

为了提高代码的扩展性和灵活性，检测逻辑的编写需要继承抽象类ABaseAgent，以及重写抽象类ABaseAgent中的public ResponseWrapper doEnhanceClass(CtClassctClass)方法和public String getCheckRule()方法。其中，public ResponseWrapperdoEnhanceClass(CtClass ctClass)方法用于编写检测逻辑、修改受保护的函数以及将修改后的受保护的函数重新加载到内存中。public String getCheckRule()方法用于匹配配置文件中的检测逻辑标识，以确定受保护的函数对应的检测逻辑。

由于不同的受保护的函数对应的检测逻辑不相同，因此，针对每一个检测逻辑都需要根据下述检测逻辑范式进行编写，检测逻辑编写范式如下：

public class FileTypeAgentTemplate extends ABaseAgent{

@Override

public ResponseWrapper doEnhanceClass(CtClass ctClass)throwsException{

//1、利用javassist获取在jvm内存中的“受保护的函数”

//2、编写检测逻辑代码，检测逻辑中可以存在白名单和黑名单，在该检测逻辑代码中包括读取白名单/黑名单的读取逻辑

//3、利用javassist提供的insertBefore(String str)方法，修改“受保护的函数”方法，将编写的检测逻辑添加到“受保护的函数”的函数体的首行位置

//4、利用Instrumentation中提供的redefineClasses方法将修改后的class文件重新加载到内存中

}

/*

*匹配检测逻辑标识，该检测逻辑标识与配置文件中的检测逻辑标识相对应

*匹配成功，则调用doEnhanceClass方法中的内容，完成检测逻辑的注入

*/

@Override

public String getCheckRule(){

return"fileTypeCheck"；

}

}

应当知道的是，虽然开发人员或者运维人员能够根据程序特征知道该程序中哪些函数存在一定的安全风险，并预先为存在安全风险的函数加载了检测逻辑，以保证函数的安全性和程序的正常运行。但是，随着攻击方式的不断迭代更新，以及用户需求的更改，需要开发人员或者运维人员在未来遇到新的攻击方式以及用户需求更改时，也能够保证函数的安全性和程序的正常运行。

此时，通过更改配置文件中相关参数的方式能够确定新的被保护的函数，以及在代理程序中根据上述检测逻辑编写范式编写对应的检测逻辑，并将其加载到新的被保护的函数的预设位置上，或者更改已有的被保护的函数的检测逻辑，以应对未来可能出现的风险和需求。

本申请实施例通过配置文件的形式对需要保护的函数进行配置，由于配置文件可更改和易于操作的特性，操作人员能够通过操作配置文件实现对想要保护的函数的配置。再有，在配置文件中配置受保护的函数对应的检测逻辑的标识，以使能通过检测逻辑标识找到与受保护的函数对应的检测逻辑，保证了被加载到受保护的函数中的检测逻辑与受保护的函数是一一对应的关系，进一步保证了安全防护的准确度。

在一些实施例中，配置文件还包括参数索引；服务器执行受保护的函数中的检测逻辑，包括：服务器根据检测逻辑对参数索引对应的受保护的函数的参数进行检测。

在具体实施过程中，除了确定受保护的函数外，还需要确定对受保护的函数中的哪一个参数进行检测，因此，配置文件中还配置有参数索引，使得检测逻辑能根据该参数索引对参数索引对应的受保护的函数的参数进行检测。

需要说明的是，若受保护的函数包括多个参数，可以在配置文件中配置一个参数索引，也可以在配置文件中配置多个参数索引，配置多个参数索引时，应当注意参数索引的顺序。在配置多个参数索引时，以使检测逻辑能对受保护的函数中的多个参数进行检测。但应当注意的是，由于一个受保护的函数对应一个检测逻辑，因此，即使需要对多个参数进行检测，但是执行的检测逻辑都是相同的。

本申请实施例通过在配置文件中配置受保护的函数的参数索引，以使检测逻辑能针对性的对受保护的函数中的参数进行检测，保证了安全防护的准确度。

图2为本申请实施例提供的一种程序运行时加载代理程序的时序图，为了便于理解如何根据配置文件确定受保护的函数以及如何根据检测逻辑范式编写检测逻辑，从而实现对受保护的函数的防护，本申请实施例结合图2所示内容给出对文件写入函数(FileOutputStream)进行防护的示例，具体如下：

首先，编写配置文件，根据配置文件确定受保护的函数，即图2所示的编写防护目标到xml文件。配置文件的形式请参见上述实施例，此处不再赘述。

由于配置好配置文件后，配置文件存储在磁盘中，应用程序需要将配置文件读取到程序内容中，方便后续的交互，即图2所示的读取xml文件并封装成参数。在进行读取时，执行的读取逻辑需要继承AbstractInitConfig对象，并重写init方法。具体如下：

确定了受保护的函数后，需要编写对应的检测逻辑，检测逻辑编写范式请参见上述实施例，此处不再赘述。但需要说明的是，由于本实施例是编写文件写入函数(FileOutputStream)对应的检测逻辑，因此在检测逻辑编写范式中将涉及到“受保护的函数”的地方替换为FileOutputStream函数即可。相应的，检测逻辑中读取白名单和黑名单的读取逻辑也需要继承AbstractInitConfig对象，并重写init方法，白名单和黑名单的具体设置请参见上述实施例，此处不再赘述。

如图2所示，编写好检测逻辑后，被防护应用利用attach技术加载agent代理程序中的检测逻辑，检测逻辑对由xml文件封装成的参数进行解析，并利用Instrumentation获取已经加载到内存的受保护的函数的class信息与配置文件中的防护目标进行匹配，具体匹配到函数所在的类名，函数名、参数索引等，当匹配成功时，利用javassist字节码技术动态修改匹配后对应的class内容，增加检测逻辑。再将整体修改的字节信息重新加载到内存中。需要知道的是，只有当程序在运行过程中，且触发到受保护的函数时，检测逻辑才会进行安全检测。

图3为本申请实施例提供的一种程序运行装置结构示意图，如图3所示，该装置包括：触发模块301和运行模块302。

触发模块301，用于在运行程序过程中，若触发受保护的函数，则执行受保护的函数中的检测逻辑；其中，受保护的函数包括检测逻辑和函数体；检测逻辑为在安全防护模块启动后，从代理程序中获取并加载在函数体的预设位置上；运行模块302，用于在利用检测逻辑检测通过的情况下，运行函数体。

在上述实施例的基础上，该装置还包括检测模块，用于若检测逻辑检测到传入受保护的函数的参数存在攻击行为，则对攻击行为进行拦截，并停止运行函数体。

在上述实施例的基础上，触发模块301具体用于通过检测逻辑读取预先配置的白名单，白名单中包括跳过检测的函数请求信息；若白名单包括受保护的函数对应的函数请求信息，则跳过检测逻辑，并执行函数体。

在上述实施例的基础上，触发模块301具体用于通过检测逻辑读取预先配置的黑名单，黑名单中包括禁止访问的函数请求信息；若黑名单包括受保护的函数对应的函数请求信息，则禁止受保护的函数执行。

在一些实施例中，该装置还包括防护检测模块，用于通过保护线程检测受保护的函数的防护开启情况；其中，保护线程在程序运行的过程中被启动；若防护开启情况为未正常开启，则重新从代理程序中获取并加载检测逻辑在函数体的预设位置上。

在上述实施例的基础上，该装置还包括读取模块，用于在安全防护模块启动后，读取配置文件；其中，配置文件包括函数所在类名、函数名和检测逻辑标识；根据函数所在类名和函数名确定受保护的函数的函数体；根据检测逻辑标识确定代理程序中与检测逻辑标识对应的检测逻辑，并将检测逻辑写入函数体的预设位置上。

在上述实施例的基础上，配置文件还包括参数索引；触发模块301具体用于根据检测逻辑对参数索引对应的受保护的函数的参数进行检测。

图4为本申请实施例提供的电子设备结构示意图，如图4所示，所述电子设备，包括处理器(processor)401、存储器(memory)402和总线403；其中，所述处理器401和存储器402通过所述总线403完成相互间的通信。所述处理器401用于调用所述存储器402中的程序指令，以执行上述各方法实施例所提供的方法。

处理器401可以是一种集成电路芯片，具有信号处理能力。上述处理器401可以是通用处理器，包括中央处理器(Central Processing Unit，CPU)、网络处理器(NetworkProcessor，NP)等；还可以是数字信号处理器(DSP)、专用集成电路(ASIC)、现成可编程门阵列(FPGA)或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件。其可以实现或者执行本申请实施例中公开的各种方法、步骤及逻辑框图。通用处理器可以是微处理器或者该处理器也可以是任何常规的处理器等。

存储器402可以包括但不限于随机存取存储器(Random Access Memory，RAM)，只读存储器(Read Only Memory，ROM)，可编程只读存储器(Programmable Read-OnlyMemory，PROM)，可擦除只读存储器(Erasable Programmable Read-Only Memory，EPROM)，电可擦除只读存储器(Electrically Erasable Programmable Read-Only Memory，EEPROM)等。

本实施例公开一种计算机程序产品，所述计算机程序产品包括存储在非暂态计算机可读存储介质上的计算机程序，所述计算机程序包括程序指令，当所述程序指令被计算机执行时，计算机能够执行上述各方法实施例所提供的方法，例如包括：在运行程序过程中，若触发受保护的函数，则执行受保护的函数中的检测逻辑；其中，受保护的函数包括检测逻辑和函数体；检测逻辑为在安全防护模块启动后，从代理程序中获取并加载在函数体的预设位置上；在利用检测逻辑检测通过的情况下，运行函数体。

本实施例提供一种非暂态计算机可读存储介质，所述非暂态计算机可读存储介质存储计算机指令，所述计算机指令使所述计算机执行上述各方法实施例所提供的方法，例如包括：在运行程序过程中，若触发受保护的函数，则执行受保护的函数中的检测逻辑；其中，受保护的函数包括检测逻辑和函数体；检测逻辑为在安全防护模块启动后，从代理程序中获取并加载在函数体的预设位置上；在利用检测逻辑检测通过的情况下，运行函数体。

在本申请所提供的实施例中，应该理解到，所揭露装置和方法，可以通过其它的方式实现。以上所描述的装置实施例仅仅是示意性的，例如，所述单元的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，又例如，多个单元或组件可以结合或者可以集成到另一个系统，或一些特征可以忽略，或不执行。另一点，所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些通信接口，装置或单元的间接耦合或通信连接，可以是电性，机械或其它的形式。

另外，作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部单元来实现本实施例方案的目的。

再者，在本申请各个实施例中的各功能模块可以集成在一起形成一个独立的部分，也可以是各个模块单独存在，也可以两个或两个以上模块集成形成一个独立的部分。

以上所述仅为本申请的实施例而已，并不用于限制本申请的保护范围，对于本领域的技术人员来说，本申请可以有各种更改和变化。凡在本申请的精神和原则之内，所作的任何修改、等同替换、改进等，均应包含在本申请的保护范围之内。

Claims (10)

1.一种程序运行方法，其特征在于，所述方法包括：

在运行程序过程中，若触发受保护的函数，则执行所述受保护的函数中的检测逻辑；其中，所述受保护的函数包括检测逻辑和函数体；所述检测逻辑为在安全防护模块启动后，从代理程序中获取并加载在所述函数体的预设位置上；

在利用所述检测逻辑检测通过的情况下，运行所述函数体。

2.根据权利要求1所述的方法，其特征在于，所述方法还包括：

若所述检测逻辑检测到传入所述受保护的函数的参数存在攻击行为，则对所述攻击行为进行拦截，并停止运行所述函数体。

3.根据权利要求1所述的方法，其特征在于，所述执行所述受保护的函数中的检测逻辑，包括：

通过所述检测逻辑读取预先配置的白名单，所述白名单中包括跳过检测的函数请求信息；

若所述白名单包括所述受保护的函数对应的函数请求信息，则跳过所述检测逻辑，并执行所述函数体。

4.根据权利要求1所述的方法，其特征在于，所述执行所述受保护的函数中的检测逻辑，包括：

通过所述检测逻辑读取预先配置的黑名单，所述黑名单中包括禁止访问的函数请求信息；

若所述黑名单包括所述受保护的函数对应的函数请求信息，则禁止所述受保护的函数执行。

5.根据权利要求1所述的方法，其特征在于，在所述安全防护模块启动后，所述方法还包括：

通过保护线程检测所述受保护的函数的防护开启情况；其中，所述保护线程在所述程序运行的过程中被启动；

若所述防护开启情况为未正常开启，则重新从代理程序中获取并加载所述检测逻辑在所述函数体的预设位置上。

6.根据权利要求1-5任一所述的方法，其特征在于，所述若触发受保护的函数，则执行所述受保护的函数中的检测逻辑之前，所述方法还包括：

在所述安全防护模块启动后，读取配置文件；其中，所述配置文件包括函数所在类名、函数名和检测逻辑标识；

根据所述函数所在类名和所述函数名确定受保护的函数的函数体；

根据所述检测逻辑标识确定代理程序中与所述检测逻辑标识对应的检测逻辑，并将所述检测逻辑写入所述函数体的预设位置上。

7.根据权利要求6所述的方法，其特征在于，所述配置文件还包括参数索引；所述执行所述受保护的函数中的检测逻辑，包括：

根据所述检测逻辑对所述参数索引对应的所述受保护的函数的参数进行检测。

8.一种程序运行装置，其特征在于，所述装置包括：

触发模块，用于在运行程序过程中，若触发受保护的函数，则执行所述受保护的函数中的检测逻辑；其中，所述受保护的函数包括检测逻辑和函数体；所述检测逻辑为在安全防护模块启动后，从代理程序中获取并加载在所述函数体的预设位置上；

运行模块，用于在利用所述检测逻辑检测通过的情况下，运行所述函数体。

9.一种电子设备，其特征在于，包括：处理器和存储器，所述存储器存储有所述处理器可执行的机器可读指令，所述机器可读指令被所述处理器执行时执行如权利要求1至7任一所述的方法。

10.一种计算机可读存储介质，其特征在于，该计算机可读存储介质上存储有计算机程序，该计算机程序被处理器运行时执行如权利要求1至7任一所述的方法。