Bill processing method and device, electronic equipment and storage medium

Abstract

The application provides a ticket processing method and device, electronic equipment and a storage medium. The method comprises the following steps: in response to an application request for a network access ticket issued by an application program, obtaining a target process for applying for a network access ticket, determining a target acquisition mode from a plurality of acquisition modes of the target process, and acquiring target process information of the target process according to the target acquisition mode, determining a target verification mode corresponding to the target process information, and performing security verification on the target process information according to the target verification mode to obtain a first verification result, and issuing a network access ticket to the application program when the first verification result indicates that the target process information passes the security verification. Through the application, the security of ticket issuance can be improved.

Description

Technical Field

[0001] This application relates to computer technology, and more particularly to a method, apparatus, electronic device, and storage medium for processing invoices. Background Technology

[0002] Ticket processing is a security mechanism used for authentication and authorization in a network environment. It involves issuing and reclaiming tickets, performing security verification on users or processes, and processing tickets based on the verification results to ensure that only authorized users or processes can access specific resources. With technological advancements, security verification has evolved, introducing behavior-based authentication, multi-factor authentication, risk-based authentication, and zero-trust authentication concepts. However, the process-based ticket application and usage method carries security risks. When a process is injected with malicious code, the malicious code or module can run as that process, abnormally accessing specific resources and reducing the security of ticket issuance. Summary of the Invention

[0003] This application provides a bill processing method, apparatus, electronic device, and storage medium that can improve the security of bill issuance.

[0004] The technical solution of this application embodiment is implemented as follows:

[0005] This application provides a bill processing method, the method comprising:

[0006] In response to a request for a network access ticket issued by an application, obtain the target process for requesting the network access ticket;

[0007] From multiple acquisition methods of the target process, a target acquisition method is determined, and target process information of the target process is acquired according to the target acquisition method, wherein different acquisition methods are used to acquire different process information of the target process;

[0008] Determine the target verification method corresponding to the target process information, and perform security verification on the target process information according to the target verification method to obtain a first verification result;

[0009] When the first verification result indicates that the target process information has passed the security verification, the network access ticket is issued to the application.

[0010] This application provides a bill processing device, including:

[0011] The data acquisition module is used to respond to a network access ticket application request issued by the application, obtain the target process for applying for the network access ticket; determine the target acquisition method from multiple acquisition methods of the target process, and acquire the target process information of the target process according to the target acquisition method, wherein different acquisition methods are used to acquire different process information of the target process;

[0012] The verification module is used to determine the target verification method corresponding to the target process information, and to perform security verification on the target process information according to the target verification method to obtain a first verification result;

[0013] The issuance module is used to issue the network access ticket to the application when the first verification result indicates that the target process information has passed the security verification.

[0014] This application provides an electronic device, including:

[0015] Memory is used to store executable instructions for a computer;

[0016] The processor, when executing computer-executable instructions stored in the memory, implements the ticket processing method provided in the embodiments of this application.

[0017] This application provides a computer-readable storage medium storing a computer program or computer-executable instructions for implementing the ticket processing method provided in this application when executed by a processor.

[0018] This application provides a computer program product, including a computer program or computer executable instructions. When the computer program or computer executable instructions are executed by a processor, they implement the ticket processing method provided in this application.

[0019] The embodiments of this application have the following beneficial effects:

[0020] From multiple acquisition methods for the target process, a target acquisition method is determined, and target process information of the target process is acquired according to the target acquisition method. The target verification method corresponding to the target process information is determined, and security verification of the target process information is performed according to the target verification method to obtain a first verification result. Then, when the first verification result indicates that the target process information has passed the security verification, a network access ticket is issued to the application. In this way, by selecting different acquisition methods or combinations of acquisition methods, different process information of the target process is acquired, and different verification methods are used for security verification based on different process information. This avoids malicious behavior from injecting into the target process in different ways, thereby improving the security of process verification. In addition, by flexibly selecting from multiple acquisition methods of the target process and performing security verification based on different process information, network access tickets are issued under different conditions, thereby improving the security of ticket issuance. Attached Figure Description

[0021] Figure 1 This is a schematic diagram of the architecture of the invoice processing system provided in the embodiments of this application;

[0022] Figure 2 This is a schematic diagram of the structure of the electronic device provided in the embodiments of this application;

[0023] Figure 3 This is a first flowchart illustrating the bill processing method provided in this application embodiment;

[0024] Figure 4 This is a schematic diagram of the second process of the bill processing method provided in the embodiments of this application;

[0025] Figure 5 This is a schematic diagram of the third process of the bill processing method provided in the embodiments of this application;

[0026] Figure 6 This is a schematic diagram of the fourth process of the bill processing method provided in the embodiments of this application;

[0027] Figure 7 This is a schematic diagram illustrating the principle of determining the number of data collection methods provided in the embodiments of this application;

[0028] Figure 8 This is a schematic diagram of the allocation of available resources provided in an embodiment of this application;

[0029] Figure 9 This is a schematic diagram of the fifth process of the bill processing method provided in the embodiments of this application;

[0030] Figure 10 This is a schematic diagram of the sixth process of the bill processing method provided in the embodiments of this application;

[0031] Figure 11This is a schematic diagram of the seventh process of the bill processing method provided in the embodiments of this application;

[0032] Figure 12 This is a schematic diagram of the eighth process of the bill processing method provided in the embodiments of this application;

[0033] Figure 13 This is a schematic diagram of the security verification principle provided in the embodiments of this application;

[0034] Figure 14 This is a schematic diagram of user access to resources provided in an embodiment of this application;

[0035] Figure 15 This is a flowchart of the invoice processing provided in the embodiments of this application;

[0036] Figure 16 This is a flowchart of the process for accessing enterprise resources provided in the embodiments of this application.

[0037] It should be noted that the terms "first" and "second" mentioned above are only used to distinguish between different options and do not represent the degree of superiority or inferiority of the options or their priority in the implementation process. Detailed Implementation

[0038] To make the objectives, technical solutions, and advantages of this application clearer, the application will be further described in detail below with reference to the accompanying drawings. The described embodiments should not be regarded as limitations on this application. All other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0039] In the following description, references are made to “some embodiments,” which describe a subset of all possible embodiments. However, it is understood that “some embodiments” may be the same subset or different subsets of all possible embodiments and may be combined with each other without conflict.

[0040] In the following description, the terms "first, second, third" are used merely to distinguish similar objects and do not represent a specific ordering of objects. It is understood that "first, second, third" may be interchanged in a specific order or sequence where permitted, so that the embodiments of this application described herein can be implemented in an order other than that illustrated or described herein.

[0041] In this application embodiment, the terms "module" or "unit" refer to a computer program or part of a computer program that has a predetermined function and works with other related parts to achieve a predetermined goal, and can be implemented wholly or partially using software, hardware (such as processing circuitry or memory), or a combination thereof. Similarly, a processor (or multiple processors or memory) can be used to implement one or more modules or units. Furthermore, each module or unit can be part of an overall module or unit that includes the functionality of that module or unit.

[0042] In the implementation of this application, the collection and processing of relevant data should strictly comply with the requirements of relevant national laws and regulations, obtain the informed consent or separate consent of the personal information subject, and carry out subsequent data use and processing within the scope of laws and regulations and the authorization of the personal information subject.

[0043] Unless otherwise defined, all technical and scientific terms used in the embodiments of this application have the same meaning as commonly understood by one of ordinary skill in the art. The terminology used in the embodiments of this application is for the purpose of describing the embodiments of this application only and is not intended to limit this application.

[0044] Before providing a further detailed description of the embodiments of this application, the nouns and terms involved in the embodiments of this application will be explained, and the nouns and terms involved in the embodiments of this application shall be interpreted as follows.

[0045] 1) Acquisition method refers to the method used to collect process information of the target process. The acquisition method can be the acquisition method through different plug-ins, interfaces, or tools. A plug-in is a software component that can be added to a main program to increase or extend its functionality. Plug-ins allow the main program to add new functions without modifying the original code. An interface is a specification or mechanism for interaction between two different systems or components. It is used to define the format, method, and rules for data exchange so that different software components can work together. A tool is software or hardware designed for a specific task or purpose. This application does not limit the tools. Tools can be simple command-line programs, complex graphical user interface applications, etc.

[0046] 2) Target process information is process information obtained by collecting target process information through target acquisition method. Target process information includes at least one of the following: module information of module, access information of target process and memory information of target process.

[0047] 3) Target verification methods are methods or strategies used to verify the security of target process information, such as checking whether the process has loaded unauthorized modules or has abnormal behavior.

[0048] 4) Security verification is the process of verifying the target process according to a preset security policy.

[0049] 5) The first verification result is used to indicate whether the target process is safe. When a process loads a suspicious module, the first verification result is used to indicate the risk or prohibit the target process from continuing to execute.

[0050] In related technologies, network access tickets are applied for and used on a process-by-process basis. When an application process within a device initiates network access, the network access parameters are sent to the management client by the terminal's full-traffic proxy. The management client collects general information about the process based on the process identifier. Based on this information, the management client applies for a network access ticket from the server. If the ticket application is successful, unless the ticket expires or the server identifies a security risk in the application, if the process is injected with malicious code, the malicious code or module can run as that process and use the network access ticket to access other resources in the enterprise network, performing unauthorized resource access, data reading, modification, or deletion operations, causing significant security risks such as data leakage and reducing the accuracy of security verification. To address the above problems, this application provides a ticket processing method, apparatus, electronic device, computer-readable storage medium, and computer program product to improve the security of ticket processing.

[0051] The invoice processing method described in this application can be applied to various fields, such as resource application, office interaction, etc. That is, the invoice processing method in this application is not limited to a certain field.

[0052] The following describes exemplary applications of the electronic device provided in the embodiments of this application. The device provided in the embodiments of this application can be implemented as a terminal or as a server. The following will describe exemplary applications when the device is implemented as a server.

[0053] See Figure 1 , Figure 1 This is a schematic diagram of the architecture of the invoice processing system 100 provided in the embodiments of this application. In order to support an invoice processing application, the terminal (terminal 400 is shown as an example) connects to the server 200 through the network 300. The network 300 can be a wide area network or a local area network, or a combination of the two.

[0054] Terminal 400 is used to send the target process for applying for a network access ticket to server 200 via network 300. Server 200 is used to determine the target acquisition method from multiple acquisition methods of the target process, and acquire the target process information of the target process according to the target acquisition method. Server 200 determines the target verification method corresponding to the target process information, and performs security verification on the target process information according to the target verification method to obtain a first verification result. When the first verification result indicates that the target process information has passed the security verification, server 200 issues a network access ticket to the application and returns the network access ticket to terminal 400. Terminal 400 displays the network access ticket through graphical interface 410.

