CN112464225A

CN112464225A - Request processing method, request processing device and computer readable storage medium

Info

Publication number: CN112464225A
Application number: CN202011200014.XA
Authority: CN
Inventors: 张登超
Original assignee: Digital Finance Ltd
Current assignee: Digital Finance Ltd
Priority date: 2020-10-30
Filing date: 2020-10-30
Publication date: 2021-03-09

Abstract

An embodiment of the application provides a request processing method, a request processing device and a computer-readable storage medium, wherein the request processing method includes: when a target access request for an application program is received, determining a preset request processing path corresponding to the target access request in a data table, wherein the data table comprises a preset request processing path corresponding to each access request in at least one access request of the application program; acquiring an actual request processing path of a target access request according to a safety protection mechanism, wherein the safety protection mechanism is pre-injected into a source code of an application program; verifying the target access request according to the actual request processing path and a preset request processing path corresponding to the target access request to obtain a verification result; and determining a response strategy to the target access request according to the verification result. By adopting the embodiment of the application, the accuracy of the request verification result and the request verification efficiency can be improved, so that the protection accuracy and the protection efficiency of the application program are improved.

Description

Request processing method, request processing device and computer readable storage medium

Technical Field

The present application relates to the field of computer technologies, and in particular, to a request processing method, a request processing apparatus, and a computer-readable storage medium.

Background

With the rapid development of the internet technology, web application programs are produced, and because the web application programs have the characteristics of simple deployment, good interactivity, cross-platform operation support and the like, the web application programs are applied more and more widely, but meanwhile, the web application programs are also threatened more and more safely.

Currently, a Web Application is generally protected by a hardware protection device, a software protection system, and the like, for example, the Web Application uses a WAF (Web Application Firewall) to perform matching filtering on a legal request or an illegal request received by the Web Application. In the safety protection process, the safety protection mechanisms such as hardware protection equipment and a software protection system are easy to have wrong interception, so that legal requests are intercepted; in addition, the hardware protection equipment, the software protection system and the like can realize interception and protection of novel security vulnerabilities only by updating the rule base, and the security vulnerabilities which are not contained in the rule base cannot be intercepted and protected; therefore, safety protection mechanisms such as hardware devices and software systems are insufficient in protection efficiency, protection accuracy and the like.

Disclosure of Invention

The embodiment of the application provides a request processing method, a request processing device and a computer readable storage medium, which can improve the accuracy of a request verification result and the request verification efficiency, thereby improving the protection accuracy and the protection efficiency of an application program.

In a first aspect, an embodiment of the present application provides a request processing method, where the request processing method includes:

when a target access request for an application program is received, determining a preset request processing path corresponding to the target access request in a data table, wherein the data table comprises a preset request processing path corresponding to each access request in at least one access request of the application program;

acquiring an actual request processing path of a target access request according to a safety protection mechanism, wherein the safety protection mechanism is pre-injected into a source code of an application program;

verifying the target access request according to the actual request processing path and a preset request processing path corresponding to the target access request to obtain a verification result;

and determining a response strategy to the target access request according to the verification result.

In a second aspect, an embodiment of the present application provides a request processing apparatus, including:

the device comprises a determining unit, a processing unit and a processing unit, wherein the determining unit is used for determining a preset request processing path corresponding to a target access request in a data table when the target access request to an application program is received, and the data table comprises the preset request processing path corresponding to each access request in at least one access request of the application program;

the device comprises an acquisition unit, a processing unit and a processing unit, wherein the acquisition unit is used for acquiring an actual request processing path of a target access request according to a safety protection mechanism, and the safety protection mechanism is pre-injected into a source code of an application program;

the verification unit is used for verifying the target access request according to the actual request processing path and a preset request processing path corresponding to the target access request to obtain a verification result;

and the determining unit is also used for determining a response strategy to the target access request according to the verification result.

In a third aspect, an embodiment of the present application provides a request processing device, including:

a processor adapted to implement a computer program; and the number of the first and second groups,

a memory storing a computer program adapted to be loaded by the processor and to perform the above-mentioned request processing method.

In a fourth aspect, an embodiment of the present application provides a computer-readable storage medium, where a computer program is stored, and when the computer program is read and executed by a processor of a computer device, the computer program causes the computer device to execute the request processing method described above.

In the embodiment of the application, when a target access request to an application program is received, a preset request processing path corresponding to the target access request can be determined in a data table, an actual request processing path to the target access request can be monitored according to a safety protection mechanism injected into a source code of the application program in advance, the target access request is verified through the actual request processing path and the preset request processing path corresponding to the target access request, the accuracy of a request verification result can be effectively improved, and therefore the protection accuracy to the application program is effectively improved; in addition, the data table stores a preset request processing path corresponding to each access request in at least one access request of the application program, when a target access request to the application program is received, the preset request processing path corresponding to the target access request can be quickly determined in the data table, the request verification efficiency is improved to a certain extent, and therefore the protection efficiency of the application program is improved.

Drawings

In order to more clearly illustrate the embodiments of the present application or the technical solutions in the prior art, the drawings needed to be used in the description of the embodiments are briefly introduced below, and it is obvious that the drawings in the following description are some embodiments of the present application, and it is obvious for those skilled in the art to obtain other drawings based on these drawings without creative efforts.

FIG. 1 is a block diagram of a request processing system according to an embodiment of the present disclosure;

