An over-authorization checking method, device and electronic equipment

Abstract

Embodiments of the present application provide an over-authorization checking method, which comprises: in response to a service access request of a user, obtaining identity information of the user and a request parameter of the service access request; determining a target service interface corresponding to the service access request based on the request parameter, and an over-authorization annotation associated with the target service interface; determining an over-authorization checking logic for the service access request from a pre-configured aspect layer based on the over-authorization annotation, and performing over-authorization checking on the service access request through the over-authorization checking logic. The technical solution of the embodiments of the present application can improve the convenience of checking over-authorization operations, and improve the generality of over-authorization checking logic code.

Description

Technical Field

[0001] This application relates to the field of data processing technology, and more specifically, to an unauthorized access verification method, apparatus, storage medium, and electronic device. Background Technology

[0002] Privilege escalation vulnerabilities, commonly found in web applications, pose serious threats to code integrity. These vulnerabilities include vertical and horizontal privilege escalation. Vertical privilege escalation occurs when a user who shouldn't have access to a function bypasses front-end verification through a special backend, allowing direct access. Horizontal privilege escalation occurs when a user accessing a function sees data outside their authorized scope. Currently, to overcome these vulnerabilities, privilege escalation verification logic is often written directly into the business logic. While simple and convenient, this approach is prone to errors if code reviews are neglected, and each business interface requires identical verification logic. Furthermore, changes in business scenarios necessitate modifications to the verification logic, resulting in poor versatility. Therefore, improving the ease of verifying privilege escalation operations while simultaneously enhancing the versatility of the verification logic code is a pressing technical challenge. Summary of the Invention

[0003] The embodiments of this application provide an unauthorized access verification method, apparatus, storage medium, and electronic device, which can improve the convenience of verifying unauthorized operations to a certain extent, and at the same time improve the versatility of unauthorized access verification logic code.

[0004] Other features and advantages of this application will become apparent from the following detailed description, or may be learned in part from practice of this application.

[0005] According to a first aspect of the embodiments of this application, an unauthorized access verification method is provided. The method includes: in response to a user's business access request, obtaining the user's identity information and request parameters of the business access request; determining a target business interface corresponding to the business access request and an unauthorized access annotation associated with the target business interface based on the request parameters; determining unauthorized access verification logic for the business access request from a pre-configured aspect layer based on the unauthorized access annotation, and performing unauthorized access verification on the business access request through the unauthorized access verification logic.

[0006] In some embodiments of this application, based on the foregoing scheme, the unauthorized access annotation includes vertical unauthorized access annotation and horizontal unauthorized access annotation. The step of determining the unauthorized access verification logic for the service access request from the pre-configured aspect layer based on the unauthorized access annotation includes: determining the vertical unauthorized access verification logic for the service access request from the pre-configured aspect layer based on the vertical unauthorized access annotation; if the service access request passes the vertical unauthorized access verification of the vertical unauthorized access verification logic, then determining the horizontal unauthorized access verification logic for the service access request from the pre-configured aspect layer based on the horizontal unauthorized access annotation.

[0007] In some embodiments of this application, based on the aforementioned scheme, the vertical unauthorized access verification logic is used to verify whether the user's identity information has access rights to the target business interface.

[0008] In some embodiments of this application, based on the foregoing scheme, determining the horizontal privilege escalation verification logic for the service access request from the pre-configured aspect layer based on the horizontal privilege escalation annotation includes: determining the method name and parameter list of the target service interface based on the horizontal privilege escalation annotation; and determining the horizontal privilege escalation verification logic for the service access request from the pre-configured aspect layer based on the method name and the parameter list.

[0009] In some embodiments of this application, based on the foregoing scheme, before obtaining the user's identity information and the request parameters of the service access request, the method further includes: obtaining a pre-configured unauthorized access verification logic package, the unauthorized access verification logic package including unauthorized access verification logic corresponding to multiple service interfaces; selecting and adjusting the unauthorized access verification logic corresponding to the target service interface from the unauthorized access verification logic package; configuring an associated unauthorized access annotation for the target service interface to associate the unauthorized access annotation with the unauthorized access verification logic corresponding to the target service interface.