[0055] The following is an example of terminal 400 processing tickets.

[0056] In some embodiments, terminal 400 can independently complete the ticket processing task. For example, in response to a network access ticket application request issued by an application, terminal 400 obtains the target process for applying for the network access ticket, determines the target acquisition method from multiple acquisition methods of the target process, acquires the target process information of the target process according to the target acquisition method, determines the target verification method corresponding to the target process information, performs security verification on the target process information according to the target verification method, obtains a first verification result, and when the first verification result indicates that the target process information has passed the security verification, issues a network access ticket to the application and displays the network access ticket through the graphical interface 410.

[0057] In one implementation scenario, a server or terminal can issue a network access ticket to a process requesting access to resources. In response to a request for a network access ticket from an application, the server obtains the target process for requesting the ticket, determines the target collection method from multiple collection methods for the target process, collects the target process information based on the target collection method, determines the target verification method corresponding to the target process information, and performs security verification on the target process information based on the target verification method to obtain a first verification result. When the first verification result indicates that the target process information has passed the security verification, the server issues a network access ticket to the application and obtains access to resources based on the network access ticket.

[0058] In one implementation scenario, a server or terminal can issue network access tickets to processes accessing user interaction information during office interactions. Responding to a network access ticket request from an application, it obtains the target process for requesting the ticket, determines the target acquisition method from multiple acquisition methods for the target process, acquires the target process information based on the target acquisition method, determines the corresponding target verification method for the target process information, and performs security verification on the target process information according to the target verification method to obtain a first verification result. When the first verification result indicates that the target process information has passed security verification, a network access ticket is issued to the application, and the user's interaction information is obtained and displayed based on the network access ticket.

[0059] In some embodiments, server 200 may be an independent physical server, a server cluster or distributed system composed of multiple physical servers, or a cloud server that provides basic cloud computing services such as cloud services, cloud databases, cloud computing, cloud functions, cloud storage, network services, cloud communication, middleware services, domain name services, security services, content delivery networks (CDN), and big data and artificial intelligence platforms.

[0060] Terminal 400 can be a smartphone, tablet computer, laptop computer, desktop computer, smart speaker, smartwatch, smart voice interaction device, smart home appliance, vehicle terminal, aircraft, etc., but is not limited to these. The terminal and server can be directly or indirectly connected via wired or wireless communication, which is not limited in this embodiment.

[0061] See Figure 2 , Figure 2 This is a schematic diagram of the structure of the electronic device provided in the embodiments of this application. Figure 2 The electronic device 500 shown can be Figure 1 The terminal 400 or server 200, and the electronic device 500 include: at least one processor 510, memory 550, and at least one network interface 520. The various components in server 200 are coupled together via a bus system 540. It is understood that the bus system 540 is used to implement communication between these components. In addition to a data bus, the bus system 540 also includes a power bus, a control bus, and a status signal bus. However, for clarity, in... Figure 2 The general labeled all buses as Bus System 540.

[0062] The processor 510 can be an integrated circuit chip with signal processing capabilities, such as a general-purpose processor, a digital signal processor (DSP), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. The general-purpose processor can be a microprocessor or any conventional processor, etc.

[0063] User interface 530 includes one or more output devices 531 that enable the presentation of media content, including one or more speakers and / or one or more visual displays. User interface 530 also includes one or more input devices 532, including user interface components that facilitate user input, such as a keyboard, mouse, microphone, touch screen display, camera, other input buttons and controls;

[0064] In some embodiments, when the terminal 400 independently completes the ticket processing task, the server 200 provided in this application embodiment does not include the user interface 530.

[0065] The memory 550 may be removable, non-removable, or a combination thereof. Exemplary hardware devices include solid-state storage, hard disk drives, optical disk drives, etc. The memory 550 may optionally include one or more storage devices physically located away from the processor 510.

[0066] The memory 550 may include volatile memory or non-volatile memory, or both. The non-volatile memory may be read-only memory (ROM), and the volatile memory may be random access memory (RAM). The memory 550 described in this application embodiment is intended to include any suitable type of memory.

[0067] In some embodiments, memory 550 is capable of storing data to support various operations, examples of which include programs, modules, and data structures or subsets or supersets thereof, as illustrated below.

[0068] Operating system 551 includes system programs for handling various basic system services and performing hardware-related tasks, such as the framework layer, core library layer, driver layer, etc., for implementing various basic business functions and handling hardware-based tasks;

[0069] The network communication module 552 is used to reach other computing devices via one or more (wired or wireless) network interfaces 520, exemplary network interfaces 520 including: Bluetooth, WiFi, and Universal Serial Bus (USB), etc.

[0070] Presentation module 553 is configured to enable the presentation of information (e.g., a user interface for operating peripheral devices and displaying content and information) via one or more output devices 531 (e.g., a display screen, a speaker, etc.) associated with user interface 530;

[0071] In some embodiments, when the ticket processing task is completed independently by the terminal 400, the server 200 provided in this application embodiment may not include the presentation module 553.

[0072] The input processing module 554 is used to detect and translate one or more user inputs or interactions from one or more input devices 532; in some embodiments, when the terminal 400 independently completes the ticket processing task, the server 200 provided in this application embodiment may not include the presentation module 553.

[0073] In some embodiments, the apparatus provided in this application can be implemented in software. Figure 2 A ticket processing device 555 stored in memory 550 is shown. This device can be software in the form of programs and plug-ins, and includes the following software modules: a data acquisition module 5551, a security verification module 5552, a ticket issuance module 5553, and a ticket collection module 5554. These modules are logically connected and can therefore be arbitrarily combined or further separated according to the functions they implement. The functions of each module will be described below.

[0074] It should be noted that, based on the understanding of the following examples of bill processing, those skilled in the art can apply the bill processing method provided in the embodiments of this application to perform security verification of processes.

[0075] See Figure 3 , Figure 3 This is a schematic diagram of the first process of the bill processing method provided in the embodiments of this application, which will be combined with Figure 3 The steps shown will be explained below. The ticket processing method provided in this application embodiment can be implemented by the server or terminal alone, or by the server and terminal working together. The following will be an example of the server and terminal working together.

[0076] In step 101, in response to a request for a network access ticket issued by the application, a target process for requesting a network access ticket is obtained.

[0077] Here, an application refers to software designed to complete a specific task. This application embodiment does not limit the scope of the application; it can be desktop software, mobile applications, web applications, etc. An application consists of a user interface and backend logic. The user interface allows users to interact with the program, while the backend logic handles specific task logic, which can be word processing software, image editing software, games, browsers, etc. A network access ticket is a network credential used to verify a user's identity and authorization in network access control. When a user attempts to connect to a protected network, the network access ticket is used to confirm whether the user has the right to access the network. The network access ticket allows the user to access network resources for a certain period of time. The target process is the process currently executing or waiting to execute that is used to request a network access ticket. A process is an execution instance of an application, enabling the operating system to allocate and schedule resources through processes.

[0078] It should be noted that the target process is created by the application through the operating system's interface and is used to request network access tickets from the server.

[0079] In some embodiments, after obtaining the target process for applying for a network access ticket, the following steps are performed: adding the target process to the process queue; when the addition time of all processes in the process queue is greater than the addition time of the target process, the operation of collecting the target process information according to the target collection method is performed.

[0080] It should be noted that a process queue usually refers to a data structure in the operating system kernel used to manage and schedule processes. A process queue is used to organize processes that are ready to execute but have not yet been scheduled. Process queues can be executed sequentially based on different criteria, such as process priority and process status (e.g., ready, blocked, running).

[0081] In step 102, the target acquisition method is determined from the multiple acquisition methods of the target process, and the target process information of the target process is acquired according to the target acquisition method.

[0082] Different acquisition methods are used to collect different process information of the target process.

[0083] In some embodiments, see Figure 4 , Figure 4 This is a schematic diagram of the second process of the bill processing method provided in the embodiments of this application, which is aimed at... Figure 3 The step 102 shown illustrates determining the target acquisition method from multiple acquisition methods of the target process, which can be achieved through... Figure 4 Steps 1021A to 1023A are implemented, and will be explained in detail below.

[0084] In step 1021A, the common fields of the target process are obtained.

[0085] Among them, general fields are those that do not require collection from the target process through multiple collection methods.

[0086] Here, the general fields include at least one of the following: a process name field and a process execution field. The process name field identifies the name of the target process, and the process execution field indicates that the target process is being executed. The process execution field includes at least one of the following: a file path field, a file tag field, and a file hash field. The file path field indicates the location where the process's executable file is stored, the file tag field identifies the process's executable file, and the file hash field is the hash value of the process's executable file, used to verify whether the process's executable file has been modified. The process's executable file is a file containing program instructions and data, which can be loaded into memory by the operating system for execution.

[0087] In some embodiments, step 1021A can be implemented by: obtaining the process identifier of the target process and obtaining the executable file associated with the process identifier; determining the process execution field of the executable file and the process name field used to characterize the process name of the target process as general fields of the general information of the target process.

[0088] It should be noted that the process identifier is used to uniquely identify each process running on the operating system.

[0089] In step 1022A, the full data collection rule is obtained, wherein the full data collection rule is used to instruct the target process to be collected through each collection method of the target process, and the full data collection rule includes at least one set rule field.

[0090] Here, a full data collection rule refers to a rule that performs complete data collection on the target process during the data collection process. Rule fields are the fields included in the collection rule. This application embodiment does not limit the set rule fields included in the full data collection rule; the set rule fields included in the full data collection rule can be set process name fields, set process execution fields, etc.

[0091] In step 1023A, when the similarity between the general field and any rule field is greater than or equal to the first similarity threshold, each acquisition method of the target process is determined as the target acquisition method.

[0092] In some embodiments, prior to step 1023A, the following steps are performed: determining the common field and its similarity to any rule field.

[0093] Following the above embodiments, the above "determining the similarity between general fields and arbitrary rule fields" can be achieved in the following way: determining the edit distance (e.g., 1) between general fields (e.g., the process name field "error function" of the target process) and arbitrary rule fields (e.g., the set process name field "error function body"); determining the maximum length (e.g., 5) between the length of the general field (e.g., 4) and the length of the arbitrary rule field (e.g., 5); and determining the ratio (e.g., 0.8) of the difference between the maximum length and the edit distance (e.g., 4) to the maximum length as the similarity between the general field and the arbitrary rule field.

