Background menu permission security detection method and system

Abstract

The invention relates to a background menu authority security detection method and system, and the method comprises the steps: enabling a user to log in a background management platform, encrypting a login user name through a private key after the background management platform passes the verification, and storing the encrypted information in a cookie of a root domain name; the background subsystem integrates unified verification middleware SDK to perform login verification; 3, the user permission is verified, and if the user permission does not exist, the middleware SDK adds a permission-free identifier in a return header; and 4, the background management platform regularly traverses all configured menu data, checks whether a return header contains a non-login identifier and a non-permission identifier, and carries out early warning according to a check result. The invention provides the background menu permission security detection method and system, whether a subsystem is accessed to the background management system according to a specification can be detected, and the security of the background menu permission is ensured. And the data security of the enterprise is ensured.

Description

Technical Field

[0001] The present invention relates to the technical field of data security, and in particular to a method and system for detecting the security of background menu permissions. Background Art

[0002] In an enterprise, a series of background data query pages need to be developed due to various business needs. For example, the marketing team needs to view the mall order data, and the operation team needs to understand the login status of game users. These different data query pages are developed by various departments and configured on the menu of the company's general background management platform. Each department's data query page is connected to the general background management platform as a subsystem and must comply with unified permission verification specifications. However, during the implementation process, it was found that some subsystems failed to fully access permission verification in order to catch up with the progress or save time, resulting in the data query page being accessed by unauthorized persons, which posed a major hidden danger to the company's data security. Summary of the invention

[0003] In order to overcome the problem in the existing backend management system that the security of subsystem access cannot be guaranteed during the process of subsystem access to the backend management system, which poses a security risk, the purpose of the present invention is to provide a method and system for backend menu permission security detection, which can detect whether the subsystem is connected to the backend management system according to the specifications, thereby ensuring the data security of the enterprise.

[0004] The present invention is implemented by the following scheme:

[0005] A method for background menu permission security detection, the method steps are as follows:

[0006] Step 1: The user logs in to the backend management platform. After verification, the backend management platform uses the private key to encrypt the login username and stores the encrypted information in the cookie of the root domain name;

[0007] Step 2: The subsystem of the backend management platform integrates the unified verification middleware SDK. When the user visits the subsystem page, the middleware SDK obtains the login cookie and uses the key to decrypt to obtain the user's login account. If the decryption result is empty, the middleware SDK adds a non-logged in mark in the return header;

[0008] Step 3: The middleware SDK obtains the address of the subsystem page being accessed, and transmits the subsystem page address and the user login account to the verification interface of the backend management platform. After receiving the verification request, the backend management platform searches for the menu corresponding to the configured subsystem page address, and verifies whether the role corresponding to the user has access rights. If the user has access rights, the middleware SDK allows the user to access and display the content of the subsystem page address; if the user does not have permission, the middleware SDK adds an unauthorized flag in the return header;

[0009] Step 4: The backend management platform regularly traverses all configured menu data, checks whether the return header contains a non-logged in mark and an unauthorized mark, and issues an early warning based on the inspection results.

[0010] Furthermore, the encryption described in step 1 includes DES symmetric encryption.

[0011] Furthermore, the menu corresponding to the configured subsystem page address is searched in step 3, and it is verified whether the role corresponding to the user has access rights. Specifically, after the background management platform receives the verification request, it first searches the menu resource table for whether the subsystem page address and its menu number exist. If so, it searches the permission table for whether the user has the permission for the menu number through the menu number.

[0012] Furthermore, step 4 is further specified as follows: requesting a menu check, checking whether the returned header contains an unlogged-in flag, and if not found, marking the menu as a risky menu and issuing an early warning;

[0013] If there is a non-logged-in flag, a login cookie without the menu permission is generated, and the menu check is requested with the cookie. If the return header contains the unauthorized flag, the menu is marked as a risky menu and an early warning is issued;

[0014] If there is no unlogged-in flag or no-authorization flag in the return header, a login cookie with the menu permission is generated, and the menu check is requested with the cookie. If any of the flags exists in the return header, the menu is marked as a risky menu and a warning is issued for the risky menu; if there is no flag in the return header, it means it is safe.

[0015] A system for background menu authority security detection, the system comprising: an encryption module, a login verification module, an authority verification module, and a sub-verification module;

