Vertical unauthorized protection method based on RBAC model
By using custom annotations to specify menu associations on classes and methods in a web system, the complexity and high maintenance cost of traditional vertical privilege escalation protection methods are solved, achieving flexible, simple, and universal vertical privilege escalation protection and ensuring system security.
Patent Information
- Application Number
- CN202511542130.2
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2025-10-27
- Publication Date
- 2026-01-30
AI Technical Summary
Existing vertical overriding protection methods are complex to configure, difficult to operate, costly to maintain, and inflexible, making it difficult to adapt to dynamic changes in system functions.
Custom annotations can be used to specify menu associations on classes and methods in a web system, enabling vertical privilege escalation protection, simplifying configuration and reducing maintenance costs.
It eliminates the need to configure API mapping relationships and interface whitelists, allowing for flexible responses to changes in system interfaces and functions, improving development efficiency and enhancing system security.
Smart Images
Figure CN121435205A_ABST
Abstract
Description
Technical Field
[0001] This invention belongs to the field of data security, and in particular relates to a vertical privilege escalation protection method based on the RBAC model. Background Technology
[0002] Web-based systems, powered by internet technology, are increasingly widely used, with many enterprises employing them for data management and visualization analysis. Within these systems, RBAC (Role-Based Access Control) is a common access control model. It assigns different roles to users, granting them varying permissions and distinguishing the functions and resources each role can access, thus achieving access control. However, without effective vertical protection against unauthorized access, users can access functions and resources they do not have permission to access, jeopardizing system security.
[0003] Therefore, as system functions become increasingly diversified, it is essential to implement effective vertical privilege escalation protection, which can effectively safeguard data security and enhance system security.
[0004] However, traditional methods for preventing vertical privilege escalation are quite cumbersome and have the following drawbacks:
[0005] 1. API mapping relationships need to be pre-configured. If there is a many-to-many relationship between APIs and function menus, the configuration will become very complicated, and it is easy to miss or misconfigure, affecting the accuracy of vertical overriding verification.
[0006] 2. Interface whitelist configuration and function item configuration are required. As the number of system interfaces and functions increases, the configuration will become more and more complex and the maintenance cost will be high.
[0007] 3. Adding or removing interfaces or function menus requires readjusting the configuration, which is cumbersome and inflexible. The system's function menus typically expand and contract dynamically during operation; some historical functions may be discontinued, while new functions are constantly being added. System interfaces also dynamically increase or decrease. If configuration rules need to be readjusted every time system function menus or interfaces are added or removed to achieve vertical privilege escalation protection, it will significantly increase maintenance difficulty.
[0008] In summary, existing traditional vertical privilege escalation protection methods suffer from problems such as complex configuration rules, high operational difficulty, poor versatility, and difficult and costly maintenance. Developing a universal, flexible, and effective vertical privilege escalation protection method is one of the technical problems that needs to be solved. Summary of the Invention
[0009] In view of the shortcomings of the existing technology, the purpose of the invention is to provide a vertical privilege escalation protection method based on the RBAC model, which can simplify and generalize vertical privilege escalation protection through custom annotations, effectively reducing development workload and later maintenance costs.
[0010] This invention proposes a vertical overriding protection method based on the RBAC model, comprising:
[0011] S1, Define custom annotations for classes and methods of the WEB system, wherein the class includes at least one method, and the custom annotation includes the attribute menu, which is used to specify a unique identifier for one or more corresponding menus;
[0012] S2, when a class or method uses the custom annotation, it indicates that all interfaces of the class or the interface of the method are associated with the menu specified by the attribute value of the menu; when a user has permission to access any menu in the specified menu, it is determined that the user has permission to access the corresponding interface; otherwise, it is determined to be a vertical privilege escalation and is intercepted.
[0013] S3, Perform vertical privilege escalation protection verification, including: receiving the user's interface request, obtaining the list of menus the user has permission to access and the list of menus specified in the custom annotation, and performing vertical privilege escalation protection verification by determining whether the list of menus the user has permission to access contains any menu from the list of menus specified in the custom annotation.
[0014] If the user's list of all accessible menus includes any menu from the menu list specified in the custom annotation, then the user is deemed to have permission to access the corresponding interface, the verification passes, and the interface request is allowed; otherwise, a vertical privilege escalation is detected, and the interface request is blocked.
[0015] Furthermore, the attribute menu corresponds to multiple menu combinations, each menu combination corresponds to a different interface, wherein each menu combination includes one or more menus.
[0016] Furthermore, in S2, when the custom annotation is used only on a class, it means that all interfaces of the class are associated with the menu specified by the attribute value of the menu. When the user has permission to access any menu item in the specified menu, it is determined that the user has permission to access all interfaces contained in the class; otherwise, it is determined to be a vertical privilege escalation and is intercepted.
[0017] Furthermore, in S2, when the custom annotation is used on a method, it indicates that the interface is associated with the menu specified by the attribute value of the `menu` attribute. If the user has permission to access any menu item in the specified menu, it is determined that the user has permission to access the interface; otherwise, it is determined to be a vertical privilege escalation and is intercepted.
[0018] Furthermore, in S2, when the custom annotation is used on both a method and the class to which the method belongs, it indicates that the specific interface of the class is associated with the set of menus specified by the attribute value of the class's attribute menu and the attribute value of the interface's attribute menu. When the user has permission for any menu in the set of menus, it is determined that the user has permission to access the interface; otherwise, it is determined to be a vertical privilege escalation and is intercepted.
[0019] Furthermore, in S3, protection checks for vertical overriding are performed, including:
[0020] S31, The server receives the user's interface request;
[0021] S32, determine if the user is logged in. If logged in, obtain the user information; otherwise, determine that the user does not have permission to access.
[0022] S33, Obtain a list of all menus that the user has permission to access based on the user information;
[0023] S34. Based on the interface request, determine whether the requested interface uses a custom annotation. If the interface uses a custom annotation, obtain the attribute value of the custom annotation used on the interface, and further obtain the menu list corresponding to the interface.
[0024] S35. Based on the interface request, determine whether the class to which the requested interface belongs uses a custom annotation. If the class to which the interface belongs uses a custom annotation, obtain the attribute value of the custom annotation's "menu" attribute on the class, and further obtain the corresponding menu list for the class.
[0025] S36, merge the menu list corresponding to the interface and the menu list corresponding to the class to obtain a menu list set;
[0026] S37. Determine whether the user's list of all authorized menus contains any menu from the menu list collection. If so, determine whether the user has permission to access the corresponding interface. If the verification passes, allow the interface request.
[0027] Furthermore, in S33, based on the logged-in user information, the current user's role is first obtained, and then the list of all menus that the user has permission to access is obtained based on the role.
[0028] Furthermore, in S34, after obtaining the attribute value of the menu attribute of the custom annotation used on the request interface, the attribute value is separated by commas to obtain the corresponding menu list.
[0029] Furthermore, in S34 and S35, if the interface or class does not use a custom annotation, an empty menu list is returned.
[0030] Furthermore, in S37, if it is determined that the user's authorized menu list does not contain any menu from the menu list set, then a vertical privilege escalation has occurred, and the interface request is intercepted.
[0031] The beneficial effects of this invention are as follows:
[0032] 1. This invention eliminates the need to configure API mapping relationships and optimizes the vertical privilege escalation protection mechanism;
[0033] 2. This invention requires no context setting, no interface whitelist configuration, and no function item configuration. It achieves effective vertical privilege escalation protection through custom annotations, simplifying and generalizing the vertical privilege escalation protection mechanism.
[0034] 3. This invention ensures that the accuracy of vertical privilege escalation verification is not affected when system interfaces or function menus are added or removed. No configuration is required and the vertical privilege escalation protection mechanism will still be effective. The protection mechanism is more flexible and universal, effectively improving development efficiency and reducing maintenance costs.
[0035] 4. For web systems based on the RBAC model, this invention can achieve effective vertical privilege escalation protection without any configuration by using custom annotations, thus effectively protecting data security and enhancing system security.
[0036] 5. This invention solves the problems of complex configuration rules, high operation difficulty and high maintenance cost of existing vertical privilege escalation protection methods by using custom annotations, and simplifies and universalizes vertical privilege escalation protection, effectively reducing development workload and later maintenance costs. Attached Figure Description
[0037] The accompanying drawings are for illustrative purposes only and are not intended to limit the invention. Throughout the drawings, the same reference numerals denote the same parts. It is obvious that the drawings described below are merely some embodiments of the present invention, and those skilled in the art can obtain other drawings based on these drawings.
[0038] Figure 1 This is a flowchart of a vertical overriding protection method based on the RBAC model according to an embodiment of the present invention;
[0039] Figure 2 This is a schematic diagram of a vertical overriding protection method based on the RBAC model according to an embodiment of the present invention. Detailed Implementation
[0040] To enable those skilled in the art to better understand the technical solutions in the embodiments of the present invention, the technical solutions of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, not all embodiments. It should be understood that these descriptions are merely exemplary and are not intended to limit the scope of the present invention. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort should fall within the scope of protection of the present invention.
[0041] Furthermore, descriptions of well-known structures and techniques are omitted in the following description to avoid unnecessarily obscuring the concepts disclosed in this invention.
[0042] In the description of this invention, it should be noted that, unless otherwise explicitly specified and limited, the terms "center," "upper," "lower," "left," "right," "vertical," "horizontal," "inner," and "outer," etc., indicating orientation or positional relationships based on the orientation or positional relationships shown in the accompanying drawings, are only for the convenience of describing the invention and simplifying the description, and do not indicate or imply that the device or element referred to must have a specific orientation, or be constructed and operated in a specific orientation, and therefore should not be construed as a limitation of the invention. Furthermore, the terms "first," "second," and "third" are used for descriptive purposes only and should not be construed as indicating or implying relative importance. The terms "installed," "connected," and "linked" should be interpreted broadly; for example, they can refer to a fixed connection, a detachable connection, or an integral connection; they can refer to a mechanical connection or an electrical connection; they can refer to a direct connection or an indirect connection through an intermediate medium; and they can refer to the internal communication of two components. Those skilled in the art can understand the specific meaning of the above terms in this invention based on the specific circumstances.
[0043] Exemplary embodiments will now be described in detail, examples of which are illustrated in the accompanying drawings. When the following description relates to the drawings, unless otherwise indicated, the same numerals in different drawings denote the same or similar elements. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with the present invention. Rather, they are merely examples of methods and systems consistent with some aspects of the invention as detailed in the appended claims.
[0044] like Figure 1 and Figure 2 As shown, this invention proposes a vertical overriding protection method based on the RBAC model, comprising:
[0045] S1 allows you to define custom annotations for classes and methods in a web system.
[0046] Specifically, the relationship between classes and methods in a web system can be summarized as follows: methods are components of classes, and classes define their behavior through methods. A class can include at least one method, that is, one or more methods.
[0047] This step specifies a custom annotation that can be used on a class or a method, or both.
[0048] Custom annotations include the `menu` attribute, which is defined as a String. The `menu` attribute is used to uniquely identify one or more corresponding menus. When multiple menus are represented, the menu values are separated by commas.
[0049] In this invention, the `menu` attribute corresponds to multiple menu combinations, and each menu combination corresponds to a different interface. Each menu combination includes one or more menus.
[0050] For example, the attribute `menu` corresponds to menu combinations, including: menu combination 1 is "menu_1,menu_2"; menu combination 2 is "menu_1,menu_2,menu_3". The interfaces corresponding to "menu_1,menu_2" and "menu_1,menu_2,menu_3" are different.
[0051] Here is an example of a custom annotation, where ApiMenu is a custom annotation:
[0052] @Target({ElementType.METHOD,ElementType.TYPE})
[0053] @Retention(RetentionPolicy.RUNTIME)
[0054] public@interface ApiMenu{
[0055] String menu();
[0056] }
[0057] S2, when a class or method uses a custom annotation, it indicates that all interfaces of the class or the interface of the method are associated with the menu specified by the attribute value of the menu; when a user has permission to access any of the specified menus, it is determined that the user has permission to access the corresponding interface; otherwise, it is determined as a vertical privilege escalation and is intercepted.
[0058] Custom annotations are used on methods or classes according to usage specifications to bind the association between interfaces and menus.
[0059] First, the usage guidelines for custom annotations will be explained, including the following three aspects:
[0060] 1) When this custom annotation is used on a class, it means that all interfaces of the class are associated with the menu specified in the "menu" attribute value. Only when the user has permission to access any of these menus will they have permission to access the interfaces contained in the class; otherwise, it will be judged as a vertical privilege escalation and blocked.
[0061] 2) When this custom annotation is used on a method, it indicates that the interface is associated with the menu specified in the "menu" attribute value. Only when the user has permission to access any of these menus will they have permission to access the interface; otherwise, it will be judged as a vertical privilege overreach and blocked.
[0062] 3) When a method and the class to which the method belongs use the same custom annotation, it means that the interface is associated with the set of menus specified in the "menu" attribute value of the custom annotation used on the interface and the class. Only when the user has permission to access any menu in this set of menus will they have permission to access the interface; otherwise, it will be judged as a vertical privilege overreach and blocked.
[0063] The three usage methods mentioned above will be explained separately below:
[0064] 1. Custom annotations can only be used on classes.
[0065] When a custom annotation is used only on a class, it means that all interfaces of that class are associated with the menu specified by the value of the `menu` attribute. If the user has permission to access any menu item in the specified menu, it is determined that the user has permission to access all interfaces contained in that class; otherwise, it is determined as a vertical privilege escalation and is intercepted.
[0066] (1.1) The menu attribute specifies a single menu.
[0067] Specifically, if the `menu` attribute specifies a menu, it means that all interfaces of this class are associated with that menu. Users can only access the interfaces contained in this class when they have permission for that menu; otherwise, it will be judged as a vertical privilege escalation and blocked. An example of its usage is as follows:
[0068]
[0069]
[0070] Referring to Table 1, the above example indicates:
[0071] If a user has permission for the menu "menu_1", then that user has permission to access interfaces " / demo / api_1" and " / demo / api_2".
[0072] If a user does not have permission for the menu "menu_1", then the user has neither permission to access the interface " / demo / api_1" nor permission to access the interface " / demo / api_2".
[0073] Table 1 shows the menu-interface mapping for classes using annotations (single menu).
[0074]
[0075] (1.2) The menu attribute specifies multiple menus.
[0076] Specifically, if the `menu` attribute specifies multiple menus, it means that all interfaces of this class are associated with these multiple menus. Users with permission to any one of these menus can access the interfaces contained in this class; otherwise, it will be considered a vertical privilege escalation and blocked. An example of its usage is as follows:
[0077]
[0078]
[0079] Referring to Table 2, the above example indicates:
[0080] If a user has permission to access either menu "menu_1" or "menu_2", then that user has permission to access interfaces " / demo / api_1" and " / demo / api_2".
[0081] If a user has neither permission for menu "menu_1" nor permission for menu "menu_2", then the user has neither permission to access interface " / demo / api_1" nor permission to access interface " / demo / api_2".
[0082] Table 2 shows the menu-interface mapping for classes using annotations (multiple menus).
[0083]
[0084] 2. Custom annotations can only be used on methods.
[0085] When a custom annotation is used only on a method, it indicates that the interface is associated with the menu specified by the value of the `menu` attribute. If the user has permission to access any of the specified menu items, it is determined that the user has permission to access the interface; otherwise, it is determined as a vertical privilege escalation and is blocked.
[0086] (2.1) The menu attribute specifies a single menu.
[0087] Specifically, if the `menu` attribute specifies a menu, it means that the interface is associated with that menu. Users can only access the interface if they have permission for that menu; otherwise, it will be considered a vertical privilege escalation and blocked. An example of its usage is as follows:
[0088]
[0089] Referring to Table 3, the above example indicates:
[0090] If a user has permission for both menu "menu_1" and menu "menu_2", then the user has permission to access interfaces " / demo / api_1", " / demo / api_2", and " / demo / api_3".
[0091] If a user has permission for menu "menu_1" but not for menu "menu_2", then the user has permission to access interfaces " / demo / api_1" and " / demo / api_2", but not for interface " / demo / api_3".
[0092] If a user has permission for menu "menu_2" but not permission for menu "menu_1", then the user has permission to access interface " / demo / api_3", but not permission to access interfaces " / demo / api_1" and " / demo / api_2".
[0093] If a user has neither permission for menu "menu_1" nor permission for menu "menu_2", then the user does not have permission to access interfaces " / demo / api_1", " / demo / api_2", and " / demo / api_3".
[0094] Table 3 shows the menu-interface mapping for methods using annotations (single menu).
[0095]
[0096] (2.2) The menu attribute specifies multiple menus.
[0097] Specifically, if the `menu` attribute specifies multiple menus, it means that the interface is associated with these multiple menus. A user can access the interface if they have permission for any one of these menus; otherwise, it will be considered a vertical privilege escalation and blocked. An example of its usage is as follows:
[0098]
[0099] Referring to Table 4, the above example indicates:
[0100] If a user has permission to access either menu "menu_1" or "menu_2", then that user has permission to access interfaces " / demo / api_1", " / demo / api_2", and " / demo / api_3".
[0101] If a user does not have permission for menus “menu_1” and “menu_2”, but has permission for menu “menu_3”, then the user has permission to access interface “ / demo / api_3”, but not permission to access interfaces “ / demo / api_1” and “ / demo / api_2”.
[0102] If a user does not have permission to access any of the menus “menu_1”, “menu_2”, or “menu_3”, then the user does not have permission to access the interfaces “ / demo / api_1”, “ / demo / api_2”, and “ / demo / api_3”.
[0103] Table 4 shows the menu-interface mapping for methods using annotations (multiple menus).
[0104]
[0105] 3. Custom annotations can be used on both a method and the class to which that method belongs.
[0106] When a custom annotation is used on both a method and the class to which that method belongs, it indicates that the concrete interface of the class is associated with the set of menus specified by the values of the `menu` attribute on the class and the `menu` attribute on the interface. If the user has permission to access any menu item in the set, it is determined that the user has permission to access the interface; otherwise, it is considered a vertical privilege escalation and is blocked. An example of its usage is as follows:
[0107]
[0108] Referring to Table 5, the above example indicates:
[0109] If a user has permission to access any one of the menus “menu_1”, “menu_2”, and “menu_3”, then that user has permission to access the interface “ / demo / api_1”.
[0110] Table 5 shows the menu-interface mapping relationship when annotations are used on both methods and classes.
[0111]
[0112] S3 performs vertical privilege escalation protection verification, including: receiving the user's interface request, obtaining the list of menus the user has permission to access and the list of menus specified in the custom annotation, and performing vertical privilege escalation protection verification by determining whether the list of menus the user has permission to access contains any menu from the list of menus specified in the custom annotation.
[0113] If a user's authorized menu list contains any menu item specified in the custom annotation, then the user is deemed authorized to access the corresponding interface, the verification passes, and the interface request is allowed; otherwise, a vertical privilege escalation is detected, and the interface request is blocked.
[0114] S31, the server receives interface requests sent by the user from the client.
[0115] The API request contains the API information requested by the user.
[0116] S32 determines whether the user is logged in. If logged in, the user information is retrieved; otherwise, the user is deemed to lack access privileges.
[0117] S33 retrieves a list of all menus that the user has permission to access based on the user information.
[0118] Specifically, based on the logged-in user information, the system first obtains the current user's role, and then retrieves a list of all menus that the user has permission to access based on that role.
[0119] S34. Based on the interface request, determine whether the requested interface uses a custom annotation. If the interface uses a custom annotation, obtain the attribute value of the custom annotation used on the interface, and further obtain the menu list corresponding to the interface.
[0120] Specifically, based on the received user interface request, determine whether the corresponding request interface uses the custom annotation `@ApiMenu`. If the interface uses the custom annotation `@ApiMenu`, retrieve the value of the `menu` attribute of the `@ApiMenu` annotation used on the interface, and separate the attribute values with commas to obtain the menu list corresponding to the interface. If the interface does not use the custom annotation `@ApiMenu`, return an empty menu list.
[0121] For example, if the attribute values of menu include menu_1 and menu_2, the attribute values can be separated by commas into "menu_1,menu_2", thus representing two separate menus, menu_1 and menu_2.
[0122] S35. Based on the interface request, determine whether the class to which the requested interface belongs uses a custom annotation. If the class to which the interface belongs uses a custom annotation, obtain the attribute value of the custom annotation's "menu" attribute on the class, and further obtain the corresponding menu list for the class.
[0123] Specifically, based on the received user interface request, it determines whether the class to which the interface belongs uses a custom annotation. If the class uses the custom annotation `@ApiMenu`, it retrieves the value of the `menu` attribute of the `@ApiMenu` annotation on that class, and separates the attribute values with commas to obtain the menu list corresponding to that class. If the class does not use the custom annotation `@ApiMenu`, it returns an empty menu list.
[0124] S36. Merge the menu list corresponding to the interface in S34 and the menu list corresponding to the class in S35 to obtain a collection of menu lists that include the menu list specified in the attribute value of the custom annotation @ApiMenu used on the interface and class.
[0125] S37 checks whether the list of all menus that the user has permission to access in S33 contains any menu from the menu list set in S36. If it does, the user is deemed to have permission to access the corresponding interface. If the verification passes, the interface request is allowed.
[0126] If it is determined that the user's list of all authorized menus does not contain any menu from the menu list set, then a vertical privilege escalation has occurred, the API request is intercepted, and the user is denied access.
[0127] The vertical privilege escalation protection method based on the RBAC model of this invention can be applied to customer intelligent operation and maintenance platform R&D projects to effectively protect against vertical privilege escalation and ensure system security. This invention can be applied to various web systems, implementing a vertical privilege escalation protection mechanism through custom annotations. The protection mechanism is simple, flexible, and universal, effectively ensuring data security and enhancing system security.
[0128] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of the embodiments of the present invention, and are not intended to limit them. Although the present invention has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features; and these modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of the present invention. Any changes or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in the present invention should be included within the protection scope of the present invention.
Claims
1. A vertical privilege-escalation protection method based on an RBAC model, characterized in that, The method comprises the following steps: S1, a custom annotation is made for a class and a method of a WEB system, wherein the class comprises at least one method, the custom annotation comprises an attribute menu, and the attribute menu is used to specify the unique identification of one or more menus; S2, when the class or the method uses the custom annotation, all interfaces of the class or the interface of the method are associated with the menu specified by the attribute value of the attribute menu; when a user has the permission of any one of the specified menus, it is judged that the user has the permission to access the corresponding interface, otherwise, it is judged that the vertical overreach is intercepted; S3, the vertical overreach is protected and checked, comprising: receiving an interface request of a user, obtaining a menu list to which the user has the permission and a menu list specified in the custom annotation, and performing the vertical overreach protection and checking by judging whether the menu list to which the user has the permission contains any one of the menu list specified in the custom annotation, if all the menu list to which the user has the permission includes any one of the menu list specified in the custom annotation, it is judged that the user has the permission to access the corresponding interface, the checking is passed, and the interface request is released; otherwise, it is judged that the vertical overreach occurs, and the interface request is intercepted.
2. The vertical privilege protection method based on the RBAC model according to claim 1, characterized in that, The attribute menu corresponds to a plurality of menu combinations, and each menu combination corresponds to a different interface, wherein each menu combination comprises one or more menus.
3. The vertical privilege protection method based on the RBAC model according to claim 1, characterized in that, In S2, when the custom annotation is used only on the class, all interfaces of the class are associated with the menu specified by the attribute value of the attribute menu; when a user has the permission of any one of the specified menus, it is judged that the user has the permission to access all interfaces contained in the class; otherwise, it is judged that the vertical overreach is intercepted.
4. The vertical privilege protection method based on the RBAC model according to claim 1, characterized in that, In S2, when the custom annotation is used on the method, the interface is associated with the menu specified by the attribute value of the attribute menu; when a user has the permission of any one of the specified menus, it is judged that the user has the permission to access the interface; otherwise, it is judged that the vertical overreach is intercepted.
5. The vertical privilege protection method based on the RBAC model according to claim 1, characterized in that, In S2, when the custom annotation is used on the method and the class to which the method belongs, the specific interface of the class is associated with the menu set specified by the attribute value of the attribute menu on the class and the attribute value of the attribute menu on the interface; when a user has the permission of any one of the menu set, it is judged that the user has the permission to access the interface; otherwise, it is judged that the vertical overreach is intercepted.
6. The vertical privilege protection method based on the RBAC model according to claim 1, characterized in that, In S3, the vertical overreach is protected and checked, comprising: S31, the server receives an interface request of a user; S32, it is judged whether the user is logged in, if yes, the user information is obtained, otherwise, it is judged that the user has no permission to access; S33, all menu lists to which the user has the permission are obtained according to the user information; S34, it is judged whether the interface uses the custom annotation according to the interface request, if the interface uses the custom annotation, the attribute value of the attribute menu of the custom annotation used on the interface is obtained, and the menu list corresponding to the interface is further obtained; S35, according to the interface request, judge whether the class to which the interface belongs uses a custom annotation, if the class to which the interface belongs uses a custom annotation, get the attribute value of the attribute menu of the custom annotation on the class, and further get the menu list corresponding to the class; S36, combine the interface corresponding menu list and the class corresponding menu list to obtain a menu list collection; S37, judge whether all the menu lists to which the user has access right contain any one of the menu list collection, if yes, judge that the user has access right to access the corresponding interface, the verification is passed, and the interface request is released.
7. The RBAC model-based vertical privilege escalation prevention method of claim 6, wherein, In S33, according to the logged-in user information, first get the role to which the current user belongs, and then get all the menu lists to which the user has access right according to the role.
8. The RBAC model-based vertical privilege escalation prevention method of claim 6, wherein, In S34, after obtaining the attribute value of the attribute menu of the custom annotation used on the request interface, the attribute value is cut by comma to obtain the corresponding menu list.
9. The vertical privilege protection method based on the RBAC model according to claim 1, characterized in that, In S34 and S35, if the interface or the class does not use the custom annotation, return an empty menu list.
10. The vertical privilege protection method based on the RBAC model according to claim 1, characterized in that, In S37, when it is judged that all the menu lists to which the user has access right do not contain any one of the menu list collection, it is judged that vertical overreach occurs, and the interface request is intercepted.