[0094] It should be noted that edit distance is used to characterize the number of single-character edits (insertion, deletion, or replacement) required to transform a generic field into an arbitrary rule field. The number of single-character edits is the minimum number of edits required to transform a generic field into an arbitrary rule field. Taking the calculation of the edit distance between a generic field (such as "kitten") and an arbitrary rule field (such as "sitting") as an example, in this process, there are 2 replacements and 1 insertion. The first replacement is to replace "k" in "kitten" with "s" to get "sitten"; the second replacement is to replace "e" in "sitten" with "i" to get "sittin"; the insertion is to insert a "g" at the end of "sittin" to get "sitting". Therefore, the edit distance between the generic field and the arbitrary rule field is 3.

[0095] Following the above embodiments, the above-mentioned "determining the similarity between general fields and arbitrary rule fields" can also be achieved in the following way: encoding the general field (such as "error function") to obtain a first encoding feature (such as [0.14, 0.13, -0.06]); encoding the arbitrary rule field (such as "error function body") to obtain a second encoding feature (such as [0.14, 0.13, -0.06, 0.15, 0.03, 0.06]); and determining the similarity between the first encoding feature and the second encoding feature (such as 0.85) as the similarity between the general field and the arbitrary rule field.

[0096] It should be noted that the embodiments of this application do not limit the similarity. The similarity can be the cosine similarity, Euclidean distance, etc. between the first coding feature and the second coding feature.

[0097] For example, when the similarity (e.g., 0.9) between a general field (such as the process name field "ExampleProcessV2") and any rule field (such as the set process name field "ExampleProcess") is greater than or equal to the first similarity threshold (e.g., 0.85), each acquisition method of the target process is determined as the target acquisition method.

[0098] In some embodiments, after step 1023A, when the similarity between the general field and any rule field is less than the first similarity threshold, the "determine the process type of the target process based on the general field" in step 1021B and step 1022B are executed to obtain the target acquisition method.

[0099] Through the embodiments of this application, the collection method of the target process can be quickly determined by predefined rules and thresholds, improving the efficiency of data processing. By verifying the hash value and comparing similarity, the target process can be accurately identified and processed, reducing the risk of erroneous collection. At the same time, the execution of malicious software or tampered files can be detected and prevented, thus enhancing the security of the system.

[0100] In some embodiments, see Figure 5 , Figure 5 This is a schematic diagram of the third process of the bill processing method provided in the embodiments of this application, which is aimed at... Figure 3 The step 102 shown illustrates determining the target acquisition method from multiple acquisition methods of the target process, which can be achieved through... Figure 5 Steps 1021B to 1022B are implemented, and will be explained in detail below.

[0101] In step 1021B, the general fields of the target process are obtained, and the process type of the target process is determined based on the general fields. The general fields are those fields that do not need to be collected from the target process through multiple collection methods.

[0102] It should be noted that the process type is used to characterize the security level (i.e. risk level) of the process. This application does not limit the process type. The process type can be a high-risk process type, a suspicious process type, etc. The abnormal execution field belonging to the high-risk process type may involve fields used to characterize unauthorized access, data leakage or other malicious behavior; the abnormal execution field belonging to the suspicious process type may involve fields used to characterize legitimate programs being exploited, frequent access to sensitive files, attempts to modify system settings, and communication with other known malware.

[0103] In some embodiments, the "obtaining the common fields of the target process" in step 1021B is similar to step 1021A, and will not be described again here.

[0104] In some embodiments, the general fields include a process execution field, which indicates the target process to be executed. See [link to documentation]. Figure 6 , Figure 6 This is a schematic diagram of the fourth process of the bill processing method provided in the embodiments of this application, which is aimed at... Figure 5 In step 1021B shown, determining the process type corresponding to the target process based on a common field can be achieved through... Figure 6Steps 10211B to 10212B are implemented, and will be explained in detail below.

[0105] In step 10211B, when the process execution field includes the abnormal execution field, the mapping table is queried based on the abnormal execution field.

[0106] The exception execution field includes at least one of the following: exception file path field, exception file tag field, and exception file hash field. The exception file path field is used to indicate the location where the exception file is stored, the exception file tag field is used to identify the exception file, the exception file hash field is used to characterize the hash value of the exception executable file of the target process, and the mapping table is used to characterize the correspondence between different candidate exception execution fields and different candidate process types.

[0107] Here, the exception file is the abnormal executable file of the target process. The exception file path field indicates the path where the exception file is stored in memory. The exception file tag field is a numerical tag for the exception file, used to confirm that the application has not been modified or corrupted after signing. The exception file hash field is used to characterize the hash value of the abnormal executable file of the target process. The hash value is used to verify the integrity and consistency of the executable file; when the file is tampered with during transmission, its corresponding hash value will change. This application does not limit the correspondence between different candidate exception execution fields and different candidate process types. The correspondence can be multiple candidate exception execution fields corresponding to one candidate process type, or each candidate exception execution field corresponding to its own candidate process type.

[0108] It should be noted that a mapping table is a data structure used to store the correspondence between candidate exception execution fields and candidate process types. This application embodiment does not limit the mapping table. The mapping table can be a data structure implemented as a hash table, a data structure implemented as an array, etc., and is used to quickly perform lookup, insertion, and deletion operations on the correspondence between candidate exception execution fields and candidate process types. The hash table uses a hash function to calculate the index value and maps the input exception execution field to the position in the hash table to access the candidate process type.

[0109] In step 10212B, when a candidate abnormal execution field corresponding to the abnormal execution field is found in the mapping table, the candidate process type corresponding to the found candidate abnormal execution field is determined as the process type.

[0110] In some embodiments, the above-mentioned "querying out the candidate abnormal execution field corresponding to the abnormal execution field from the mapping table" can be achieved in the following way: when the similarity between any execution field in the mapping table and the abnormal execution field is greater than the similarity threshold, the arbitrary execution field in the mapping table is determined as a candidate abnormal execution field.

[0111] Following the above embodiments, the step of obtaining the similarity between any execution field and the abnormal execution field in the mapping table is similar to the step of "determining the similarity between the general field and any rule field" and will not be repeated here.

[0112] For example, taking the abnormal execution field as the abnormal file path field as an example, the mapping table includes the following correspondence: the process type corresponding to path 1 " / proc / 10001 / exe" is a high-risk process type, and the process type corresponding to path 2 " / proc / 23456 / exe" is a suspicious process type. When a candidate abnormal execution field (such as path 1) corresponding to the abnormal execution field (such as path " / proc / 10002 / exe") is found in the mapping table, the candidate process type (such as high-risk process type) corresponding to the candidate abnormal execution field is determined as the process type.

[0113] Through the embodiments of this application, potential security threats can be more accurately identified by recognizing and classifying abnormal execution fields, thereby improving system security. Assessing the security level of processes based on process type (such as high-risk process types, suspicious process types) facilitates rapid response and handling of security incidents, and allows the system to flexibly add new abnormal execution fields and process types to adapt to constantly changing security threats.

[0114] See also Figure 5 In step 1022B, based on the process type, the target acquisition method is determined from multiple acquisition methods of the target process.

[0115] Here, the target acquisition method refers to the method of acquiring process information of the target process. Different acquisition methods will acquire different process information of the target process.

[0116] In some embodiments, step 1022B can be implemented in the following way: query the collection method configuration table based on process type, wherein the collection method configuration table includes the correspondence between different candidate process types and different collection methods; when a candidate process type corresponding to the process type is found in the collection method configuration table, the collection method corresponding to the found candidate process type is determined as the target collection method.

[0117] Here, this application embodiment does not limit the correspondence between different candidate process types and different acquisition methods. The correspondence between different candidate process types and different acquisition methods can be that multiple candidate process types correspond to one acquisition method, or that each candidate process type corresponds to its own acquisition method. This application embodiment does not limit the acquisition method configuration table. The data structure of the acquisition method configuration table is similar to the data structure of the mapping table, and will not be described in detail here.

[0118] In some embodiments, the above-mentioned step of "when a candidate process type corresponding to the process type is found in the acquisition method configuration table, the acquisition method corresponding to the candidate process type is determined as the target acquisition method" is similar to step 10212B, and will not be repeated here.

[0119] In some embodiments, step 1022B can also be implemented in the following way: querying the quantity configuration table based on the process type, wherein the quantity configuration table includes the correspondence between different candidate process types and different quantities; when a candidate process type corresponding to the process type is found from the quantity configuration table, the quantity corresponding to the found candidate process type is determined as the target quantity; from multiple collection methods of the target process, the collection method that meets the target quantity is selected as the target collection method.

[0120] Here, this application embodiment does not limit the correspondence between different candidate process types and different quantities. The correspondence between different candidate process types and different quantities can be that multiple candidate process types correspond to one quantity, or that each candidate process type corresponds to its own quantity. This application embodiment does not limit the quantity configuration table. The data structure of the quantity configuration table is similar to the data structure of the mapping table, and will not be described in detail here.

[0121] As an example, Figure 7 This is a schematic diagram illustrating the principle of determining the number of data acquisition methods provided in an embodiment of this application. See also... Figure 7 When the process execution field includes the abnormal execution field, the mapping table is queried based on the abnormal execution field, and the candidate process type corresponding to the abnormal execution field is determined as the process type. The quantity configuration table is queried based on the process type, and the quantity corresponding to the process type is determined as the target quantity (e.g., 2). From the multiple collection methods of the target process (e.g., collection method A, collection method B, collection method C), the collection method that meets the target quantity is selected as the target collection method.

[0122] In some embodiments, the step of "when a candidate process type corresponding to the process type is found in the quantity configuration table, the quantity corresponding to the found candidate process type is determined as the target quantity" is similar to step 10212B, and will not be repeated here.

[0123] Following the above embodiments, the above-mentioned "selecting a collection method that meets the target number from multiple collection methods of the target process as the target collection method" can be implemented in at least one of the following ways: randomly selecting a collection method that meets the target number from multiple collection methods of the target process as the target collection method; or, obtaining the execution resource amount and available resource amount of each collection method; sorting multiple collection methods based on the execution resource amount to obtain a sorting result; determining the collection method that meets the target number in the sorting result as the target collection method, wherein the sum of the execution resource amounts of the collection methods that meet the target number is less than or equal to the available resource amount according to the process type corresponding to the collection method.

[0124] It should be noted that the above steps of "sorting multiple collection methods based on execution resource quantity to obtain the sorting result; determining the collection methods that meet the target number in the sorting result as the target collection method. Among them, the sum of the execution resource quantities of the collection methods that meet the target number is less than or equal to the available resource quantity" are referred to steps 1021C to 1023C.

[0125] As an example, Figure 8 This is a schematic diagram illustrating the allocation of available resources according to an embodiment of this application. See also... Figure 8 After determining the available resources on the client, at least one collection method and the execution resource amount of each collection method are obtained: the execution resource amount of collection method A is 5GB, the execution resource amount of collection method B is 12GB, the execution resource amount of collection method C is 10GB, etc. The available resources are sorted in ascending order of execution resource amount, and some collection methods are selected for collection. Among them, the sum of the execution resource amounts of some collection methods is less than or equal to the available resource amount.