[0010] In some embodiments of this application, based on the foregoing scheme, if no unauthorized annotation associated with the target business interface is determined, unauthorized verification logic for the business access request is determined based on the verification logic interface of the target business interface, and unauthorized verification of the business access request is performed through the unauthorized verification logic.

[0011] In some embodiments of this application, based on the foregoing scheme, after performing unauthorized access verification on the service access request based on the unauthorized access verification logic, the method further includes: if the service access request passes the unauthorized access verification, then executing the target service corresponding to the target service interface; if the service access request fails the unauthorized access verification, then sending a prompt message to the user, the prompt message being used to prompt the user that they do not have access rights to the target service.

[0012] According to a second aspect of the embodiments of this application, an unauthorized access verification device is provided. The device includes: a response unit, configured to respond to a user's business access request and obtain the user's identity information and request parameters of the business access request; a determination unit, configured to determine, based on the request parameters, a target business interface corresponding to the business access request and an unauthorized access annotation associated with the target business interface; and a verification unit, configured to determine unauthorized access verification logic for the business access request from a pre-configured aspect layer based on the unauthorized access annotation, and to perform unauthorized access verification on the business access request through the unauthorized access verification logic.

[0013] According to a third aspect of the embodiments of this application, a computer-readable storage medium is provided, characterized in that the computer-readable storage medium stores at least one piece of program code, the at least one piece of program code being loaded and executed by a processor to perform the operations performed by the method described in any of the first aspects above.

[0014] According to a fourth aspect of the present application, an electronic device is provided, including one or more processors and one or more memories, wherein at least one piece of program code is stored in the one or more memories, the at least one piece of program code being loaded and executed by the one or more processors to perform the operation as described in any of the first aspects above.

[0015] In the technical solution of this application, when the server receives a service access request sent by the terminal device, it obtains the identity information of the user initiating the service access request and the request parameters of the service access request; then, based on the request parameters, it determines the target service interface corresponding to the service access request and the unauthorized access annotation associated with the target service interface; finally, based on the unauthorized access annotation, it determines the unauthorized access verification logic for the service access request from the pre-configured aspect layer, and performs unauthorized access verification on the service access request through the unauthorized access verification logic. As can be seen, the technical solution of this application eliminates the need to write unauthorized access verification logic at each business interface. Instead, the unauthorized access verification logic for business access requests is uniformly written into the aspect layer. This allows the unauthorized access verification logic for business access requests to be determined simply by configuring the associated unauthorized access annotation for each business interface. This reduces the tediousness of writing unauthorized access verification logic to a certain extent, improves the convenience of verifying unauthorized operations, and avoids information leakage caused by omitting the writing of unauthorized access verification logic. In addition, because the unauthorized access verification logic is uniformly written in the aspect layer, the unauthorized access verification logic code provided by this application can adapt to a variety of different business scenarios and has strong versatility.

[0016] It should be understood that the above general description and the following detailed description are exemplary and explanatory only, and do not limit this application. Attached Figure Description

[0017] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with this application and, together with the description, serve to explain the principles of this application. It is obvious that the drawings described below are merely some embodiments of this application, and those skilled in the art can obtain other drawings based on these drawings without any inventive effort. In the drawings:

[0018] Figure 1 A flowchart of an overreach verification method according to an embodiment of this application is shown;

[0019] Figure 2 A detailed flowchart illustrating the logic for determining the unauthorization verification of the service access request from a pre-configured aspect layer based on the unauthorization annotation according to an embodiment of this application is shown.

[0020] Figure 3 A block diagram of an overreach verification apparatus according to an embodiment of this application is shown;

[0021] Figure 4 A schematic diagram of the structure of a computer system suitable for implementing the electronic device of the present application is shown. Detailed Implementation