fig. 2 is a schematic flowchart of a request processing method provided in an embodiment of the present application;

FIG. 3 is a flow chart illustrating another request processing method according to an embodiment of the present disclosure;

FIG. 4 is a diagram illustrating injection results of a safety protection mechanism according to an embodiment of the present disclosure;

fig. 5 is a schematic diagram illustrating a correspondence relationship between a target access request and a data processing path according to an embodiment of the present application;

fig. 6 is a schematic structural diagram of a request processing apparatus according to an embodiment of the present application;

fig. 7 is a schematic structural diagram of a request processing device according to an embodiment of the present application.

Detailed description of the invention

The technical solutions in the embodiments of the present application will be clearly and completely described below with reference to the drawings in the embodiments of the present application, and it is obvious that the described embodiments are only a part of the embodiments of the present application, and not all of the embodiments. All other embodiments, which can be derived by a person skilled in the art from the embodiments given herein without making any creative effort, shall fall within the protection scope of the present application.

Referring to fig. 1, fig. 1 is a schematic structural diagram of a request processing system according to an embodiment of the present application, where the request processing system 10 includes a terminal 101 and a server 102. The terminal 101 may be a mobile terminal, a Personal Computer (PC) terminal, a laptop Computer (Tablet PC) terminal, or the like, which is not limited in the embodiments of the present application. The server 102 may be an independent physical server, a server cluster or a distributed system formed by a plurality of physical servers, or a cloud server providing cloud computing services, and the embodiments of the present application are not limited herein. The terminal 101 and the server 102 may be directly or indirectly connected through wired communication or wireless communication, and the application is not limited herein.

In the request processing system 10 composed of the terminal 101 and the server 102, when a target access request of the terminal 101 to an application program is received, the server 102 may determine a preset request processing path corresponding to the target access request in a data table, and obtain an actual request processing path for the target access request according to a security protection mechanism injected into a source code of the application program in advance, and the server 102 may verify the target access request according to the actual request processing path and the preset request processing path corresponding to the target access request to obtain a verification result, and determine a response policy for the target access request according to the verification result.

The application mentioned in the embodiment of the present application may be a World Wide Web (World Wide Web) application, the Web application is an application that can be accessed through a Web, and the greatest benefit of the Web application is that a user using the Web application can easily access the application, and only a browser needs to be installed in the terminal 101 used by the user, and no other software needs to be installed.

The data table may include a preset request processing path corresponding to each access request in at least one access request of the application program. The at least one access request may refer to all types of access requests that may be received by the application, and the at least one access request may also refer to a partial type of access requests that may be received by the application, for example, the at least one access request may include a user login request, a user query request, a user update request, and the like.

Each preset request processing path comprises a request processing method located at the starting point of the path, at least one data processing method located between the starting point of the path and the end point of the path, a return data method located at the end point of the path, and a calling sequence between the at least one data processing method. The actual request processing path may include a first actual request processing method located at a start point of the path, at least one first actual data processing method located between the start point of the path and an end point of the path, a first actual return data method located at the end point of the path, and a calling order between the at least one first actual data processing method.

In an implementation manner, the target access request does not carry data to be verified, and the server 102 may verify the target access request by determining whether the actual request processing path is the same as a preset request processing path corresponding to the target access request. When the actual request processing path is the same as the preset request processing path corresponding to the target access request, the server 102 generates a verification result that the verification of the target access request is successful. When the actual request processing path is different from the preset request processing path corresponding to the target access request, the server 102 generates a verification result that the verification of the target access request fails. When the verification result is that the verification of the target access request is successful, responding to the target access request; and when the verification result is that the verification of the target access request fails, refusing to respond to the target access request, and outputting an alarm page to the terminal 101, wherein the alarm page is used for prompting that the target access request is blocked.

For example, the target access request is a user query request, the user query request does not carry data to be verified, and the server 102 verifies the user query request by determining whether the actual request processing path is the same as a preset request processing path corresponding to the user query request. When the user query request is successfully verified, the user query request is responded, and the data requested by the user query request is returned to the terminal 101. And when the user query request is failed to be checked, refusing to respond to the user query request, and outputting an alarm page to the terminal 101, wherein the alarm page is used for prompting that the user query request is blocked.

In another implementation, the target access request carries data to be verified (i.e., first data hereinafter), and the server 102 may verify the target access request by determining whether an actual request processing path is the same as a preset request processing path corresponding to the target access request, and whether second data returned by the first actual data returning method is the same as the first data. And when the preset request processing path corresponding to the target access request is the same as the actual request processing path and the second data is the same as the first data, generating a verification result of successful verification of the target access request. When the preset request processing path corresponding to the target access request is different from the actual request processing path; or when the second data is different from the first data; or when the preset request processing path corresponding to the target access request is different from the actual request processing path and the second data is different from the first data, generating a verification result of the target access request which fails to be verified. When the verification result is that the verification of the target access request is successful, responding to the target access request; and when the verification result is that the verification of the target access request fails, refusing to respond to the target access request, and outputting an alarm page to the terminal 101, wherein the alarm page is used for prompting that the target access request is blocked.

For example, the target access request is a user login request, and the user login request carries data to be verified, such as login information of the user (e.g., a user account, a password, etc.); the server 102 verifies the user query request by judging whether the actual request processing path is the same as a preset request processing path corresponding to the user login request, and judging user information carried in the user login request and user information returned by the first actual data returning method. When the user login request is successfully verified, the terminal 101 is allowed to log in the application program in response to the user login request. And when the user login request is failed to be checked, refusing to respond to the user login request, and outputting an alarm page to the terminal 101, wherein the alarm page is used for prompting the user that the query request is blocked.