[0126] In some embodiments, see Figure 9 , Figure 9 This is a schematic diagram of the fifth process of the bill processing method provided in the embodiments of this application, which is aimed at... Figure 3 The step 102 shown illustrates determining the target acquisition method from multiple acquisition methods of the target process, which can be achieved through... Figure 9 Steps 1021C to 1023C are implemented, and will be explained in detail below.

[0127] In step 1021C, the execution resource amount and available resource amount for each acquisition method are obtained.

[0128] Here, available resources refer to resources that are yet to be allocated, i.e., the difference between total resources and allocated resources. This application embodiment does not limit the form of resources; resources can be threads, computing power, memory space, etc. The execution resource quantity for each acquisition method is the number of resources allocated to the plugin corresponding to that acquisition method.

[0129] For example, the difference between the total resources (e.g., 1GB of space) and the allocated resources (e.g., 0.2GB of space) (e.g., 0.8GB of space) is determined as the available resource amount. The execution resource amount for the plugin corresponding to acquisition method A is 5GB of storage space, and the execution resource amount for the plugin corresponding to acquisition method B is 20GB of storage space.

[0130] In step 1022C, the multiple acquisition methods are sorted based on the amount of execution resources to obtain the sorting result.

[0131] It should be noted that the embodiments of this application do not limit the method of obtaining the sorting results. The sorting results can be obtained by ascending order, descending order, etc.

[0132] For example, if collection method A corresponds to an execution resource amount (e.g., 0.85) and collection method B corresponds to an execution resource amount (e.g., 0.8), and the sorting result is obtained in ascending order, the collection methods are sorted in ascending order based on the execution resource amount (e.g., 0.85 and 0.8) to obtain the ascending sorted result (i.e., the sorted result is [B, A]). Alternatively, if the sorting result is obtained in descending order, the collection methods are sorted in descending order based on the execution resource amount (e.g., 0.85 and 0.8) to obtain the descending sorted result (i.e., the sorted result is [A, B]).

[0133] In step 1023C, some acquisition methods in the sorting results are determined as the target acquisition methods.

[0134] In some cases, the sum of the execution resources for certain acquisition methods is less than or equal to the available resources.

[0135] In some embodiments, step 1023C can be implemented by determining a preset number of collection methods in the sorting results as the target collection method.

[0136] For example, with a preset quantity of 1, if the sorting result is obtained in ascending order, the last one in the sorting result (i.e., the ascending sorting result such as [sampling method B, sampling method A]) will be selected as the target sampling method. Alternatively, if the sorting result is obtained in descending order, the first one in the sorting result (i.e., the descending sorting result such as [sampling method A, sampling method B]) will be selected as the target sampling method.

[0137] Through the embodiments of this application, by considering the amount of execution resources and available resources, system resources can be allocated more effectively, avoiding resource waste, and selecting the collection method with the least resource consumption, thereby improving system efficiency. The system is allowed to flexibly select the collection method based on different process types and resource conditions, improving the flexibility of security verification.

[0138] In some embodiments, see Figure 10 , Figure 10 This is a schematic diagram of the sixth process of the bill processing method provided in the embodiments of this application, which is aimed at... Figure 3 The step 102 shown illustrates the acquisition of target process information based on the target acquisition method, which can be achieved through... Figure 10 Steps 1021D to 1023D are implemented, and will be explained in detail below.

[0139] Perform at least one of the processes in steps 1021D to 1023D.

[0140] In step 1021D, when the target acquisition method is used to acquire process information of the module that represents the target process, the module loading plugin is called to obtain the module loaded by the target process and the module information of the module is determined as the target process information.

[0141] Here, a module loading plugin (such as the "PsSetLoadImageNotifyRoutine" plugin) refers to a plugin that dynamically loads modules by querying the target process in the system. This application does not limit the scope of modules; a module can be a component or a library used to provide specific functionality. Modules can be called by the main program or other modules. A component is a replaceable, independent module in the system used to implement specific encapsulated functions and interact with the outside world through a preset interface. A library contains core code resources shared by multiple applications. Module information is specific information used to identify a module. This application embodiment does not limit the module information; it can include the module's base address, entry point, module size, and module name. The base address refers to the module's starting position in memory; all addresses within the module are offsets relative to the base address. The entry point is the starting point for execution after the module is loaded. For executable files, the entry point is usually the program's main function; for dynamic link libraries, it might be an initialization function called when the module is loaded. The entry point address is the location where the system begins executing the module's code after it is loaded into memory. The module size refers to the total number of bytes occupied by the module in memory, including code, data, and any other resources. The module name is the module's identifier, usually a string used to distinguish different modules. A plugin is a component used to add specific functionality to an application. Plugins integrate seamlessly with applications, allowing users to extend or customize application functionality without modifying the application's own code.

[0142] In some embodiments, the module loading plugin includes a preset first callback function. The first callback function includes a loading path for representing the loaded module and a process identifier for identifying the process. The above-mentioned "obtaining the module loaded by the target process through the module loading plugin" can be implemented in the following way: in response to the target process loading the module, the preset first callback function is queried based on the process identifier of the target process to obtain the loading path corresponding to the process identifier, and the module information of the module is queried based on the loading path.

[0143] It should be noted that the first callback function is a function that is called when a specific event or condition occurs. The callback function is a parameter function passed as an argument to another function. After the external function completes a specific task, it calls the parameter function to complete the subsequent processing.

[0144] For example, based on the process identifier of the target process (e.g., 12138), the preset first callback function is queried to obtain the loading path corresponding to the process identifier (e.g., " / usr / share / my_actions: / path / to / custom_actions"), and the module information of the module is queried based on the loading path.

[0145] In some embodiments, before determining the module information of the module as the target process information in step 1021D, the following steps are performed: determining a first time point when the loading request of the module is received and a second time point when the module is historically loaded, wherein the second time point is less than the first time point; when the difference between the first time point and the second time point is greater than a time threshold, the operation of determining the module information of the module as the target process information is performed.

[0146] Here, a module load request indicates that the target process requests to load the module, and in response to the module load request, the target process loads the module. The second point in time when a module is historically loaded is the time when the module was last loaded.

[0147] It should be noted that when the target process loads the module for the first time, it performs an operation to determine the module information as the target process information.

[0148] Following the example above, when the difference between the first time point (e.g., 230513, where "230513" represents May 13, 2023) and the second time point (e.g., 240513) (e.g., 010000) is greater than the time threshold (e.g., 000001), the operation of determining the module information of the module as the target process information is executed.

[0149] Following the example above, the module information (such as the module name) of the module is determined as the target process information.

[0150] In step 1022D, when the target acquisition method is used to acquire process information that represents the access information of the target process, the process access plugin is invoked, the handle of the target process is obtained through the process access plugin, and the access information corresponding to the handle is determined as the target process information.

[0151] Here, the access information of the target process refers to the information about third-party processes accessing the target process. This application embodiment does not restrict the access information of the target process; the access information includes common fields of the third-party process, process information of the third-party process, and access permissions of the third-party process. The process access plugin is a plugin for querying the access information of the target process. A handle is used to uniquely identify a resource or object. A handle can point to system resources such as files, network connections, processes, threads, and memory segments. Through a handle, an application can access and manipulate specific resources without directly manipulating the memory address of the resource.

[0152] In some embodiments, the above-mentioned "obtaining the handle of the target process through the process access plugin" can be implemented in the following way: in response to the target process being accessed, the second callback function in the process access plugin is called to identify the accessing process of the target process, and the access identifier of at least one of the process information of the accessing process and the access permissions of the accessing process is determined as the handle of the target process.

[0153] It should be noted that access permissions refer to the restrictions on a user's or process's ability to access resources (such as files, directories, network services, etc.) in a computer system, network, or software application, used to protect resources from unauthorized access or modification. This application's embodiments do not restrict access permissions; access permissions can include access, reading, modification, etc.

[0154] For example, the handle of the target process is determined by at least one of the process information of the accessing process and the access identifier of the accessing process's access permissions (such as the access identifier corresponding to the process path of the accessing process being "10001", or the access identifier corresponding to the access permissions of the accessing process (such as read and write permissions) being "10231".

[0155] In step 1023D, when the target acquisition method is used to acquire process information that represents the memory information of the target process, the memory scanning plugin is invoked, the memory of the target process is queried through the memory scanning plugin, and the memory information of the queried memory is determined as the target process information.

[0156] Here, the memory information of the target process refers to the information stored in memory associated with the target process. This application embodiment does not limit the memory information of the target process; it can include a base address, region size, status, protection attributes, type, and content. The base address is the starting address of the memory block; the region size is the size of the region occupied by the memory block; the status is used to determine whether the memory block is free, reserved, or committed; the protection attributes are used to determine the access permissions of the memory block, such as whether it is readable, writable, or executable; the type is used to distinguish whether the memory block is private, mapped, or mirrored; and the content is the actual data in the memory block, such as application variable values ​​or application executable code. Each variable value has a unique memory address (i.e., the application variable address), which is the address of the storage location allocated to the variable in computer memory, used to access and manipulate the variable. Memory scanning plugins (such as the "VirtualQueryEx" plugin and the "ReadProcessMemory" plugin) are plugins used to scan memory.

[0157] Through the embodiments of this application, different information is collected during the startup and execution of the process by using different plugins, thereby achieving convenience and flexibility in data collection.

[0158] See also Figure 3 In step 103, the target verification method corresponding to the target process information is determined, and the target process information is verified for security according to the target verification method to obtain the first verification result.

[0159] It should be noted that different acquisition methods yield process information corresponding to different verification methods. When the target acquisition method is used to collect process information representing the modules loaded by the target process, the target verification method performs security verification on the target process information by calculating the similarity between the module information of a predefined module and the module information loaded by the target process. Here, the predefined module is a module that is pre-defined as not being able to be safely loaded. When the target acquisition method is used to collect process information representing the access information of the target process, the target verification method performs security verification on the target process information by calculating the similarity between the predefined access information and the access information of the target process. Here, the predefined access information is pre-defined abnormal access information. When the target acquisition method is used to collect process information representing the memory information of the target process, the target verification method performs security verification on the target process information by calculating the similarity between the predefined memory information and the memory information of the target process. Here, the predefined memory information is abnormal memory information stored in memory.

[0160] In some embodiments, see Figure 11 , Figure 11This is a schematic diagram of the seventh process of the bill processing method provided in the embodiments of this application, which is aimed at... Figure 3 The step 103 shown illustrates the security verification of the target process information according to the target verification method, resulting in a first verification result, which can be obtained through... Figure 11 Steps 1031 to 1032 are implemented, and will be explained in detail below.