[0022] Exemplary embodiments will now be described more fully with reference to the accompanying drawings. However, these exemplary embodiments can be implemented in many forms and should not be construed as limited to the examples set forth herein; rather, these embodiments are provided to make this application more comprehensive and complete, and to fully convey the concept of the exemplary embodiments to those skilled in the art.

[0023] Furthermore, the described features, structures, or characteristics can be combined in any suitable manner in one or more embodiments. Numerous specific details are provided in the following description to give a thorough understanding of embodiments of this application. However, those skilled in the art will recognize that the technical solutions of this application can be practiced without one or more of the specific details, or other methods, components, apparatuses, steps, etc., can be employed. In other instances, well-known methods, apparatuses, implementations, or operations are not shown or described in detail to avoid obscuring various aspects of this application.

[0024] The block diagrams shown in the accompanying drawings are merely functional entities and do not necessarily correspond to physically independent entities. That is, these functional entities can be implemented in software, in one or more hardware modules or integrated circuits, or in different network and / or processor devices and / or microcontroller devices.

[0025] The flowcharts shown in the accompanying drawings are merely illustrative and do not necessarily include all content and operations / steps, nor do they necessarily have to be performed in the described order. For example, some operations / steps can be broken down, while others can be combined or partially combined; therefore, the actual execution order may change depending on the specific circumstances.

[0026] It should be noted that "multiple" in this article refers to two or more. "And / or" describes the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can represent: A alone, A and B simultaneously, or B alone. The character " / " generally indicates that the preceding and following related objects have an "or" relationship.

[0027] It should be noted that the terms "first," "second," etc., in the specification, claims, and accompanying drawings of this application are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such uses of these terms can be interchanged where appropriate so that the embodiments of this application described herein can be implemented in orders other than those illustrated or described.

[0028] To make the objectives, technical solutions, and advantages of this invention clearer, the technical solutions of the embodiments of this invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only a part of the embodiments of this invention, and not all of them. Based on the embodiments of this invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this invention.

[0029] The following detailed description of some embodiments of this application will be provided in conjunction with the accompanying drawings. Unless otherwise specified, the following embodiments and features can be combined with each other.

[0030] See Figure 1 The flowchart of an overreach verification method according to an embodiment of the present application is shown, specifically including steps 110 to 130.

[0031] Step 110: In response to the user's business access request, obtain the user's identity information and the request parameters of the business access request.

[0032] It is understood that the user's identity information includes, but is not limited to, the user's account information, the permission information corresponding to the user account, etc. The request parameters are used to describe the relevant content of the user's business access request, such as a request to query user information for account A, a request to delete user information for account A, a request to edit user information for account A, etc.

[0033] In some implementations, when a user triggers a service access request on a terminal device, the server receives the service access request sent from the terminal device, and simultaneously obtains the identity information of the user who initiated the service access request, as well as the request content of the service access request.

[0034] Step 120: Determine the target business interface corresponding to the business access request and the unauthorized annotation associated with the target business interface based on the request parameters.

[0035] In some implementations, the privilege escalation annotation includes a vertical privilege escalation annotation (@CheckFunction) and a horizontal privilege escalation annotation (@CheckDataRange).

[0036] Step 130: Determine the unauthorized access request verification logic from the pre-configured aspect layer based on the unauthorized access annotation, and perform unauthorized access verification on the business access request through the unauthorized access verification logic.

[0037] In some implementations, the logic for determining the unauthorized access request from the pre-configured aspect layer based on the unauthorized annotation can be as follows: Figure 2 The method shown is executed.

[0038] See Figure 2 The diagram illustrates a detailed flowchart of an embodiment of this application, showing how to determine the unauthorized access request verification logic from a pre-configured aspect layer based on the unauthorized annotation, specifically including steps 131 to 132.

[0039] Step 131: Determine the vertical privilege escalation verification logic for the business access request from the pre-configured aspect layer based on the vertical privilege escalation annotation.

[0040] In some implementations, the vertical privilege escalation verification logic is used to verify whether the user's identity information has access rights to the target business interface.