It is to be understood that the request processing system described in the embodiment of the present application is for more clearly illustrating the technical solution of the embodiment of the present application, and does not constitute a limitation to the technical solution provided in the embodiment of the present application, and as a person having ordinary skill in the art knows that along with the evolution of the system architecture and the appearance of a new service scenario, the technical solution provided in the embodiment of the present application is also applicable to similar technical problems.

In the embodiment of the application, when a target access request of the terminal 101 to the application is received, the server 102 may determine a preset request processing path corresponding to the target access request in the data table, and may also monitor an actual request processing path to the target access request according to a security protection mechanism injected into a source code of the application in advance, and the server 102 verifies the target access request through the actual request processing path and the preset request processing path corresponding to the target access request, so that the accuracy of a request verification result can be effectively improved, and thus the protection accuracy of the application is effectively improved; in addition, the data table stores a preset request processing path corresponding to each access request in at least one access request of the application program, and when a target access request of the terminal 101 to the application program is received, the server 102 can quickly determine the preset request processing path corresponding to the target access request in the data table, so that the request verification efficiency is improved to a certain extent, and the protection efficiency of the application program is improved.

Referring to fig. 2, fig. 2 is a flowchart illustrating a request processing method according to an embodiment of the present application, where the request processing method may be executed by the server 102 in the request processing system 10 shown in fig. 1, and the request processing method may include the following steps S201 to S204:

in step S201, when a target access request to an application is received, a preset request processing path corresponding to the target access request is determined in a data table.

The data table may include a preset request processing path corresponding to each access request in at least one access request of the application program, and the data table may further include a request processing method of the preset request processing path corresponding to each access request, where the preset request processing path of each access request corresponds to the request processing method of the access request. For a specific process of establishing the data table, reference may be made to the description of step S302 to step S303 in the embodiment shown in fig. 3, which is not described herein again.

The target access request may be a Uniform Resource Locator (URL), and when a target access request to an application program is received, a request processing method corresponding to the target access request may be determined according to a request parameter in the target access request, and then a preset request processing path corresponding to the request processing method is determined in a data table according to the request processing method, that is, the preset request processing path corresponding to the target access request is determined in the data table. For example, the URL is "https:// www.example.com/logic/", a request processing method (for example, a logic () method) corresponding to the URL may be determined according to a request parameter "logic" in the URL, and then a preset request processing path corresponding to the request processing method may be determined in the data table according to the request processing method, that is, a preset request processing path corresponding to the target access request may be determined in the data table.

Step S202, an actual request processing path of the target access request is obtained according to a safety protection mechanism.

The safety protection mechanism can be injected into the source code of the application program in advance, and particularly, the safety protection mechanism can be injected into the source code of the application program in the development stage of the application program, the compilation stage of the application program or the interpretation and operation stage of the application program. For a specific injection process of the safety protection mechanism, reference may be made to the description of step S301 in the embodiment shown in fig. 3, which is not described herein again.

Step S203, the target access request is verified according to the actual request processing path and the preset request processing path corresponding to the target access request, and a verification result is obtained.

In one implementation, the target access request may be verified by determining whether a preset request processing path corresponding to the target access request is the same as an actual request processing path. If the preset request processing path corresponding to the target access request is the same as the actual request processing path, generating a verification result for successful verification of the target access request; and if the preset request processing path corresponding to the target access request is different from the actual request processing path, generating a verification result of failed verification of the target access request. Specifically, the preset request processing path corresponding to the target access request is the same as the actual request processing path, which may be: the methods included in the preset request processing path are the same as those included in the actual request processing path, and the calling order of the methods included in the preset request processing path is the same as that of the methods included in the actual request processing path. The preset request processing path corresponding to the target access request is different from the actual request processing path, which may be: the methods included in the preset request processing path are different from the methods included in the actual request processing path; or the calling sequence of each method included in the preset request processing path is different from the calling sequence of each method included in the actual request processing path; or, the methods included in the preset request processing path are different from the methods included in the actual request processing path, and the calling sequence of the methods included in the preset request processing path is different from the calling sequence of the methods included in the actual request processing path.

For example, the preset request processing path corresponding to the target access request is "request processing method 1 → data processing method 2 → data returning method 1", the actual request processing path corresponding to the target access request is "request processing method 1 → data processing method 3 → data returning method 1", each method included in the preset request processing path is different from each method included in the actual request processing path, and it is determined that the verification for the target access request fails. For another example, the preset request processing path corresponding to the target access request is "request processing method 1 → data processing method 2 → data returning method 1", the actual request processing path corresponding to the target access request is "request processing method 1 → data processing method 2 → data processing method 1 → data returning method 1", the calling sequence of each method included in the preset request processing path is different from the calling sequence of each method included in the actual request processing path, and it is determined that the verification of the target access request fails.

In another implementation manner, the target access request carries first data, and the target access request may be verified by determining whether a preset request processing path corresponding to the target access request is the same as an actual request processing path, and determining whether second data returned by the first actual data returning method is the same as the first data. And if the preset request processing path corresponding to the target access request is the same as the actual request processing path and the second data is the same as the first data, generating a verification result of successful verification of the target access request. If the preset request processing path corresponding to the target access request is different from the actual request processing path; or, if the second data is different from the first data; or, if the preset request processing path corresponding to the target access request is different from the actual request processing path and the second data is different from the first data, generating a verification result of failed verification of the target access request.