[0161] In step 1031, abnormal verification information for the target process is obtained according to the target verification method.

[0162] Here, the exception verification information is used to verify the target process information, and different verification methods correspond to different exception verification information.

[0163] In some embodiments, see Figure 12 , Figure 12 This is a schematic diagram of the eighth process of the bill processing method provided in the embodiments of this application, which is aimed at... Figure 11 The step 1031 shown, which involves obtaining abnormal verification information for the target process, can be achieved through... Figure 12 Steps 10311 to 10313 are implemented, and will be explained in detail below.

[0164] Perform at least one of the processes from steps 10311 to 10313.

[0165] In step 10311, when the target process information is used to characterize the module information of the module loaded by the target process, the module information of the set module is determined as abnormal verification information. The set module is a module that is pre-set and cannot be safely loaded.

[0166] It should be noted that the embodiments of this application do not restrict the modules that cannot be safely loaded in advance. The modules that cannot be safely loaded in advance may be modules that have been injected with malicious information, or modules that are easy to be injected with malicious information, etc.

[0167] For example, the module information of the set module (such as module A that has been injected with malicious information) will be identified as abnormal verification information.

[0168] In step 10312, when the target process information is used to characterize the access information of the target process, the access information is set as abnormal verification information, and the access information is a pre-set abnormal access information.

[0169] Here, the embodiments of this application do not limit the pre-set abnormal access information. The pre-set abnormal access information may be abnormal access permissions (such as modification permissions) or abnormal access processes (such as access process A).

[0170] For example, setting access information (such as modifying permissions) will be identified as abnormal verification information.

[0171] In step 10313, when the target process information is used to characterize the memory information of the target process, the target memory information is determined from multiple set memory information, and the target memory information is determined as the abnormal verification information. The set memory information is the abnormal memory information stored in memory.

[0172] Here, abnormal memory information refers to unusual memory data, such as the size of a region where memory usage is high. The location of this memory information in memory varies depending on the specific settings.

[0173] In some embodiments, determining the target memory information from multiple set memory information in step 10313 can be achieved by: determining a first storage space for storing the set memory information for each set memory information; when a second storage space for storing the memory information of the target process matches the first storage space, the set memory information is determined as the target memory information.

[0174] Here, memory storage space refers to the area in computer memory used to store data. In this application embodiment, there is no limitation on the area for storing data, and the area can be random access memory, cache, etc.

[0175] It should be noted that different processes store their memory information in different storage spaces, and each storage space corresponds to its own set of memory information to check processes in different storage spaces. The set memory information in the same storage space is used to perform security verification of the process information of the target process in that storage space.

[0176] For example, a first storage space is determined for storing setting memory information (e.g., the first storage space for setting memory information A is space A, and the first storage space for setting memory information B is space B). When a second storage space (e.g., space B) for storing memory information of the target process matches the first storage space, the setting memory information (e.g., setting memory information B) is determined as the target memory information.

[0177] For example, target memory information (such as a region size of 20G) is identified as abnormal verification information.

[0178] In step 1032, when the similarity between the abnormal verification information and the target process information is less than the third similarity threshold, the verification is passed and determined as the first verification result.

[0179] For example, when the similarity (e.g., 0.3) between the abnormal verification information (such as the modification permission in the abnormal access information) and the target process information (such as the access permission in the abnormal access information) is less than the third similarity threshold (e.g., 0.85), the verification is passed and determined as the first verification result.

[0180] Through the embodiments of this application, malicious behavior can be effectively identified and prevented through precise security verification, thereby improving system security and allowing the system to flexibly add new verification methods and abnormal information to adapt to ever-changing security threats.

[0181] As an example, Figure 13 This is a schematic diagram of the security verification principle provided in an embodiment of this application. See also... Figure 13 Target acquisition method A collects process information representing the modules loaded by the target process. The module information is identified as the target process information corresponding to target acquisition method A, and the module information of the configured modules is identified as exception verification information. Target acquisition method B collects process information representing the access information of the target process. The access information corresponding to the handle of the target process is identified as the target process information corresponding to target acquisition method B, and the configured access information is identified as exception verification information. Target acquisition method C collects process information representing the memory information of the target process. The queried memory information is identified as the target process information, and the target memory information is identified as exception verification information. Security verification is performed based on the exception verification information and the target process information.

[0182] See also Figure 3 In step 104, when the first verification result indicates that the target process information has passed the security verification, a network access ticket is issued to the application.

[0183] In some embodiments, when the first verification result indicates that the target process information has not passed security verification, a network access ticket is refused to be issued to the application.

[0184] Following the above embodiment, after step 104, the following steps are performed: when a network access ticket exists, resources are granted to the application in response to the application's resource request.

[0185] In some embodiments, after step 104, the following steps are performed: the abnormal verification information is updated to obtain verification update information for the target process; when the similarity between the verification update information and the target process information is greater than or equal to a third similarity threshold, the network access ticket issued to the application is revoked.

[0186] Following the above embodiments, the above-mentioned "updating the abnormal verification information to obtain the verification update information for the target process" can be achieved in the following way: obtaining new abnormal verification information, and determining the new abnormal verification information and the abnormal verification information as the verification update information for the target process, wherein the collection time of the new abnormal verification information is greater than the issuance time of the network access ticket.

[0187] For example, when the similarity (e.g., 0.9) between any verification update information (such as the path " / proc / 10001 / exe" and the path " / proc / 10321 / 32141 / exe") and the target process information (such as the path " / proc / 10321 / 32142 / exe") is greater than or equal to the third similarity threshold (e.g., 0.85), the network access ticket issued to the application is revoked.

[0188] Following the above embodiment, after "reclaiming the network access ticket issued to the application", the following steps can be performed: reclaim the resources issued to the application; in response to the application requesting a network access ticket again within a preset time, do not perform the operation of obtaining the network access ticket.

[0189] In some embodiments, the above-mentioned "reclaiming network access tickets issued to applications" can be implemented by reclaiming network access tickets issued to applications during the validity period of the network access tickets.

[0190] It should be noted that the issued network access tickets have an expiration date. Within this period, the ticket is valid and can be used to access network resources. Once the network access ticket expires, it will automatically become invalid and can no longer be used to access network resources.

[0191] Following the above embodiment, after step 104, the following steps are performed: when an invalid network access ticket exists, in response to the application's resource request, resources are refused to be issued to the application.

[0192] It should be noted that when an application attempts to request resources using an expired network access ticket, the system can recognize that the ticket is expired and refuse to grant the resources.

[0193] In some embodiments, after step 104, the following steps are performed: periodically querying the memory of the target process through a memory scanning plugin, and determining the new memory information of the queried memory as timing information; when the timing information hits the verification information, reclaiming the network access ticket issued to the application.

[0194] It should be noted that the memory information in the target process's memory is dynamically updated. By periodically querying the target process's memory, the system can obtain the latest memory information, thus preventing abnormal information from being injected into the memory and ensuring system security. The verification information includes exception verification information used to verify the memory information in the target process's memory. When the new memory information obtained matches the set memory information, the network access ticket issued to the application is revoked.

[0195] Through the embodiments of this application, by controlling the issuance and retrieval of network access tickets, secure access to network resources can be managed more effectively, preventing malicious programs from abusing network resources. By continuously updating abnormal verification information and re-evaluating process information, dynamic security verification of target processes can be achieved. By retrieving network access tickets of processes with similar abnormal behavior, security risks can be reduced and potential attacks can be prevented.

[0196] The following will describe an exemplary application of the bill processing method provided in this application embodiment in a real-world application scenario.

[0197] In related technologies, network access tickets are applied for and used on a process-by-process basis. When an application process within a device initiates network access, the network access parameters are sent to the management client by the terminal's full-traffic proxy (intercepting network requests from various application processes within the device). The management client collects the process's characteristic information (i.e., general information) based on the process identifier. Based on this information, the management client applies for a network access ticket from the server. If the ticket application is successful, the application will continue to operate unless the ticket expires or the server identifies a security risk in the application (the server issues a handling command to the terminal to block the process's network access or prohibit its subsequent operation, etc.). If a process that has successfully applied for a network access ticket is injected with malicious code, the malicious code or module can run as that process and use the network access ticket to access other resources in the enterprise network, performing unauthorized resource access, data reading, modification, or deletion, causing significant security risks such as data leakage. The network access parameters include the source address or domain name, source port, destination address or domain name, destination port, and the corresponding process identifier (PID) that initiated the network access. The characteristic information includes the hash of the process's executable file, the full path, the last modification time of the executable file, copyright information, and signature information. The network access ticket can be used by all functional logic or modules within that process.

[0198] To address the aforementioned issues, this application proposes a ticket processing method that advances process security checks to the moment of process startup, covering the entire application process's runtime cycle and improving the accuracy of process risk detection. Simultaneously, through a plug-in-style security check mode, it continuously identifies information about processes actively (or passively) loading modules, high-privilege access to target process handles, and memory scans of the target process. This information is sent to the server for verification. This refines the existing method of applying for tickets based on processes to include the modules loaded by the process, memory characteristics, and high-privilege access to the target process by other processes. This finer granularity allows for more precise detection of process security risks. During the ticket's validity period, the management client continuously monitors the process's active or passive module loading actions based on security rules issued by the server. Third-party processes accessing the target process handle with corresponding high privileges are monitored, ensuring that normal business logic of the process accesses enterprise resources via network access tickets. This effectively blocks malicious behavior, prevents data leakage, achieves comprehensive process protection, and improves the accuracy of security verification.

[0199] For example, to apply for a network access ticket for accessing resources, see Figure 14 , Figure 14 This is a schematic diagram of user access to resources provided in an embodiment of this application. Figure 14 middle, Figure 14 It includes multiple modules for accessing resources in the embodiments of this application, such as system 401, server 402, and access control policy engine 403. The multiple modules for accessing resources provided in the embodiments of this application will be explained below.

[0200] 1) System 401

[0201] Here, in response to a user's request to access resources, the system constructs a process (401) and requests a network access ticket through the process.

[0202] 2) Server 402

[0203] Here, server 402 acts as the provider of zero-trust network security services. It provides a unified entry point for access subjects (i.e. users) to access the resources of objects through network requests via zero-trust proxy and access gateway. Server 402 provides authentication operations for the unified entry point. Only network requests that have passed authentication can be forwarded by zero-trust proxy to access gateway. Access gateway proxies access to the actual business system. The authentication operation is executed by access control policy engine 403.

[0204] 3) Access control policy engine 403