[0041] It is understood that the vertical privilege escalation annotation can be used to obtain the vertical privilege escalation verification logic for the business access request through the index, and the user's identity information can be passed to the vertical privilege escalation verification logic, thereby enabling vertical privilege escalation verification of the business access request.

[0042] It should be noted that the aspect layer is aspect-based AOP, and only one type of vertical privilege escalation verification logic (i.e., a set of vertical privilege escalation verification code) is set in the aspect layer. For different users initiating business access requests to the same business, or for the same user initiating business access requests to different businesses, the same vertical privilege escalation verification logic is used to perform vertical privilege escalation verification on the business access requests.

[0043] See also Figure 2 Step 132: If the business access request passes the vertical privilege escalation check of the vertical privilege escalation check logic, then the horizontal privilege escalation check logic for the business access request is determined from the pre-configured aspect layer based on the horizontal privilege escalation annotation.

[0044] In some implementations, if the service access request fails the vertical privilege escalation check of the vertical privilege escalation check logic, the user's service access request is rejected. For example, assuming the user's identity information is that of a regular user, if the vertical privilege escalation check logic determines that the user's service access request is for accessing an administrator's operation privileges, then the user's service access request is rejected.

[0045] In some implementations, the determination of the lateral privilege escalation verification logic for the service access request from the pre-configured aspect layer based on the lateral privilege escalation annotation can be performed according to steps 1321 to 1322 below.

[0046] Step 1321: Determine the method name and parameter list of the target business interface based on the horizontal overriding annotation.

[0047] In some implementations, the method name and parameter list corresponding to the target business interface can be written into the horizontal privilege escalation annotation corresponding to the target business interface.

[0048] It should be noted that because the horizontal privilege escalation logic differs across different business interfaces, it is necessary to set method names and parameter columns to accurately determine the vertical privilege escalation logic corresponding to each business interface. The method name describes the business module to which the target business interface belongs, and the parameter columns describe the business content corresponding to the target business interface. For example, business department modules, human resources department modules, and R&D department modules can be used as method names; employee information viewing, employee information editing, and employee position adjustment can be used as parameter columns.

[0049] Step 1322: Determine the lateral privilege escalation logic for the service access request from the pre-configured aspect layer based on the method name and the parameter list.

[0050] It is understood that the horizontal privilege escalation check logic configured in the aspect layer corresponding to the method name and parameter columns can be indexed using the method name and parameter columns, thereby determining whether the service accessed by the user can be controlled by the user based on the user's identity information. For different business scenarios, only adaptive adjustments to the method name and parameter columns are needed to perform horizontal privilege escalation checks for the respective business scenarios.

[0051] In some implementations, before obtaining the user's identity information and the request parameters of the service access request, the method further includes the following steps 1 to 3.

[0052] Step 1: Obtain the pre-configured unauthorized access verification logic package, which includes unauthorized access verification logic corresponding to multiple business interfaces.

[0053] In some implementations, the privilege escalation verification logic package may be a Jar package for preventing privilege escalation. Furthermore, the privilege escalation verification logic package includes vertical privilege escalation verification logic and horizontal privilege escalation verification logic.

[0054] Step 2: Select and adjust the unauthorized access verification logic corresponding to the target business interface from the unauthorized access verification logic package.

[0055] It is understandable that if the above-mentioned unauthorized access verification logic package is introduced into business scenario A, then the unauthorized access verification logic included in the above-mentioned unauthorized access verification logic needs to be adjusted according to the characteristics of business scenario A so as to adapt to the business interfaces included in business scenario A.

[0056] Step 3: Configure an associated privilege escalation annotation for the target business interface to associate the privilege escalation annotation with the privilege escalation verification logic corresponding to the target business interface.

[0057] It is understandable that business interfaces that require configuration of privilege escalation annotations can be exposed, and then corresponding vertical and horizontal privilege escalation annotations can be configured to enable privilege escalation verification of user access operations when users access the business.

[0058] In this embodiment, the over-authority verification logic package makes the over-authority verification logic of this application highly portable, applicable to different business scenarios, and highly versatile.