In one implementation, in order to prevent the unauthorized vulnerability from being generated, when the target access request is successfully verified, the target access request, the first actual request processing method in the actual request processing path and the first data may be stored in an associated manner; if the target access request is received again, a second actual request processing method and a second actual data returning method corresponding to the target access request received again can be obtained according to the safety protection mechanism, and third data returned by the second actual data returning method can be obtained; if the first actual request processing method is the same as the second actual request processing method, and the first data is matched with the third data (for example, the first data may be the same as the third data), generating a verification result that the verification of the target access request received again is successful; if the first actual request processing method is different from the second actual request processing method; or, if the first data does not match the third data; or if the first actual request processing method is different from the second actual request processing method and the first data is not matched with the third data, generating a verification result that the verification of the target access request received again fails. Taking a user query request as an example, the override vulnerability may refer to a situation where the same query request is sent twice for the same user and the returned query results are inconsistent. By the method, the unauthorized vulnerability can be effectively avoided, the request verification accuracy is further improved, and the protection accuracy of the application program is further improved.

In an implementation manner, if the verification of the second received target access request is successful, the first actual request processing method and the first data stored in association with each other may be overwritten by using a second actual request processing method and third data corresponding to the second received target access request. In addition, a caching time period (for example, 10 seconds) may be set, and when all the target access requests received multiple times are successfully verified within the caching time period (for example, within 10 seconds), the target access requests, the first actual request processing method, and the first data are not stored in an associated manner; when the target access requests received multiple times are checked to be successful outside the cache time period (for example, more than 10 seconds), the target access requests, the first actual request processing method and the first data may be stored in association. By setting the cache time period, when the target access requests received for multiple times are successfully verified outside the cache time period (for example, more than 10 seconds), the target access requests, the first actual request processing method and the first data can be stored in the cache space in an associated manner, so that cache resources can be reasonably allocated, and the cache space is saved. Further, a cache cleaning time period can be set, more than one access request to the application program can be set, more than one access request of the same type can be received, the data volume can be larger, the occupied cache space is more, the operation state of the application program is easily affected (for example, the operation process is blocked, the operation process is interrupted, and the like), the data of which the cache time exceeds the cache cleaning time period can be deleted from the cache, the cache space can be effectively managed, and the normal operation state of the application program can be maintained.