[0205] Here, any process created by a user in any environment is initially considered untrusted and is only converted to trusted access after being filtered by the access control engine 403. Server 402 collects process information related to the process as a unified policy enforcement point. The access control policy engine 403 in server 402 includes multiple unified policy decision points. These unified policy decision points are used to verify the unified policy enforcement points. Once the verification is successful, untrusted access is converted to trusted access, enabling the user to access the object's resources. These resources can be office resources, data resources, development and maintenance resources, the Internet, etc.

[0206] See Figure 15 , Figure 15 This is a flowchart of the bill processing provided in the embodiments of this application. The following is an explanation of the process for issuing bills provided in the embodiments of this application.

[0207] In step 501, the terminal's management client identifies the start and exit of any process within the device.

[0208] Here, security checks on processes are initiated at the moment of process startup, covering the entire runtime of the application process. Different interfaces are used to register callback functions on different systems (e.g., in Windows, the "PsSetCreateProcessNotifyRoutine" application programming interface (API) can be used to register callback functions in the kernel driver) to identify process creation and exit. Specifically, this API is used at the kernel layer (i.e., Ring 0) to register callback functions and identify the startup and exit of processes within the device. The kernel layer is the core of the operating system, responsible for managing system hardware resources, including the processor, memory, input / output devices, etc., and providing the basic environment for application execution. The kernel driver is a software component running in kernel mode within the operating system, responsible for managing the interaction between hardware devices and the operating system, providing a software interface that allows the operating system and applications to access and control hardware devices.

[0209] In step 502, process information is continuously collected, and security checks are performed on the process information.

[0210] Here, process information includes information about the process's actions of actively or passively loading modules, information about third-party processes accessing the target process handle with corresponding high privileges, and performing memory scans. Relevant process information is sent to the server for inspection in advance. Among these, memory scanning is scanning the contents of the process's memory.

[0211] When a new process starts, it is added to a process queue maintained by the kernel; when a process exits, it is removed from the queue accordingly. For processes in the queue, the kernel layer and the application layer communicate to query the process's characteristic information (i.e., general information), which includes the process path, executable file hash, digital signature, etc.

[0212] The management client constructs the entire runtime cycle of each application process within the device in this way. Within the process runtime cycle, this embodiment employs a plug-in-based security check mode (i.e., a verification method). This involves making the functions of actively (or passively) loading module information, identifying high-privilege access to target process handles, and memory scanning functions into plug-ins (e.g., encapsulating the functions of loading information from the collection module, identifying high-privilege access to target process handles, and memory scanning into independent plug-ins. Each plug-in has a unified interface for the client to call as needed). The server sets relevant rules according to the policy and sends these rules to the client. The client performs full or partial checks on different processes based on the rules sent by the server. The rules specify which type of plug-in or several types of plug-ins should be executed on certain running processes. For example, the server can send a rule (i.e., a full collection rule) requiring the client to perform a full check on a batch of processes that meet certain characteristics, while only performing partial checks on other processes. Correspondingly, after receiving the rules sent by the server, the client calls the corresponding plug-in to perform the appropriate identification on the target process.

[0213] Specifically, for each process within the device, it may execute only one plugin's function, two plugins, or all plugins, depending on the rules issued by the server. Let P be a set of processes, and p be one of them. Let A be a set of plugins (i.e., collection methods), including three plugins: a1 is a plugin for identifying modules actively or passively loaded by the collection process p; a2 is a plugin for identifying high-privilege access to the target process handle; and a3 is a plugin for scanning the memory of process p. Let R be a set of rules issued by the server, and r be one of them. A rule is a set of judgment conditions or constraints issued by the server to determine whether to execute one or more plugins in plugin set A for processes with specific characteristics. Rule r may contain process characteristic information such as path characteristics, digital signatures, product names, hash values, and the conditions that these characteristics need to satisfy.

[0214] The management client can quickly query all running processes and their characteristic information (i.e., general information) within the device, and determine the characteristic information of the processes (when the terminal's management client constructs the full runtime of each application process, for processes added to the cache queue, the kernel layer synchronizes the process PID to the user layer (i.e., ring3 layer), and the user layer automatically collects process characteristic information, including process path, executable file hash, digital signature, etc., and then returns it to the kernel layer). When the characteristic information meets the conditions in rule r, the client will execute the corresponding plugin function (i.e., target collection method) according to rule r.

[0215] When the management client detects a process startup, it compares the process's characteristic information with each rule in the rule set R issued by the server. Each process executes different plugin (or combinations of plugins) functions based on the different rules satisfied by its characteristic information. The management client can perform corresponding security checks on processes with different characteristics according to the server's policies and requirements. Specifically, for all p∈P, the set of plugins A′ to be executed is determined according to R(p). For all a∈A′, the management client checks process p by identifying plugin a. Specifically, if a1∈A′, a module loading information collection operation is performed on process p, recording the characteristic information of all modules loaded by process p, such as the module path, module hash value, and module signature. If a2∈A′, a high-privilege access target process handle identification operation is performed on process p, identifying high-privilege access operations of other processes accessing process p's handle. High privileges generally include build, read, and write permissions, and the specific values ​​of high-privilege access operations are specified by the rules or policies issued by the server. If a3∈A′, a memory scan check is performed on process p. Iterate through a specified memory region of process p and apply a set of predefined rules (including regular expressions, hash values, etc.) to each memory region to detect potential malicious behaviors such as code injection.

[0216] For each launched process, the management client uses plugin a1 to collect real-time information on its active or passive module loading actions. Once a new module is detected being loaded into the process, it collects the module's characteristic information, including the module's path, hash, and signature. On specific operating systems, this can be achieved through the "PsSetLoadImageNotifyRoutine" interface. Plugin a2 can identify and control access to system objects through callback functions, recognizing high-privilege access operations by other processes to the target process handle. Plugin a3 can utilize the VirtualQueryEx and ReadProcessMemory interfaces to perform memory scans of the target process. To ensure accuracy and efficiency while reducing performance overhead, it periodically scans the target process's memory based on server-side rules (using static process characteristics or runtime actions triggered by relevant rules) to look for suspicious signatures. This helps identify potential code injection, data patterns, or fileless memory-loading trojans. In addition to specifying the timing or triggering conditions for memory scanning, the server also specifies the relevant areas (i.e., storage space) for memory scanning. For example, it may only read committed or private areas with protection attributes of being read and written (Read-Write, RX), being read, written and executed (Read-Write-Execute, RWX), and being written and executed (Write-Execute, WX).

[0217] In step 503, duplicate checks on the process are avoided.

[0218] Here, for processes in a running state, regarding the collected module loading data (i.e., module information of the loaded modules), high-privilege handle access data (i.e., access information), and memory scan data (i.e., memory information), the following methods are used to improve efficiency while reducing unnecessary duplicate checks: The server sets a time window (i.e., time threshold) for repeated client-side checks, for example, 2 hours. Within the time window, only the same module is checked once; that is, if the same module has already been checked within the time window σ, it will not be checked again for the remaining time of the time window. Simultaneously, a cache record is maintained on the client side, recording the characteristic information of modules that have already been checked (a maximum timeout is set for cached items; expired items are automatically deleted from the cache record).

[0219] Before sending a request to the server for inspection, the client first checks if the module to be inspected is in the cache record. If it is in the cache record, i.e., a cache hit, then no further inspection is needed. Specifically, let M be the set of modules loaded by process p as identified by the management client, and m be one of these modules. Let T be the time window, and C be the cache record. Check(m) is the inspection function (0 indicates no inspection, 1 indicates inspection). For all m∈T, the following operations are performed: First, check if m is in C, i.e., check if the cache is hit. If the cache is hit, i.e., m∈C, then Check(m) returns 0. Next, check if m has already been inspected in T. If it has already been inspected, i.e., m∈T, then Check(m) returns 0. Finally, if m is neither a cache hit nor has it been inspected in T, then Check(m) returns 1, indicating that the client will send this record to the server for inspection, and simultaneously add m to both T and C. The management client can improve the efficiency of security checks and reduce computing and network communication overhead by collecting data through three plugins.

[0220] In step 504, a network access ticket is issued to the device.

[0221] Here, when the device's full-traffic proxy intercepts the traffic of the corresponding process accessing enterprise resources, the server issues network access tickets to the application process that does not pose a security risk. The device's full-traffic proxy is a full-traffic proxy implemented at the network device level, such as a proxy service configured on network devices like routers, switches, and firewalls, used to manage the entire network or subnet and manage all data traffic passing through the device.

[0222] During the validity period of the invoice, the monitoring client controls the actions of processes actively or passively loading modules based on the security rules issued by the server, as well as the operations of third-party processes accessing the target process handle with corresponding high privileges. By conducting real-time information exchange and security checks between the client and server, and continuously identifying and promptly handling module loading and external high-privilege access to processes during the invoice's validity period, and further by taking timely action against processes detected by memory scanning, the security of enterprise resource access can be significantly improved.

[0223] See Figure 16 , Figure 16 This is a flowchart of accessing enterprise resources provided in the embodiments of this application. The following is an explanation of the process of accessing enterprise resources provided in the embodiments of this application.

[0224] In step 601, the set of behaviors for the process is constructed.

[0225] Here, we define a time interval T, denoted as ([t0, t1]), where t0 is the identification start time (process startup time), t1 is the time when the process needs to apply for a network access ticket to access enterprise resources, and the set of behaviors A of process e within the time interval T is denoted as (A = {a1, a2, ... a1}). n `}` represents the set of behaviors performed by a process within a time interval `T`. This set of behaviors may include information about actively (or passively) loading modules, operations that identify high-privilege access to the target process handle, and the results of memory scans. The set of behaviors of process `e` in different time intervals is affected by its own execution logic and the security check rules issued by the server. The result of verifying whether a network access ticket can be issued changes based on the set of behaviors.

[0226] In step 602, network access tickets are issued to normal processes based on the set of processes' behaviors.

[0227] Here, the server constructs a set of malicious behavior rules M based on the anomaly intelligence database, denoted as M = {m1, m2, ... m}. n The malicious behavior rule set is composed of malicious behavior rules. A single malicious behavior rule indicates whether any behavior 'a' in behavior set A matches the malicious behavior rule set M. The server uses a single malicious behavior rule to decide whether to issue a ticket to a process accessing enterprise resources. That is, if any behavior matches the malicious behavior rule set M within the time interval T, the server refuses to issue a network access ticket; otherwise, the server issues a network access ticket normally.

[0228] In step 603, the risks associated with using network access tickets are addressed.

[0229] Here, this application embodiment provides two risk points regarding the use of network access tickets, namely risk point 1 and risk point 2.

[0230] Regarding risk point 1, the server issued a network access ticket to process e. At that time, the set of actions triggered by process e was A = {a1, a2, ... a...}. n The server-side detection showed no violation of malicious behavior rules, therefore the process posed no security risk and was allowed to access the target site. However, considering that malicious behavior rules are dynamically changing, behaviors that were previously detected as risk-free may later be found to pose a high risk.

[0231] Regarding risk point 2, after process e receives a network access ticket, it can be used multiple times within its validity period. When a third-party process uses high privileges to access the handle of this process and then injects malicious code or modules, it can use this process and the readily available ticket to access enterprise resources, causing data leakage.

[0232] Regarding risk point 1, during the use of the ticket, the set of behaviors A associated with process e issuing the ticket is continuously compared with the set of malicious behavior rules M on the server side. (Of course, the set of behaviors A of process e within the interval [t0, t1] is a given fact and remains unchanged, but the set of malicious behavior rules M is dynamically changing. If M does not change during the ticket usage period, this step is unnecessary.) Specifically, within the time interval T (denoted as [t0, t1]), process e generates a set of behaviors A, where {a1, a2, ... a...} n} represents the set of actions performed by a process within a time interval T. The malicious behavior detection rule on the server side is Mpost, where Mpost = {m1, m2, ..., m}. k} represents the set of malicious behavior rules specified by the server. This set of rules is dynamically changing. Mpre represents the historical set of rules during ticket processing, and Mpost represents the current set of rules. During the use of the ticket, each behavior a in the behavior set A of process e will be continuously compared with the malicious behavior rule set Mpost. If a match is found, the ticket will be immediately invalidated, and the process will be prevented from applying for additional network tickets, thus cutting off the possibility of accessing enterprise resources.