[0059] In some implementations, the unauthorized access verification method proposed in this application further includes: if no unauthorized access annotation associated with the target business interface is determined, then an unauthorized access verification logic for the business access request is determined based on the verification logic interface of the target business interface, and the unauthorized access request is verified by the unauthorized access verification logic.

[0060] It's understandable that for some special business interfaces, such as those not controlled by roles, it's not suitable to use the privilege escalation logic written in the aspect layer. In such cases, special privilege escalation logic is needed. Therefore, a corresponding validation logic interface is set up for this type of special business interface, and the privilege escalation logic for this type of special business interface is written into the corresponding validation logic interface, thus realizing privilege escalation validation for this type of special business interface.

[0061] In this embodiment, by setting a verification logic interface, it is possible to write unauthorized access verification logic that matches a special business interface, making the unauthorized access verification method of this application highly scalable.

[0062] In some implementations, the unauthorized access verification method proposed in this application further includes: after performing unauthorized access verification on the service access request based on the verification logic, if the service access request passes the unauthorized access verification, then the target service corresponding to the target service interface is executed; if the service access request fails the unauthorized access verification, then a prompt message is sent to the user, the prompt message being used to prompt the user that they do not have access rights to the target service.

[0063] It is understood that if a user's business access request fails the vertical privilege escalation check, or passes the vertical privilege escalation check but fails the horizontal privilege escalation check, the user will receive the prompt message on the terminal device to remind the user that they do not have access rights to the business they are trying to access, thereby improving the security of business access.

[0064] In some embodiments of the technical solutions provided in this application, when the server receives a service access request sent by a terminal device, it obtains the identity information of the user initiating the service access request and the request parameters of the service access request; then, based on the request parameters, it determines the target service interface corresponding to the service access request and the unauthorized access annotation associated with the target service interface; finally, based on the unauthorized access annotation, it determines the unauthorized access verification logic for the service access request from a pre-configured aspect layer, and performs unauthorized access verification on the service access request through the unauthorized access verification logic. As can be seen, the technical solution of this application eliminates the need to write unauthorized access verification logic at each business interface. Instead, the unauthorized access verification logic for business access requests is uniformly written into the aspect layer. This allows the unauthorized access verification logic for business access requests to be determined simply by configuring the associated unauthorized access annotation for each business interface. This reduces the tediousness of writing unauthorized access verification logic to a certain extent, improves the convenience of verifying unauthorized operations, and avoids information leakage caused by omitting the writing of unauthorized access verification logic. In addition, because the unauthorized access verification logic is uniformly written in the aspect layer, the unauthorized access verification logic code provided by this application can adapt to a variety of different business scenarios and has strong versatility.

[0065] The following describes an embodiment of the apparatus described in this application, which can be used to execute the unauthorized access verification method in the above embodiments of this application. For details not disclosed in the apparatus embodiments of this application, please refer to the embodiments of the unauthorized access verification method described above in this application.

[0066] Figure 3 A block diagram of an overreach verification apparatus according to an embodiment of this application is shown.

[0067] Reference Figure 3 As shown, an overreach verification device 300 according to an embodiment of this application includes: an acquisition unit 301, a determination unit 302, and a verification unit 303.

[0068] The response unit 301 is used to respond to a user's business access request by obtaining the user's identity information and the request parameters of the business access request; the determination unit 302 is used to determine the target business interface corresponding to the business access request and the unauthorized access annotation associated with the target business interface based on the request parameters; and the verification unit 303 is used to determine the unauthorized access verification logic for the business access request from a pre-configured aspect layer based on the unauthorized access annotation, and to perform unauthorized access verification on the business access request through the unauthorized access verification logic.

[0069] In some embodiments of this application, based on the foregoing scheme, the verification unit 303 is further configured to: the unauthorized access annotation includes a vertical unauthorized access annotation and a horizontal unauthorized access annotation; the step of determining the verification logic for the service access request from the pre-configured aspect layer based on the unauthorized access annotation includes: determining the vertical unauthorized access verification logic for the service access request from the pre-configured aspect layer based on the vertical unauthorized access annotation; if the service access request passes the vertical unauthorized access verification of the vertical unauthorized access verification logic, then determining the horizontal unauthorized access verification logic for the service access request from the pre-configured aspect layer based on the horizontal unauthorized access annotation.