In one implementation, the request processing method may be used to perform secondary verification on the target access request. For example, the target access request is a user login request of an illegal user to the application program, and the user login request carries login information of the user (including a user name ' admin ' or ' 1 ' ═ 1 ' - -and a password ' arbitrary character '). Supposing that a developer of the application program does not set a function or a method for filtering characters in a user name due to negligence, or directly carries out database query after splicing the user name and a password in login information; at this time, since the query statement "SELECT × FROM USERS' where user name is constructed according to the login information of the illegal user is always true, so that the actual request processing path corresponding to the user login request is the same as the preset request processing path corresponding to the user login request, and the login information returned by the returned data method is also the same as the login information in the user login request, if the verification method in the above implementation manner is adopted, the verification will be failed. At this time, a request processing method may be adopted to perform auxiliary verification on the target access request, and if it is detected that the user name in the user login request is inconsistent with the normally input user name through the request processing method (for example, the normally input user name cannot include an illegal character "admin"), it may also be determined that the verification of the user login request fails, thereby further improving the accuracy of the request verification result, and further improving the accuracy of the security protection of the application program.

And step S204, determining a response strategy to the target access request according to the verification result.

When the verification result is that the verification of the target access request is successful, the determined response policy for the target access request may be to respond to the target access request, for example, to allow the application to log in, to return data requested by the target access request, and the like. When the verification result is that the verification of the target access request fails, the determined response policy to the target access request may be to deny a response to the target access request, for example, not allowing the application program to log in, prohibiting the data requested by the target access request from being returned, and the like; an alarm page can be output to the terminal which sends the target question-back request, and the alarm page is used for prompting that the target access request is blocked; the target access request and the actual request processing path corresponding to the target access request can be written into the log, and the alarm information is sent to the developer of the application program and the security manager of the application program, so that the developer of the application program and the security manager of the application program can know the illegal request received by the application program and the request processing path corresponding to the illegal request in time by checking the log or the alarm information, the application program can be repaired, and the security and the reliability of the application program are improved.

In the embodiment of the application, when a target access request to an application program is received, a preset request processing path corresponding to the target access request can be determined in a data table, an actual request processing path to the target access request can be monitored according to a safety protection mechanism injected into a source code of the application program in advance, the target access request is verified through the actual request processing path and the preset request processing path corresponding to the target access request, the accuracy of a request verification result can be effectively improved, and therefore the protection accuracy to the application program is effectively improved; in addition, the data table stores a preset request processing path corresponding to each access request in at least one access request of the application program, when a target access request to the application program is received, the preset request processing path corresponding to the target access request can be quickly determined in the data table, the request verification efficiency is improved to a certain extent, and therefore the protection efficiency of the application program is improved. In addition, the request processing method can be used for performing auxiliary verification on the target access request; when the target access request is successfully verified, the target access request, the first actual request processing method in the actual request processing path and the first data can be stored in an associated manner, so that the unauthorized vulnerability is effectively avoided, the accuracy of the request verification result is further improved, and the operation of the application program is safer and more reliable.

Referring to fig. 3, fig. 3 is a flowchart illustrating another request processing method according to an embodiment of the present application, where the request processing method may be executed by the server 102 in the request processing system 10 shown in fig. 1, and the request processing method may include the following steps S301 to S307:

step S301, a safety protection mechanism is injected into the source code of the application program.

The security protection mechanism can be understood as a development framework or a framework system composed of a piece of executable security protection code, and the security protection mechanism needs to be injected into the source code of the application program in the development stage of the application program. The security protection mechanism may include a request start identifier, at least one request method identifier, and a request end identifier. The request origin identifier may be used to identify a request processing method for the access request in the source code of the application; the request method identifier may be used to identify a data processing method for the access request in the source code of the application; the request end identifier may be used to identify a return data method for the access request in the source code of the application.

For the same type of access request, the request processing method for the access request, the at least one data processing method for the access request, and the return data method for the access request collectively form a preset request processing path for the access request, that is, the preset request processing path corresponding to the access request may include the request processing method located at the start point of the path, the at least one data processing method located between the start point of the path and the end point of the path, the return data method located at the end point of the path, and the calling order between the at least one data processing method.

In one implementation, the security protection mechanism may be manually injected into the source code of the application by a developer of the application during a development phase of the application according to development logic of the application. In another implementation manner, the security protection mechanism may also be automatically injected into the source code of the application program in a development stage of the application program according to a call relationship between methods included in a preset request processing path corresponding to each access request in at least one access request of the application program.

In the above two implementation manners, the injection process of the safety protection mechanism may be: adding a request starting identifier at a position corresponding to a request processing method in a source code of an application program, adding a request method identifier at a position corresponding to each data processing method in at least one data processing method in the source code of the application program according to a calling sequence among the at least one data processing method, and returning a request ending identifier at a position corresponding to the data method in the source code of the application program. For example, for the case of automatic labeling, after the request processing method is determined in the source code of the application program, a request start identifier is added at a position corresponding to the request processing method in the source code of the application program; then, automatically tracking the called data processing method 1 after the request processing method, and adding a request method identifier at a position corresponding to the data processing method 1 in a source code of an application program; and by analogy, the automatic tracking of the data processing method 2 called after the data processing method 1 is continued until the data returning method is tracked, and then the request ending identifier is added at the position corresponding to the data returning method in the source code of the application program.

Fig. 4 is a schematic diagram of an injection result of a security protection mechanism provided in an embodiment of the present application, where as shown in fig. 4, "@ Request _ Start ()" in a dashed box is a Request Start identifier; "@ Re Request _ Path _1 ()" and "@ Request _ Path _2 ()" in the dashed box are two Request method identifiers, and the calling order of the data processing method identified by "@ Request _ Path _1 ()" precedes the calling order of the data processing method identified by "@ Request _ Path _2 ()"; "@ Request _ Data _ Receive ()" is a Request end identifier. The Request processing method identified by "@ Request _ Start ()", the two Data processing methods identified by "@ Request _ Path _1 ()" and "@ req est _ Path _2 ()", and the return Data method identified by "@ Request _ Data _ Receive ()" constitute a preset Request processing Path together. It should be noted that the embodiment shown in fig. 4 is only an example, and does not constitute a limitation to the embodiment of the present application, and in an actual application scenario, the Request start identifier, the Request method identifier, and the Request end identifier may also be represented by other forms of identifiers, for example, the Request start identifier may also be represented by "@ Request _ Begin ()", the Request end identifier may also be represented by "@ Request _ Data _ Return ()", and the Request method identifier may also be represented by "@ Request _ Process ()".

Step S302, obtaining a preset request processing path corresponding to each access request in at least one access request of the application program through a security protection mechanism.

In an implementation manner, for a manner of automatically injecting a security protection mechanism, in an initialization stage of an application program, a preset request processing path corresponding to each access request in at least one access request of the application program may be obtained through the security protection mechanism. In another implementation manner, for a manner of manually injecting a security protection mechanism by a developer, a preset request processing path corresponding to each access request cannot be obtained at an initialization stage of an application program, because no mapping is formed among a request start identifier, a request method identifier, and a request end identifier manually injected by the developer, that is, a calling relationship among methods is not considered or a calling relationship among the methods is not labeled clearly in a process of injecting the request start identifier, the request method identifier, and the request end identifier into a source code by the developer; for the manner of manually injecting the security protection mechanism by the developer, only in the stage of compiling the application program or in the stage of interpreting and running the application program, the preset request processing path corresponding to each access request in at least one access request of the application program can be obtained through the security protection mechanism. The at least one access request may refer to all types of access requests that may be received by the application program, and may also refer to a part of types of access requests that may be received by the application program; for example, the at least one access request may include a user login request, a user query request, a user update request, and/or the like.

Step S303, recording a preset request processing path corresponding to each access request and a request processing method located at the start point of the path into a pre-established data table.

After a preset request processing path corresponding to each access request in at least one access request of an application program is acquired through a security protection mechanism, the preset request processing path corresponding to each access request and a request processing method located at the starting point of the path can be recorded into a pre-established data table; and the preset request processing path corresponding to each access request in the data table corresponds to the request processing method of the preset request processing path corresponding to the access request. In an implementation manner, for the manner of automatically injecting the security protection mechanism, in the initialization stage of the application program, the preset request processing path corresponding to each access request in at least one access request of the application program may be obtained through the security protection mechanism, so that the data table including the preset request processing path corresponding to each access request may be obtained in the initialization stage of the application program. In another implementation manner, for the manual injection of the security protection mechanism, in a stage of compiling the application program or in a stage of interpreting and running the application program, the preset request processing path corresponding to each access request in at least one access request of the application program may be obtained through the security protection mechanism, so that the data table including the preset request processing path corresponding to each access request may be obtained in a stage of compiling the application program or in a stage of interpreting and running the application program.

Table 1 shows an exemplary data table, and as shown in table 1, an application may receive 5 types of access requests, where each type of access request corresponds to a preset request processing path; table 1 includes 3 fields, which are an ID field, a request processing method field, and a preset request processing path field, respectively; the ID field is an own field of the database, the ID field is increased along with the increase of the types of the access requests, and the request processing method field is used for recording the request processing method corresponding to each access request; the preset request processing path field is used for recording a preset request processing path corresponding to each access request; the preset request processing paths corresponding to different types of access requests are different, so that the same entry cannot exist in the data table. It should be noted that the data table shown in table 1 is only for example and is not to be construed as limiting the embodiments of the present application.

TABLE 1

During the actual running process of the application program, a plurality of different target access requests of the same type to the application program can be received, for example, the received user login requests of a plurality of users to the application program; for a plurality of different target access requests, because the plurality of different target access requests belong to the same type, request processing paths (for example, a preset request processing path or an actual request processing path) corresponding to the plurality of different target access requests may be the same, but for different target access requests, return data returned by the return data method is different. As shown in fig. 5, fig. 5 is a schematic diagram of a correspondence relationship between a target access request and a data processing path provided in an embodiment of the present application, where a target access request 1 sent by a user 1 for an application, a target access request 2 sent by a user 2 for an application, and a target access request 3 sent by a user 3 for an application belong to the same type of access request, corresponding data processing paths are the same, but data returned by the same data return method are different, the target access request 1 corresponds to the return data 1, the target access request 2 corresponds to the return data 2, and the target access request 3 corresponds to the return data 3.

In step S304, when a target access request to the application program is received, a preset request processing path corresponding to the target access request is determined in the data table.

Step S305, acquiring an actual request processing path for the target access request according to the security protection mechanism.

And S306, verifying the target access request according to the actual request processing path and the preset request processing path corresponding to the target access request to obtain a verification result.

And step S307, determining a response strategy to the target access request according to the verification result.

In this embodiment of the application, an execution process of step S304 is the same as that of step S201 in the embodiment shown in fig. 2, an execution process of step S305 is the same as that of step S202 in the embodiment shown in fig. 2, an execution process of step S306 is the same as that of step S203 in the embodiment shown in fig. 2, an execution process of step S307 is the same as that of step S204 in the embodiment shown in fig. 2, and specific execution processes may refer to descriptions of the embodiment shown in fig. 2, and are not described again here.

In the embodiment of the application, the safety protection mechanism can be automatically injected into the source code of the application program according to the calling relation among the methods in the source code in the development stage of the application program, and the injection mode is more intelligent by the mode of automatically injecting the safety protection mechanism. The preset request processing path corresponding to each access request in at least one access request possibly received by an application program can be obtained through a safety protection mechanism, the preset request processing path corresponding to each access request is recorded into a pre-established data table, and the preset request processing path corresponding to each access request can be quickly inquired in the data table, so that the request verification efficiency is improved to a certain extent, and the protection efficiency of the application program is improved.

Referring to fig. 6, fig. 6 is a schematic structural diagram of a request processing apparatus provided in an embodiment of the present application, where the request processing apparatus 60 may be configured to execute corresponding steps in the request processing method shown in fig. 2 or fig. 3, and the request processing apparatus 60 may include the following units:

the determining unit 601 is configured to determine, when a target access request for an application is received, a preset request processing path corresponding to the target access request in a data table, where the data table includes a preset request processing path corresponding to each access request in at least one access request of the application;

an obtaining unit 602, configured to obtain an actual request processing path for a target access request according to a security mechanism, where the security mechanism is pre-injected into a source code of an application;

the verifying unit 603 is configured to verify the target access request according to the actual request processing path and a preset request processing path corresponding to the target access request, so as to obtain a verification result;

the determining unit 601 is further configured to determine a response policy to the target access request according to the verification result.

In one implementation, the determining unit 601 is further configured to:

injecting a security protection mechanism into the source code of the application program;

acquiring a preset request processing path corresponding to each access request in at least one access request of an application program through a safety protection mechanism;

and recording a preset request processing path corresponding to each access request and a request processing method positioned at the starting point of the path into a pre-established data table.

In one implementation, the security protection mechanism includes a request start identifier, at least one request method identifier, and a request end identifier; the preset request processing path comprises a request processing method positioned at the starting point of the path, at least one data processing method, a return data method positioned at the ending point of the path and a calling sequence among the at least one data processing method.

In an implementation manner, the determining unit 601 is specifically configured to:

adding a request starting identifier at a position corresponding to a request processing method in a source code of an application program;

adding a request method identifier at a position corresponding to each data processing method in at least one data processing method in a calling sequence in a source code of an application program;

and adding a request ending identifier at a position corresponding to the returned data method in the source code of the application program.

In an implementation manner, the checking unit 603 is specifically configured to:

judging whether a preset request processing path corresponding to the target access request is the same as an actual request processing path or not;

if the verification result is the same as the verification result, the verification of the target access request is successful;

if not, generating a verification result of failed verification of the target access request;

the preset request processing path is the same as the actual request processing path, and the preset request processing path refers to the following steps: the methods included in the preset request processing path are the same as those included in the actual request processing path, and the calling sequence of the methods included in the preset request processing path is the same as that of the methods included in the actual request processing path.

In one implementation, the actual request processing path includes a first actual return data method; the target access request carries first data; the verification unit 603 is specifically configured to:

acquiring second data returned by the first actual data returning method;

judging whether a preset request processing path corresponding to the target access request is the same as an actual request processing path and whether the matching of the first data and the second data is met;

if so, generating a verification result of successful verification of the target access request;

In one implementation, the actual request processing path further includes a first actual request processing method; a verification unit 603, further configured to:

if the verification result is that the target access request is verified successfully, the target access request, the first actual request processing method and the first data are stored in an associated mode;

if the target access request is received again, acquiring a second actual request processing method and a second actual data returning method corresponding to the target access request received again according to a safety protection mechanism, and acquiring third data returned by the second actual data returning method;

and if the first actual request processing method is the same as the second actual request processing method and the first data is matched with the third data, generating a verification result of successful verification of the target access request received again.

and if the verification result is that the verification of the target access request fails, refusing to respond to the target access request, outputting an alarm page, writing the target access request and an actual request processing path corresponding to the target access request into a log, wherein the alarm page is used for prompting that the target access request is blocked.

According to an embodiment of the present application, the units in the request processing apparatus 60 shown in fig. 6 may be respectively or entirely combined into one or several other units to form one or several other units, or some unit(s) may be further split into multiple units with smaller functions to form one or several other units, which may achieve the same operation without affecting the achievement of the technical effect of the embodiment of the present application. The units are divided based on logic functions, and in practical application, the functions of one unit can be realized by a plurality of units, or the functions of a plurality of units can be realized by one unit. In other embodiments of the present application, the request processing device 60 may also include other units, and in practical applications, these functions may also be implemented by being assisted by other units, and may be implemented by cooperation of multiple units. According to another embodiment of the present application, the request processing apparatus 60 shown in fig. 6 may be constructed by running a computer program (including program codes) capable of executing the steps involved in the corresponding method shown in fig. 2 or fig. 3 on a general-purpose computing device including a general-purpose computer such as a Central Processing Unit (CPU), a random access storage medium (RAM), a read-only storage medium (ROM), and the like, and a storage element, and the request processing method of the embodiment of the present application may be implemented. The computer program may be embodied on a computer readable storage medium, for example, and loaded and run in the server 102 of the request processing system shown in fig. 1 via the computer readable storage medium.

Referring to fig. 7, fig. 7 is a schematic structural diagram of a request processing device according to an embodiment of the present disclosure, where the request processing device includes a processor 701, a memory 702, and a communication interface 703, and the processor 701, the memory 702, and the communication interface 703 are connected by one or more communication buses.

The processor 701 is configured to perform corresponding steps in the request processing method shown in fig. 2 or fig. 3. The Processor 701 may be a Central Processing Unit (CPU), a Network Processor (NP), a hardware chip, or any combination thereof.

The memory 702 is used to store computer programs and the like. The Memory 702 may include volatile Memory (volatile Memory), such as Random Access Memory (RAM); the Memory 702 may also include a Non-Volatile Memory (NVM), such as a Read-Only Memory (ROM), a flash Memory (flash Memory), a Hard Disk (Hard Disk Drive, HDD) or a Solid-State Drive (SSD); the memory 702 may also comprise a combination of the above types of memory.

The communication interface 703 is used for receiving and transmitting data, for example, the communication interface 703 is used for receiving a target access request to an application program, the communication interface 703 is used for outputting an alarm page, and the like. In this embodiment, the request processing device may include a plurality of communication interfaces, where a communication interface for transmitting data and a communication interface for receiving data may not be the same communication interface.

The processor 701 invokes a computer program stored in the memory 702 to perform the following steps:

In one implementation, the processor 701 invokes a computer program stored in the memory 702 to further perform the following steps:

In one implementation, the processor 701 invokes a computer program stored in the memory 702 to specifically perform the following steps:

In one implementation, the actual request processing path includes a first actual return data method; the target access request carries first data; the processor 701 invokes the computer program stored in the memory 702 to specifically perform the following steps:

acquiring second data returned by the first actual data returning method;

In one implementation, the actual request processing path further includes a first actual request processing method; the processor 701 invokes the computer program stored in the memory 702 to further perform the following steps:

Embodiments of the present application further provide a computer-readable storage medium, which may be used to store a computer program, where the computer program, when being called by a processor of a computer device, enables the computer device to perform corresponding steps of the request processing method in the foregoing fig. 2 or fig. 3 embodiment. The computer-readable storage medium includes, but is not limited to, flash memory (flash memory), Hard Disk Drive (HDD), Solid-State Drive (SSD).

The embodiment of the present application further provides a computer program product, and when the computer program product is executed by a computer device, the computer program product may perform corresponding steps of the request processing method in the foregoing fig. 2 or fig. 3 embodiment.

Those of ordinary skill in the art will appreciate that the various illustrative elements and algorithm steps described in connection with the embodiments disclosed herein may be implemented as electronic hardware, computer software, or combinations of computer software and electronic hardware. Whether such functionality is implemented as hardware or software depends upon the particular application and design constraints imposed on the implementation. Skilled artisans may implement the described functionality in varying ways for each particular application, but such implementation decisions should not be interpreted as causing a departure from the scope of the present application.

In the above embodiments, the implementation may be wholly or partially realized by software, hardware, firmware, or any combination thereof. When implemented in software, may be implemented in whole or in part in the form of a computer program product. The computer program product includes one or more computer instructions. When loaded and executed on a computer, cause the processes or functions described in accordance with the embodiments of the application to occur, in whole or in part. The computer may be a general purpose computer, a special purpose computer, or other programmable apparatus. The computer instructions may be stored in or transmitted over a computer-readable storage medium. The computer instructions may be transmitted from one website, computer, server, or data center to another website, computer, server, or data center via wired (e.g., coaxial cable, fiber optic, Digital Subscriber Line (DSL), etc.) or wireless (e.g., infrared, microwave, etc.) means. The computer-readable storage medium can be any available medium that can be accessed by a computer or a data storage device, such as a server, a data center, etc., that incorporates one or more of the available media. The usable medium may be a magnetic medium (e.g., floppy Disk, hard Disk, magnetic tape), an optical medium (e.g., DVD), or a semiconductor medium (e.g., Solid State Disk (SSD)), among others.

The above description is only for the specific embodiments of the present application, but the scope of the present application is not limited thereto, and any person skilled in the art can easily conceive of the changes or substitutions within the technical scope of the present application, and shall be covered by the scope of the present application. Therefore, the protection scope of the present application shall be subject to the protection scope of the claims.

Claims

1. A method for processing a request, the method comprising:

when a target access request to an application program is received, determining a preset request processing path corresponding to the target access request in a data table, wherein the data table comprises a preset request processing path corresponding to each access request in at least one access request of the application program;

acquiring an actual request processing path of the target access request according to a safety protection mechanism, wherein the safety protection mechanism is pre-injected into a source code of the application program;

2. The method according to claim 1, wherein before determining the preset request processing path corresponding to the target access request in the data table, the method further comprises:

injecting the security protection mechanism in source code of the application;

acquiring a preset request processing path corresponding to each access request in at least one access request of the application program through the safety protection mechanism;

and recording a preset request processing path corresponding to each access request and a request processing method positioned at the starting point of the path into the pre-established data table.

3. The method of claim 2, wherein the security protection mechanism comprises a request start identifier, at least one request method identifier, and a request end identifier; the preset request processing path comprises the request processing method positioned at the starting point of the path, at least one data processing method, a return data method positioned at the ending point of the path and a calling sequence among the at least one data processing method.

4. The method of claim 3, wherein injecting the security protection mechanism in the source code of the application comprises:

adding the request starting identifier at a position corresponding to the request processing method in the source code of the application program;

adding a request method identifier at a position corresponding to each data processing method in the at least one data processing method in the calling sequence in the source code of the application program;

and adding the request ending identifier at a position corresponding to the return data method in the source code of the application program.

5. The method according to any one of claims 1 to 4, wherein the verifying the target access request according to the actual request processing path and a preset request processing path corresponding to the target access request to obtain a verification result includes:

judging whether a preset request processing path corresponding to the target access request is the same as the actual request processing path or not;

wherein, the preset request processing path is the same as the actual request processing path, which means that: each method included in the preset request processing path is the same as each method included in the actual request processing path, and the calling sequence of each method included in the preset request processing path is the same as the calling sequence of each method included in the actual request processing path.

6. The method of any of claims 1 to 4, wherein the actual request processing path includes a first actual return data method; the target access request carries first data; the verifying the target access request according to the actual request processing path and a preset request processing path corresponding to the target access request to obtain a verification result includes:

acquiring second data returned by the first actual data returning method;

judging whether a preset request processing path corresponding to the target access request is the same as the actual request processing path and whether the first data and the second data are matched;

7. The method of claim 6, wherein the actual request processing path further comprises a first actual request processing method; the method further comprises the following steps:

if the target access request is received again, acquiring a second actual request processing method and a second actual data returning method corresponding to the target access request received again according to the safety protection mechanism, and acquiring third data returned by the second actual data returning method;

and if the first actual request processing method is the same as the second actual request processing method and the first data is matched with the third data, generating a verification result for successfully verifying the target access request received again.

8. The method of claim 1, wherein determining a response policy to the target access request according to the verification result comprises:

and if the verification result is that the verification of the target access request fails, refusing to respond to the target access request, outputting an alarm page, and writing the target access request and an actual request processing path corresponding to the target access request into a log, wherein the alarm page is used for prompting that the target access request is blocked.

9. A request processing apparatus, characterized in that the request processing apparatus comprises:

an obtaining unit, configured to obtain an actual request processing path for the target access request according to a security protection mechanism, where the security protection mechanism is pre-injected into a source code of the application program;

the determining unit is further configured to determine a response policy to the target access request according to the verification result.

10. A computer-readable storage medium, characterized in that it stores a computer program which, when read and executed by a processor of a computer device, causes the computer device to perform the request processing method of any one of claims 1 to 8.