[0233] Regarding risk point 2, for processes that receive network access tickets, if a memory scan detects malicious code characteristics during the process of accessing enterprise resources using the ticket (the process's memory scanning behavior is identified in real time during ticket usage, and relevant actions are taken if problems are found), the client immediately takes appropriate action, including terminating the process's network access, stopping the process and all its child processes, and preventing it from starting again. Furthermore, callbacks are registered at the kernel driver layer to identify all processes' high-privilege access to the target process and module loading behavior. For module loading and high-privilege access behavior, the server updates malicious behavior rules in real time, and the client synchronizes these rules in real time. Processes that meet certain characteristics (e.g., modules matching certain characteristics are allowed to be loaded by the process, processes matching certain characteristics are allowed to access the target process's handle with high privileges, etc.) are allowed to operate through network access tickets, while other processes requesting network access tickets are blocked. Identification and control at the kernel level provide higher security and real-time performance. Specific operations are as follows.

[0234] Define a time interval [t2, t3], where t2 is the time when process e receives the network access ticket, and t3 is the time when the ticket automatically expires. Within the time interval [t2, t3], identify the process's behavior in real time and record the behavior set A. A = {a1, a2, ... a3} n} represents the set of actions triggered by a process using a network ticket within the time interval [t2, t3]. M = {m1, m2, ... m} n} represents the set of malicious behavior rules specified by the server. The set of rules is dynamically changing. P = {p1, p2, ..., p...} n} represents the access behavior of other high-privilege processes to the target process within the time interval [t2, t3], where Q{q1, q2, ... q n} represents the behavior of process e in actively or passively loading modules. The server specifies W = {w1, w2, ... w...} n The whitelist `W` represents the set of allowed module loading information and access information that allows certain processes (e.g., those with valid digital signatures) to access the target process handle with high privileges. `D(p, W)` is a Boolean function used to determine whether an attempt by a process to access the target process with high privileges should be blocked. If `p` is not in the whitelist `W`, then `D(p, W) = True`, indicating that the attempt to access the target process with high privileges should not be blocked; otherwise, `D(p, W) = False`, indicating that the attempt to access the target process with high privileges should be blocked. Similarly, `F(q, W)` is also a Boolean function used to determine whether the target process actively or passively loads modules should be blocked.

[0235] The client identifies process module loading and high-privilege access behaviors by registering callback functions in the kernel driver. During process ticket usage, it checks in real-time whether module loading and high-privilege access behaviors conform to whitelist rules based on D(p, W) and F(q, W). If the process and module are whitelisted, operation is allowed; otherwise, it is blocked. Furthermore, if a memory scan reveals malicious logic characteristics in a process, actions are taken including terminating the process's network access, stopping the process and all its child processes, and preventing its next startup.

[0236] In response to the active or passive module loading behavior of processes and other processes' high-privilege access to target processes during the use of tickets, in addition to real-time identification, timely handling is also performed. In this way, malicious behavior can be effectively blocked, data leakage can be prevented, and comprehensive protection of processes can be achieved. It can also prevent malicious code and module injection, ensuring that after a network access ticket is issued to a specified process, it is used by the normal business logic of that process to use the network access ticket, rather than by other malicious code and modules residing in the process's address space and using the existing ticket to access enterprise data. This can improve the security of enterprise resource access to a certain extent.

[0237] In summary, the method provided in this application embodiment can improve the security of enterprise resource access to a certain extent. First, the terminal's management client identifies the startup and exit of any process within the device, detecting security throughout the process's entire lifecycle. Through a plug-in-style security check mode, it continuously identifies information such as processes actively (or passively) loading modules, high-privilege access to target process handles, and information obtained from memory scans of the target process, sending this information to the server for inspection. When the device's full-traffic proxy intercepts traffic from a corresponding process accessing enterprise resources, the server issues network access tickets to application processes that are found to pose no security risk. During the ticket's validity period, the management client continuously manages the process's active or passive module loading actions based on the security rules issued by the server. Operations by third-party processes accessing the target process handle with corresponding high privileges are also monitored. During the ticket's usage period, timely handling is also performed on the client to ensure that after a network access ticket is issued to a designated process, it is the process's normal business logic that uses the network access ticket to access enterprise resources, effectively blocking malicious behavior and preventing data leakage.

[0238] The following description continues to illustrate the exemplary structure of the document processing device 555 provided in the embodiments of this application as a software module. In some embodiments, such as... Figure 2 As shown, the software modules stored in the ticket processing device 555 in the memory 550 may include:

[0239] The data acquisition module 5551 is used to respond to the network access ticket application's request for network access ticket, obtain the target process for requesting network access ticket; determine the target acquisition method from multiple acquisition methods of the target process, and acquire the target process information of the target process according to the target acquisition method, wherein different acquisition methods are used to acquire different process information of the target process;

[0240] The security verification module 5552 is used to determine the target verification method corresponding to the target process information, and to perform security verification on the target process information according to the target verification method to obtain the first verification result;

[0241] The ticket issuance module 5553 is used to issue a network access ticket to the application when the first verification result indicates that the target process information has passed the security verification.

[0242] In some embodiments, the data acquisition module 5551 is further configured to acquire a general field of the target process, wherein the general field is a field that does not need to be acquired by multiple acquisition methods of the target process; acquire a full acquisition rule, wherein the full acquisition rule is used to instruct the target process to be acquired by each acquisition method of the target process, and the full acquisition rule includes at least one set rule field; when the similarity between the general field and any rule field is greater than or equal to a first similarity threshold, each acquisition method of the target process is determined as the target acquisition method.

[0243] In some embodiments, the data acquisition module 5551 is further configured to acquire a general field of the target process, and determine the process type of the target process based on the general field, wherein the general field is a field that does not need to be acquired by multiple acquisition methods for the target process; and determine the target acquisition method from multiple acquisition methods of the target process based on the process type.

[0244] In some embodiments, the data acquisition module 5551 is further configured to query the acquisition method configuration table based on the process type, wherein the acquisition method configuration table includes the correspondence between different candidate process types and different acquisition methods; when a candidate process type corresponding to the process type is found in the acquisition method configuration table, the acquisition method corresponding to the queried candidate process type is determined as the target acquisition method.

[0245] In some embodiments, the data acquisition module 5551 is further configured to query a quantity configuration table based on process type, wherein the quantity configuration table includes the correspondence between different candidate process types and different quantities; when a candidate process type corresponding to a process type is found in the quantity configuration table, the quantity corresponding to the queried candidate process type is determined as the target quantity; and from multiple acquisition methods of the target process, an acquisition method that meets the target quantity is selected as the target acquisition method.

[0246] In some embodiments, the data acquisition module 5551 is further configured to query a mapping table based on the abnormal execution field when the process execution field includes an abnormal execution field, wherein the abnormal execution field includes at least one of the following: an abnormal file path field, an abnormal file tag field, and an abnormal file hash field. The abnormal file path field is used to indicate the location where the abnormal file is stored, the abnormal file tag field is used to identify the abnormal file, the abnormal file hash field is used to characterize the hash value of the abnormal executable file of the target process, the mapping table is used to characterize the correspondence between different candidate abnormal execution fields and different candidate process types, and the general field includes a process execution field, which is used to indicate the execution target process. When a candidate abnormal execution field corresponding to the abnormal execution field is found in the mapping table, the candidate process type corresponding to the found candidate abnormal execution field is determined as the process type.

[0247] In some embodiments, the data acquisition module 5551 is further configured to acquire the execution resource quantity and available resource quantity of each acquisition method; sort multiple acquisition methods based on the execution resource quantity to obtain a sorting result; and determine a portion of the acquisition methods in the sorting result as target acquisition methods, wherein the sum of the execution resource quantities of the portion of acquisition methods is less than or equal to the available resource quantity.

[0248] In some embodiments, the data acquisition module 5551 is further configured to perform at least one of the following processes: when the target acquisition method is used to acquire process information representing the module loaded by the target process, the module loading plugin is invoked to obtain the module loaded by the target process through the module loading plugin, and the module information of the module is determined as the target process information; when the target acquisition method is used to acquire process information representing the access information of the target process, the process access plugin is invoked to obtain the handle for accessing the target process through the process access plugin, and the access information corresponding to the handle is determined as the target process information; when the target acquisition method is used to acquire process information representing the memory information of the target process, the memory scanning plugin is invoked to query the memory of the target process through the memory scanning plugin, and the memory information of the queried memory is determined as the target process information.

[0249] In some embodiments, the data acquisition module 5551 is further configured to determine a first time point when the loading request of the receiving module is received, and a second time point when the module is historically loaded, wherein the second time point is less than the first time point; when the difference between the first time point and the second time point is greater than a time threshold, the module information of the module is determined as the target process information.

[0250] In some embodiments, the security verification module 5552 is further configured to obtain abnormal verification information for the target process according to the target verification method; when the similarity between the abnormal verification information and the target process information is less than a third similarity threshold, the verification pass is determined as the first verification result.