[0016] The encryption module is used for users to log in to the backend management platform. After the backend management platform passes the verification, it uses the private key to encrypt the login username and stores the encrypted information in the cookie of the root domain name;

[0017] The login verification module is used to integrate the unified verification middleware SDK in the background subsystem. When the user visits the subsystem page, the middleware SDK obtains the login cookie and uses the key to decrypt to obtain the user login account. If the decryption result is empty, the middleware SDK adds a non-logged in mark in the return header;

[0018] The permission verification module is used to use the middleware SDK to obtain the address of the subsystem page being accessed, and transmit the subsystem page address and the user login account to the verification interface of the background management platform. After receiving the verification request, the background management platform searches for the menu corresponding to the configured subsystem page address, and verifies whether the role corresponding to the user has access rights. If the user has access rights, the middleware SDK allows the user to access and display the content of the subsystem page address; if the user does not have permission, the middleware SDK adds an unauthorized identifier in the return header;

[0019] The sub-verification module is used to regularly traverse all configured menu data on the background management platform, check whether the return header contains a non-logged in mark and an unauthorized mark, and issue an early warning based on the check result.

[0020] Furthermore, the encryption is RSA asymmetric encryption or DES symmetric encryption.

[0021] Furthermore, the permission verification module searches for the menu corresponding to the configured subsystem page address and verifies whether the role corresponding to the user has access rights. Specifically, after receiving the verification request, the background management platform first searches the menu resource table for the subsystem page address and its menu number. If so, the menu number is used to search the permission table for whether the user has the permission for the menu number.

[0022] Furthermore, the sub-verification module is further specified as follows: requesting a menu check, checking whether the returned header contains a non-logged-in mark, and if not found, marking the menu as a risky menu and issuing a warning;

[0023] If there is a non-logged-in flag, a login cookie without the menu permission is generated, and the menu check is requested with the cookie. If the return header contains the unauthorized flag, the menu is marked as a risky menu and an early warning is issued;

[0024] If there is no unlogged-in flag or no-authorization flag in the return header, a login cookie with the menu permission is generated, and the menu check is requested with the cookie. If any of the flags exists in the return header, the menu is marked as a risky menu and a warning is issued for the risky menu; if there is no flag in the return header, it means it is safe.

[0025] The beneficial effects of the present invention are:

[0026] The present invention provides a method and system for background menu permission security detection. By integrating a middleware SDK with a background subsystem, the middleware SDK can verify the login status and permissions of the current user, and add a corresponding non-logged-in mark and no-authority mark in a return header according to the verification result. According to the result of the return header, it can be detected whether the subsystem is connected to a unified permission authentication system according to specifications, thereby ensuring the data security of the enterprise. BRIEF DESCRIPTION OF THE DRAWINGS

[0027] Figure 1 is a flow chart of the method of the present invention;

[0028] Figure 2 It is a structural block diagram of the system of the present invention. DETAILED DESCRIPTION

[0029] The present invention will be further described below in conjunction with the accompanying drawings.

[0030] See also Figure 1 , a method for background menu permission security detection, the method steps are as follows:

[0031] Step 1: The user logs in to the backend management platform. After verification, the backend management platform uses the private key to encrypt the login username and stores the encrypted information in the cookie of the root domain name;

[0032] Step 2: The backend subsystem integrates the unified verification middleware SDK. When the user visits the subsystem page, the middleware SDK obtains the login cookie and uses the key to decrypt it to obtain the user's login account. If the decryption result is empty, the middleware SDK adds a non-logged in mark in the return header;

[0033] Step 3: The middleware SDK obtains the address of the subsystem page being accessed, and transmits the subsystem page address and the user login account to the verification interface of the backend management platform. After receiving the verification request, the backend management platform searches for the menu corresponding to the configured subsystem page address, and verifies whether the role corresponding to the user has access rights. If the user has access rights, the middleware SDK allows the user to access and display the content of the subsystem page address; if the user does not have permission, the middleware SDK adds an unauthorized flag in the return header;

[0034] Step 4: The backend management platform regularly traverses all configured menu data, checks whether the return header contains a non-logged in mark and an unauthorized mark, and issues an early warning based on the inspection results.

[0035] The present invention will be further described below in conjunction with a specific embodiment:

[0036] A method for background menu permission security detection, the method comprising the following steps:

[0037] Step 1: The user logs in to the backend management platform. After verification, the backend management platform uses the key to perform DES symmetric encryption on the login username and stores the encrypted information in the cookie of the root domain name.

[0038] User yewei logs in to the backend management platform manage.mydomain.com. The system first verifies whether the user's account and password are correct. If not, it returns a login failure. If the verification is successful, the system will use the symmetric encryption key 12345678 to perform DES symmetric encryption on the user's login username yewei. The encrypted information is U2FsdGVkX18+WgWeDpEvWAClWzu / e1yJ. Then, the system stores this encrypted information in a cookie named login_name under the root domain name .mydomain.com.

[0039] Step 2: The backend subsystem integrates the unified verification middleware SDK. When the user visits the subsystem page, the middleware SDK obtains the login cookie and uses the RSA public key to decrypt the cookie to obtain the user's login account. If the decryption result is empty, the middleware SDK adds a non-logged in flag in the return header.

[0040] When user yewei visits the mall order query page https: / / shop.mydomain.com / manage / order, the backend subsystem integrates the unified verification middleware SDK encapsulated by the general management system. Since the subsystem is a second-level domain name of the .mydomain.com root domain name, cookies can be exchanged.

[0041] The middleware SDK first obtains a value named login_name from the cookie, whose value is U2FsdGVkX18+WgWeDpEvWAClWzu / e1yJ.

[0042] The middleware SDK uses the key 123456 of the backend management platform to decrypt login_name to obtain the login user name yewei. If the cookie cannot be obtained or the decryption fails, it means that the user is not logged in. In this case, the middleware SDK will add a non-logged in flag in the returned header, such as head['flag'] = 'unlogin'.

[0043] Step 3. The middleware SDK obtains the address of the subsystem page being accessed, and transmits the subsystem page address and the user login account to the verification interface of the background management platform. After the background management platform receives the verification request, it first searches the menu resource table for the subsystem page address and its menu number. If so, it searches the permission table for the user with the menu number. If the user does not have permission, the middleware SDK adds an unauthorized flag in the return header.

[0044] The middleware SDK obtains the subsystem page address accessed by the user as https: / / shop.mydomain.com / manage / order, and transmits the page address and the user login account to the verification interface of the backend management platform: https: / / manage.mydoman.com / sdk / api / auth?user=yewei&resource=https: / / shop.mydo main.com / manage / order&sign=X4Z160uwHLZJiYQzwZQrdXxIikKkGFOU.

[0045] After receiving the verification request, the backend management platform first searches the menu resource table for a menu number that is configured with the page address https: / / shop.mydomain.com / manage / order. If so, the menu number is used to search the permission table to see if the user yewei has the permission for the menu number. If the user has the permission, the authentication is successful, and the middleware SDK allows the user to access and display the content of https: / / shop.mydomain.com / manage / order. If the menu number does not exist or the user does not have the permission for the corresponding menu number, the middleware SDK adds an unauthorized flag to the returned header, such as head['flag'] = 'unauth'.

[0046] Step 4. The background management platform regularly traverses all configured menu data, requests menu inspection, and checks whether the return header contains a non-logged in mark. If not found, the menu is marked as a risky menu and a warning is issued; if there is a non-logged in mark, a login cookie without the menu permission is generated, and the menu inspection is requested with the cookie. If the return header contains an unauthorized mark, the menu is marked as a risky menu and a warning is issued; if the return header does not contain a non-logged in mark and an unauthorized mark, a login cookie with the menu permission is generated, and the menu inspection is requested with the cookie. If any mark exists in the return header, the menu is marked as a risky menu and a warning is issued for the risky menu; if there is no mark in the return header, it means it is safe.

[0047] Steps 1 to 3 describe how the subsystem performs resource authentication to ensure security when the unified verification middleware SDK encapsulated by the general management system is integrated. Step 4 simulates the three situations of not logging in, logging in but without permission, and logging in with permission to make requests, and can determine whether the SDK is used.

[0048] The backend management platform will traverse all the menu data configured on the menu table every 10 minutes. First, the menu address is directly requested without any cookies. Since the current request is in the unlogged state, the middleware SDK will return the unlogged flag, so check whether the returned header contains the unlogged flag head['flag'] = 'unlogin'. If the unlogged flag is not returned, the menu will be marked as a risky menu.