[0070] In some embodiments of this application, based on the foregoing scheme, the verification unit 303 is further configured to: use the vertical over-authority verification logic to verify whether the user's identity information has access rights to the target business interface.

[0071] In some embodiments of this application, based on the foregoing scheme, the verification unit 303 is further configured to: determine the method name and parameter list of the target business interface based on the lateral privilege escalation annotation; and determine the lateral privilege escalation verification logic for the business access request from a pre-configured aspect layer based on the method name and the parameter list.

[0072] In some embodiments of this application, based on the foregoing scheme, the response unit 301 is further configured to: obtain a pre-configured unauthorized access verification logic package, the unauthorized access verification logic package including unauthorized access verification logic corresponding to multiple service interfaces; select and adjust the unauthorized access verification logic corresponding to the target service interface from the unauthorized access verification logic package; configure an associated unauthorized access annotation for the target service interface to associate the unauthorized access annotation with the unauthorized access verification logic corresponding to the target service interface.

[0073] In some embodiments of this application, based on the foregoing scheme, the verification unit 303 is further configured to: if no unauthorized annotation associated with the target business interface is determined, determine the unauthorized verification logic for the business access request based on the verification logic interface of the target business interface, and perform unauthorized verification on the business access request through the verification logic.

[0074] In some embodiments of this application, based on the foregoing scheme, the verification unit 303 is further configured to: if the service access request passes the unauthorized access verification, execute the target service corresponding to the target service interface; if the service access request fails the unauthorized access verification, send a prompt message to the user, the prompt message being used to prompt the user that they do not have access rights to the target service.

[0075] Figure 4 A schematic diagram of the structure of a computer system suitable for implementing the electronic device of the present application is shown.

[0076] It should be noted that, Figure 4 The computer system 400 of the electronic device shown is merely an example and should not impose any limitation on the functionality and scope of use of the embodiments of this application.

[0077] like Figure 4 As shown, the computer system 400 includes a Central Processing Unit (CPU) 401, which can perform various appropriate actions and processes based on programs stored in Read-Only Memory (ROM) 402 or programs loaded from storage portion 408 into Random Access Memory (RAM) 403, such as performing the methods described in the above embodiments. The RAM 403 also stores various programs and data required for system operation. The CPU 401, ROM 402, and RAM 403 are interconnected via a bus 404. An Input / Output (I / O) interface 405 is also connected to the bus 404.

[0078] The following components are connected to I / O interface 405: an input section 406 including a keyboard, mouse, etc.; an output section 407 including a cathode ray tube (CRT), liquid crystal display (LCD), etc., and speakers, etc.; a storage section 408 including a hard disk, etc.; and a communication section 409 including a network interface card such as a LAN (Local Area Network) card, modem, etc. The communication section 409 performs communication processing via a network such as the Internet. A drive 410 is also connected to I / O interface 405 as needed. A removable medium 411, such as a disk, optical disk, magneto-optical disk, semiconductor memory, etc., is installed on drive 410 as needed so that computer programs read from it can be installed into storage section 408 as needed.

[0079] Specifically, according to embodiments of this application, the processes described above with reference to the flowcharts can be implemented as computer software programs. For example, embodiments of this application include a computer program product comprising a computer program carried on a computer-readable medium, the computer program containing program code for performing the methods shown in the flowcharts. In such embodiments, the computer program can be downloaded and installed from a network via communication section 409, and / or installed from removable medium 411. When the computer program is executed by central processing unit (CPU) 401, it performs various functions defined in the system of this application.