[0251] In some embodiments, the security verification module 5552 is further configured to perform at least one of the following processes: when the target process information is used to characterize the module information of a module loaded by the target process, the module information of the set module is determined as abnormal verification information, and the set module is a module that is pre-set to be unable to be safely loaded; when the target process information is used to characterize the access information of the target process, the set access information is determined as abnormal verification information, and the set access information is pre-set abnormal access information; when the target process information is used to characterize the memory information of the target process, the target memory information is determined from multiple set memory information, and the target memory information is determined as abnormal verification information, and the set memory information is abnormal memory information stored in memory.

[0252] In some embodiments, the security verification module 5552 is further configured to determine a first storage space for storing the setting memory information for each setting memory information; when the second storage space for storing the memory information of the target process matches the first storage space, the setting memory information is determined as the target memory information.

[0253] In some embodiments, the ticket retrieval module 5554 is used to update the abnormal verification information to obtain verification update information for the target process; when the similarity between the verification update information and the target process information is greater than or equal to a third similarity threshold, the network access ticket issued to the application is reclaimed.

[0254] This application provides a computer program product, which includes computer-executable instructions stored in a computer-readable storage medium. The processor of an electronic device reads the computer-executable instructions from the computer-readable storage medium and executes the computer-executable instructions, causing the electronic device to perform the ticket processing method described above in this application.

[0255] This application provides a computer-readable storage medium storing computer-executable instructions or a computer program. When the computer-executable instructions or the computer program are executed by a processor, the processor will execute the ticket processing method provided in this application. For example, ... Figure 3 The document illustrates the method for processing invoices.

[0256] In some embodiments, the computer-readable storage medium may be a memory such as RAM, ROM, flash memory, magnetic surface memory, optical disk, or CD-ROM; or it may be a variety of devices including one or any combination of the above-mentioned memories.

[0257] In some embodiments, computer-executable instructions may take the form of programs, software, software modules, scripts, or code, written in any form of programming language (including compiled or interpreted languages, or declarative or procedural languages), and may be deployed in any form, including as stand-alone programs or as modules, components, subroutines, or other units suitable for use in a computing environment.

[0258] As an example, computer-executable instructions may, but do not necessarily, correspond to files in a file system. They may be stored as part of a file that holds other programs or data, for example, in one or more scripts in a Hyper Text Markup Language (HTML) document, in a single file dedicated to the program in question, or in multiple co-located files (e.g., files that store one or more modules, subroutines, or code sections).

[0259] As an example, computer-executable instructions can be deployed to execute on a single electronic device, or on multiple electronic devices located at one location, or on multiple electronic devices distributed across multiple locations and interconnected via a communication network.

[0260] In summary, from multiple acquisition methods for the target process, a target acquisition method is determined, and target process information of the target process is acquired based on this method. The corresponding target verification method is then determined, and the target process information is subjected to security verification according to this method to obtain a first verification result. When the first verification result indicates that the target process information has passed security verification, a network access ticket is issued to the application. Thus, by selecting different acquisition methods or combinations of acquisition methods, different process information of the target process is acquired, and different verification methods are used for security verification based on different process information. This prevents malicious behavior from being injected into the target process through various means, improving the security of ticket processing. Furthermore, the flexible selection of multiple acquisition methods for the target process, the security verification based on different acquired process information, and the issuance of network access tickets under different conditions enhance the flexibility of ticket processing.

[0261] The above description is merely an embodiment of this application and is not intended to limit the scope of protection of this application. Any modifications, equivalent substitutions, and improvements made within the spirit and scope of this application are included within the scope of protection of this application.

Claims

1. A method for processing invoices, characterized in that, The method includes: In response to a request for a network access ticket issued by an application, obtain the target process for requesting the network access ticket; From multiple acquisition methods of the target process, a target acquisition method is determined, and target process information of the target process is acquired according to the target acquisition method, wherein different acquisition methods are used to acquire different process information of the target process; Determine the target verification method corresponding to the target process information, and perform security verification on the target process information according to the target verification method to obtain a first verification result; When the first verification result indicates that the target process information has passed the security verification, the network access ticket is issued to the application.

2. The method according to claim 1, characterized in that, The step of determining the target acquisition method from multiple acquisition methods of the target process includes: Obtain the common fields of the target process, wherein the common fields are those fields that do not need to be collected from the target process through the multiple collection methods; Obtain full data collection rules, wherein the full data collection rules are used to instruct the target process to be collected through each collection method of the target process, and the full data collection rules include at least one set rule field; When the similarity between the general field and any of the rule fields is greater than or equal to the first similarity threshold, each acquisition method of the target process is determined as the target acquisition method.

3. The method according to claim 1, characterized in that, The step of determining the target acquisition method from multiple acquisition methods of the target process includes: Obtain the common fields of the target process, and determine the process type of the target process based on the common fields, wherein the common fields are fields that do not need to be collected from the target process through the multiple collection methods; Based on the process type, the target acquisition method is determined from multiple acquisition methods of the target process.

4. The method according to claim 3, characterized in that, The step of determining the target acquisition method from multiple acquisition methods of the target process based on the process type includes: Based on the process type, query the collection method configuration table, wherein the collection method configuration table includes the correspondence between different candidate process types and different collection methods; When a candidate process type corresponding to the process type is found in the collection method configuration table, the collection method corresponding to the found candidate process type is determined as the target collection method.

5. The method according to claim 3, characterized in that, The step of determining the target acquisition method from multiple acquisition methods of the target process based on the process type includes: The quantity configuration table is queried based on the process type, wherein the quantity configuration table includes the correspondence between different candidate process types and different quantities; When a candidate process type corresponding to the process type is found in the quantity configuration table, the quantity corresponding to the found candidate process type is determined as the target quantity. From the multiple acquisition methods of the target process, the acquisition method that meets the target number is selected as the target acquisition method.

6. The method according to claim 3, characterized in that, The general fields include a process execution field, which is used to indicate the execution of the target process; The step of determining the process type corresponding to the target process based on the general field includes: When the process execution field includes an abnormal execution field, a mapping table is queried based on the abnormal execution field. The abnormal execution field includes at least one of the following: an abnormal file path field, an abnormal file tag field, and an abnormal file hash field. The abnormal file path field is used to indicate the location where the abnormal file is stored. The abnormal file tag field is used to identify the abnormal file. The abnormal file hash field is used to characterize the hash value of the abnormal executable file of the target process. The mapping table is used to characterize the correspondence between different candidate abnormal execution fields and different candidate process types. When a candidate abnormal execution field corresponding to the abnormal execution field is found in the mapping table, the candidate process type corresponding to the queried candidate abnormal execution field is determined as the process type.

7. The method according to claim 1, characterized in that, The step of determining the target acquisition method from multiple acquisition methods of the target process includes: Obtain the execution resource amount and available resource amount for each of the aforementioned acquisition methods; The multiple collection methods are sorted based on the amount of execution resources to obtain a sorting result; The target acquisition method is determined from a subset of the sorting results, wherein the sum of the execution resource amounts of the subset of acquisition methods is less than or equal to the available resource amount.

8. The method according to any one of claims 1 to 7, characterized in that, The step of collecting target process information of the target process according to the target acquisition method includes: Perform at least one of the following processes: When the target acquisition method is used to acquire process information representing the module loaded by the target process, the module loading plugin is invoked, the module loaded by the target process is obtained through the module loading plugin, and the module information of the module is determined as the target process information; When the target acquisition method is used to acquire process information that represents the access information of the target process, the process access plugin is invoked, the handle for accessing the target process is obtained through the process access plugin, and the access information corresponding to the handle is determined as the target process information; When the target acquisition method is used to acquire process information that represents the memory information of the target process, a memory scanning plugin is invoked to query the memory of the target process and the memory information obtained from the query is determined as the target process information.

9. The method according to claim 8, characterized in that, Before determining the module information of the module as the target process information, the method further includes: Determine a first time point when the loading request for the module is received, and a second time point when the module is historically loaded, wherein the second time point is less than the first time point; When the difference between the first time point and the second time point is greater than a time threshold, the operation of determining the module information of the module as the target process information is performed.

10. The method according to any one of claims 1 to 7, characterized in that, The step of performing security verification on the target process information according to the target verification method to obtain a first verification result includes: Based on the target verification method, obtain abnormal verification information for the target process; When the similarity between the abnormal verification information and the target process information is less than the third similarity threshold, the verification is passed and determined as the first verification result.

11. The method according to claim 10, characterized in that, The step of obtaining the abnormal verification information for the target process information includes: Perform at least one of the following processes: When the target process information is used to characterize the module information of the module loaded by the target process, the module information of the set module is determined as the abnormal verification information, and the set module is a module that is pre-set and cannot be safely loaded. When the target process information is used to characterize access information to the target process, the set access information is determined as the abnormal verification information, and the set access information is a pre-set abnormal access information. When the target process information is used to characterize the memory information of the target process, the target memory information is determined from multiple set memory information, and the target memory information is determined as the abnormal verification information, wherein the set memory information is abnormal memory information stored in memory.

12. The method according to claim 11, characterized in that, Determining the target memory information from multiple sets of memory information includes: For each of the defined memory information, a first storage space is determined for storing the defined memory information; When the second storage space used to store the memory information of the target process matches the first storage space, the set memory information is determined as the target memory information.

13. The method according to claim 10, characterized in that, After issuing the network access ticket to the application, the method further includes: The abnormal verification information is updated to obtain verification update information for the target process; When the similarity between the verification update information and the target process information is greater than or equal to the third similarity threshold, the network access ticket issued to the application is revoked.

14. A ticket processing device, characterized in that, The device includes: The data acquisition module is used to respond to a network access ticket application request issued by the application, obtain the target process for applying for the network access ticket; determine the target acquisition method from multiple acquisition methods of the target process, and acquire the target process information of the target process according to the target acquisition method, wherein different acquisition methods are used to acquire different process information of the target process; The security verification module is used to determine the target verification method corresponding to the target process information, and to perform security verification on the target process information according to the target verification method to obtain a first verification result; The ticket processing module is used to issue the network access ticket to the application when the first verification result indicates that the target process information has passed the security verification.

15. An electronic device, characterized in that, The electronic device includes: Memory is used to store executable instructions for a computer; A processor, when executing computer-executable instructions or computer programs stored in the memory, implements the ticket processing method according to any one of claims 1 to 13.

16. A computer-readable storage medium storing computer-executable instructions or a computer program, characterized in that, When the computer-executable instructions or computer program are executed by a processor, the ticket processing method according to any one of claims 1 to 13 is implemented.

17. A computer program product comprising computer-executable instructions or a computer program, characterized in that, When the computer-executable instructions or computer program are executed by a processor, the ticket processing method according to any one of claims 1 to 13 is implemented.

Images