[0049] If there is a non-logged-in flag, then generate a login cookie without the menu permission, such as the RSA asymmetric encrypted cookie of user yewei2, and bring the cookie to request the menu address. Since the cookie is in the logged-in state, the middleware SDK will request the menu permission verification interface. Since there is no permission, the middleware SDK will return the unauthorized flag, so check whether the returned header contains the unauthorized flag head['flag'] = 'unauth'. If the unauthorized flag is not returned, the menu is marked as a risky menu.

[0050] If there is an unauthorized identifier, the final verification step is performed to generate a login cookie with the menu permission. For example, a login cookie for user yewei is generated, and the menu check is requested with the cookie. Since user yewei has the menu permission, the middleware SDK will pass the verification and return the specific menu page to the user. Therefore, if there is any head['flag'] identifier in the return header, the menu will be marked as a risky menu; an early warning will be issued for the risky menu, and the relevant departments will be notified to make rectifications.

[0051] See also Figure 2 , a system for background menu permission security detection, the system comprising: an encryption module, a login verification module, a permission verification module, and a sub-verification module;

[0052] The encryption module is used for users to log in to the backend management platform. After the backend management platform passes the verification, it uses the private key to encrypt the login username and stores the encrypted information in the cookie of the root domain name;

[0053] The login verification module is used to integrate the unified verification middleware SDK in the background subsystem. When the user visits the subsystem page, the middleware SDK obtains the login cookie and uses the key to decrypt to obtain the user login account. If the decryption result is empty, the middleware SDK adds a non-logged in mark in the return header;

[0054] The permission verification module is used to use the middleware SDK to obtain the address of the subsystem page being accessed, and transmit the subsystem page address and the user login account to the verification interface of the background management platform. After receiving the verification request, the background management platform searches for the menu corresponding to the configured subsystem page address, and verifies whether the role corresponding to the user has access rights. If the user has access rights, the middleware SDK allows the user to access and display the content of the subsystem page address; if the user does not have permission, the middleware SDK adds an unauthorized identifier in the return header;

[0055] The sub-verification module is used to regularly traverse all configured menu data on the background management platform, check whether the return header contains a non-logged in mark and an unauthorized mark, and issue an early warning based on the check result.

[0056] In one embodiment of the present invention, the encryption is RSA asymmetric encryption or DES symmetric encryption.

[0057] In one embodiment of the present invention, the permission verification module searches for the menu corresponding to the configured subsystem page address and verifies whether the role corresponding to the user has access rights. Specifically, after the background management platform receives the verification request, it first searches the menu resource table for the subsystem page address and its menu number. If so, it searches the permission table for the user through the menu number to see whether he has the permission for the menu number.

[0058] In one embodiment of the present invention, the sub-verification module is further specifically configured to: request a menu check, check whether a non-logged-in mark is included in the returned header, and if not found, mark the menu as a risky menu and issue an early warning;

[0059] If there is a non-logged-in flag, a login cookie without the menu permission is generated, and the menu check is requested with the cookie. If the return header contains the unauthorized flag, the menu is marked as a risky menu and an early warning is issued;

[0060] If there is no unlogged-in flag or no-authorization flag in the return header, a login cookie with the menu permission is generated, and the menu check is requested with the cookie. If any of the flags exists in the return header, the menu is marked as a risky menu and a warning is issued for the risky menu; if there is no flag in the return header, it means it is safe.

[0061] In one embodiment of the present invention, the returned header is: the returned request header head['flag'].

[0062] The above description is only a preferred embodiment of the present invention. All equivalent changes and modifications made according to the scope of the patent application of the present invention should fall within the scope of the present invention.

Claims

1. A method for background menu permission security detection, characterized in that: The method steps are as follows: Step 1: The user logs in to the backend management platform. After verification, the backend management platform uses the private key to encrypt the login username and stores the encrypted information in the cookie of the root domain name; Step 2: The subsystem of the backend management platform integrates the unified verification middleware SDK. When the user visits the subsystem page, the middleware SDK obtains the login cookie and uses the key to decrypt to obtain the user's login account. If the decryption result is empty, the middleware SDK adds a non-logged in mark in the return header; Step 3: The middleware SDK obtains the address of the subsystem page being accessed, and transmits the subsystem page address and the user login account to the verification interface of the backend management platform. After receiving the verification request, the backend management platform searches for the menu corresponding to the configured subsystem page address and verifies whether the role corresponding to the user has access rights. If the user has access rights, the middleware SDK allows the user to access and display the content of the subsystem page address; If there is no permission, the middleware SDK adds an unauthorized flag in the return header; Step 4: The backend management platform regularly traverses all configured menu data, checks whether the return header contains a non-logged in mark and an unauthorized mark, and issues an early warning based on the inspection results.