[0080] It should be noted that the computer-readable medium shown in the embodiments of this application can be a computer-readable signal medium or a computer-readable storage medium, or any combination of the two. A computer-readable storage medium can be, for example,—but not limited to—an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any combination thereof. More specific examples of a computer-readable storage medium may include, but are not limited to: an electrical connection having one or more wires, a portable computer disk, a hard disk, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM), flash memory, optical fiber, portable compact disc read-only memory (CD-ROM), optical storage device, magnetic storage device, or any suitable combination thereof. In this application, a computer-readable storage medium can be any tangible medium containing or storing a program that can be used by or in conjunction with an instruction execution system, apparatus, or device. In this application, a computer-readable signal medium can include a data signal propagated in baseband or as part of a carrier wave, carrying computer-readable program code. Such transmitted data signals can take various forms, including but not limited to electromagnetic signals, optical signals, or any suitable combination thereof. The computer-readable signal medium can also be any computer-readable medium other than a computer-readable storage medium, which can send, propagate, or transmit a program for use by or in connection with an instruction execution system, apparatus, or device. The program code contained on the computer-readable medium can be transmitted using any suitable medium, including but not limited to wireless, wired, etc., or any suitable combination thereof.

[0081] The flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of this application. Each block in a flowchart or block diagram may represent a module, segment, or portion of code, which contains one or more executable instructions for implementing a specified logical function. It should also be noted that in some alternative implementations, the functions indicated in the blocks may occur in a different order than those indicated in the drawings. For example, two consecutively indicated blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in a block diagram or flowchart, and combinations of blocks in a block diagram or flowchart, can be implemented using a dedicated hardware-based system that performs the specified function or operation, or using a combination of dedicated hardware and computer instructions.

[0082] The units described in the embodiments of this application can be implemented in software or hardware, and the described units can also be located in a processor. The names of these units do not necessarily limit the specific unit itself.

[0083] In another aspect, this application also provides a computer program product or computer program including computer instructions stored in a computer-readable storage medium. A processor of a computer device reads the computer instructions from the computer-readable storage medium and executes the computer instructions, causing the computer device to perform the unauthorized access verification method described in the above embodiments.

[0084] In another aspect, this application also provides a computer-readable medium, which may be included in the electronic device described in the above embodiments; or it may exist independently and not assembled into the electronic device. The computer-readable medium carries one or more programs, which, when executed by the electronic device, cause the electronic device to implement the unauthorized access verification method described in the above embodiments.

[0085] It should be noted that although several modules or units for the device used to perform actions have been mentioned in the detailed description above, this division is not mandatory. In fact, according to the embodiments of this application, the features and functions of two or more modules or units described above can be embodied in one module or unit. Conversely, the features and functions of one module or unit described above can be further divided and embodied by multiple modules or units.

[0086] Through the above description of the embodiments, those skilled in the art will readily understand that the exemplary embodiments described herein can be implemented by software or by combining software with necessary hardware. Therefore, the technical solutions according to the embodiments of this application can be embodied in the form of a software product, which can be stored in a non-volatile storage medium (such as a CD-ROM, USB flash drive, external hard drive, etc.) or on a network, including several instructions to cause a computing device (such as a personal computer, server, touch terminal, or network device, etc.) to execute the method according to the embodiments of this application.

[0087] Other embodiments of this application will readily conceive of by those skilled in the art upon consideration of the specification and practice of the embodiments disclosed herein. This application is intended to cover any variations, uses, or adaptations of this application that follow the general principles of this application and include common knowledge or customary techniques in the art not disclosed herein. It should be understood that this application is not limited to the precise structures described above and shown in the accompanying drawings, and various modifications and changes can be made without departing from its scope. The scope of this application is limited only by the appended claims.

Claims