2. A method for background menu permission security detection according to claim 1, characterized in that: The encryption described in step 1 is RSA asymmetric encryption or DES symmetric encryption.

3. A method for background menu permission security detection according to claim 1, characterized in that: The menu corresponding to the configured subsystem page address is searched in step 3, and it is verified whether the role corresponding to the user has access rights. Specifically, after receiving the verification request, the background management platform first searches the menu resource table for the subsystem page address and its menu number. If so, the menu number is used to search the permission table for whether the user has the permission for the menu number.

4. A method for background menu permission security detection according to claim 1, characterized in that: Step 4 is further specified as follows: the backend management platform periodically requests menu checks, directly requests the menu address without any cookies, and checks whether the returned header contains a non-logged-in mark. If not found, the menu is marked as a risky menu and an early warning is issued; If there is a non-logged-in flag, a login cookie without the menu permission is generated, and the menu check is requested with the cookie. If the return header contains the unauthorized flag, the menu is marked as a risky menu and an early warning is issued; If the returned header does not contain the unlogged-in flag or the unauthorized flag, a login cookie with the menu permission is generated and the menu check is requested with the cookie. If any of the flags is present in the returned header, the menu is marked as a risky menu and an early warning is issued for the risky menu. If there is no identifier in the returned header, it means it is safe.

5. A system for background menu permission security detection, characterized in that: The system includes: an encryption module, a login verification module, an authority verification module, and a sub-verification module; The encryption module is used for users to log in to the backend management platform. After the backend management platform passes the verification, it uses the private key to encrypt the login username and stores the encrypted information in the cookie of the root domain name; The login verification module is used to integrate the unified verification middleware SDK in the background subsystem. When the user visits the subsystem page, the middleware SDK obtains the login cookie and uses the key to decrypt to obtain the user login account. If the decryption result is empty, the middleware SDK adds a non-logged in mark in the return header; The permission verification module is used to use the middleware SDK to obtain the address of the subsystem page being accessed, and transmit the subsystem page address and the user login account to the verification interface of the background management platform. After receiving the verification request, the background management platform searches for the menu corresponding to the configured subsystem page address, and verifies whether the role corresponding to the user has access rights. If the user has access rights, the middleware SDK allows the user to access and display the content of the subsystem page address; if the user does not have permission, the middleware SDK adds an unauthorized identifier in the return header; The sub-verification module is used to regularly traverse all configured menu data on the background management platform, check whether the return header contains a non-logged in mark and an unauthorized mark, and issue an early warning based on the check result.

6. A system for background menu authority security detection according to claim 5, characterized in that: The encryption is RSA asymmetric encryption or DES symmetric encryption.

7. A system for detecting the security of background menu permissions according to claim 5, characterized in that: The permission verification module searches for the menu corresponding to the configured subsystem page address and verifies whether the role corresponding to the user has access rights. Specifically, after receiving the verification request, the background management platform first searches the menu resource table for the subsystem page address and its menu number. If so, the menu number is used to search the permission table for whether the user has the permission for the menu number.

8. A system for background menu authority security detection according to claim 5, characterized in that: The sub-verification module is further specified as follows: requesting a menu check, checking whether the returned header contains a non-logged-in mark, and if not found, marking the menu as a risky menu and issuing an early warning; If there is a non-logged-in flag, a login cookie without the menu permission is generated, and the menu check is requested with the cookie. If the return header contains the unauthorized flag, the menu is marked as a risky menu and an early warning is issued; If the returned header does not contain the unlogged-in flag or the unauthorized flag, a login cookie with the menu permission is generated and the menu check is requested with the cookie. If any of the flags is present in the returned header, the menu is marked as a risky menu and an early warning is issued for the risky menu. If there is no identifier in the returned header, it means it is safe.

Images