1. A method for verifying unauthorized access, characterized in that, The method includes: In response to a user's business access request, obtain the user's identity information and the request parameters of the business access request; Based on the request parameters, the target business interface corresponding to the business access request and the unauthorized access annotation associated with the target business interface are determined. The unauthorized access annotation includes vertical unauthorized access annotation and horizontal unauthorized access annotation. Based on the above unauthorized access annotation, the unauthorized access verification logic for the business access request is determined from the pre-configured aspect layer, and the unauthorized access request is verified by the above unauthorized access verification logic. The step of determining the unauthorized access request verification logic from the pre-configured aspect layer based on the unauthorized access annotation includes: determining the vertical unauthorized access request verification logic from the pre-configured aspect layer based on the vertical unauthorized access annotation, wherein the aspect layer includes only one type of vertical unauthorized access verification logic, which is used to perform vertical unauthorized access verification on business access requests initiated by different users for the same business, or on business access requests initiated by the same user for different businesses; if the business access request passes the vertical unauthorized access verification of the vertical unauthorized access verification logic, then determining the horizontal unauthorized access request verification logic from the pre-configured aspect layer based on the horizontal unauthorized access annotation.

2. The method according to claim 1, characterized in that, The vertical privilege escalation verification logic is used to verify whether the user's identity information has access rights to the target business interface.

3. The method according to claim 1, characterized in that, The step of determining the lateral privilege escalation verification logic for the business access request from the pre-configured aspect layer based on the lateral privilege escalation annotation includes: The method name and parameter list of the target business interface are determined based on the horizontal overriding annotation; Based on the method name and the parameter list, the lateral privilege escalation logic for the service access request is determined from the pre-configured aspect layer.

4. The method according to claim 1, characterized in that, Before obtaining the user's identity information and the request parameters of the service access request, the method further includes: Obtain a pre-configured unauthorized access verification logic package, wherein the unauthorized access verification logic package includes unauthorized access verification logic corresponding to multiple business interfaces; Select and adjust the unauthorized access verification logic corresponding to the target business interface from the unauthorized access verification logic package; Configure an associated privilege escalation annotation for the target business interface to associate the privilege escalation annotation with the privilege escalation verification logic corresponding to the target business interface.

5. The method according to claim 1, characterized in that, The method further includes: If no unauthorized annotation is found associated with the target business interface, then the unauthorized verification logic for the business access request is determined based on the verification logic interface of the target business interface, and the unauthorized verification logic is used to perform unauthorized verification on the business access request.

6. The method according to claim 1, characterized in that, After performing unauthorized access verification on the service access request based on the unauthorized access verification logic, the method further includes: If the service access request passes the privilege escalation check, then the target service corresponding to the target service interface is executed; If the service access request fails the unauthorized access verification, a prompt message is sent to the user, which indicates that the user does not have access rights to the target service.

7. An overreach verification device, characterized in that, The device includes: The response unit is used to respond to a user's business access request by obtaining the user's identity information and the request parameters of the business access request. The determining unit is used to determine, based on the request parameters, the target business interface corresponding to the business access request, and the unauthorized annotation associated with the target business interface, wherein the unauthorized annotation includes vertical unauthorized annotation and horizontal unauthorized annotation; The verification unit is configured to determine the unauthorized access request verification logic for the service access request from a pre-configured aspect layer based on the unauthorized access annotation, and to perform unauthorized access verification on the service access request through the unauthorized access verification logic. The determination of the unauthorized access request verification logic from the pre-configured aspect layer based on the unauthorized access annotation includes: determining the vertical unauthorized access request verification logic from the pre-configured aspect layer based on the vertical unauthorized access annotation, wherein the aspect layer includes only one type of vertical unauthorized access verification logic. This vertical unauthorized access verification logic is used to perform vertical unauthorized access verification on service access requests initiated by different users for the same service, or on service access requests initiated by the same user for different services. If the service access request passes the vertical unauthorized access verification of the vertical unauthorized access verification logic, then the horizontal unauthorized access request verification logic is determined from the pre-configured aspect layer based on the horizontal unauthorized access annotation.

8. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores at least one piece of program code, which is loaded and executed by a processor to perform the operations performed by the method as described in any one of claims 1 to 6.

9. An electronic device, characterized in that, The method includes one or more processors and one or more memories, wherein at least one piece of program code is stored in the one or more memories, and the at least one piece of program code is loaded and executed by the one or more processors to implement the method as claimed in any one of claims 1 to 6.

Images