A method and system for detecting background menu authority security

Abstract

The application relates to a background menu authority security detection method and system, and the method is as follows: a user logs in a background management platform, the background management platform is verified, a private key is used to encrypt a login username, and the encrypted information is stored in a cookie of a root domain name; a background subsystem integrates a unified verification middleware SDK to perform login verification; step 3: the authority of the user is verified, if there is no authority, the middleware SDK adds an authority-free identifier in a return header; step 4: the background management platform regularly traverses all configured menu data, checks whether the return header contains a login-free identifier and an authority-free identifier, and performs early warning according to the checking result; the application provides a background menu authority security detection method and system, can detect whether a subsystem is connected to a background management system according to a specification, and ensures the data security of an enterprise.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of data security, in particular to a method and system for detecting security of background menu authority. BACKGROUND

[0002] In an enterprise, a series of background data query pages need to be developed due to various business needs. For example, a marketing team needs to view mall order data, an operation team needs to understand the login situation of game users, etc. These different data query pages are developed by various departments and configured to the menu of the general background management platform of the company. The data query page of each department as a subsystem accesses the general background management platform and must comply with the unified authority verification specification. However, it is found in the execution process that some subsystems fail to completely access the authority verification in order to catch up with the schedule or save time, resulting in that the data query page may be accessed by unauthorized persons, which brings a major hidden danger to the data security of the company. SUMMARY

[0003] In order to overcome the problem that the security of the subsystem accessing the background management system cannot be guaranteed in the process of the subsystem accessing the background management system in the existing background management system, and the security is hidden, the purpose of the present application is to provide a method and system for detecting security of background menu authority, which can detect whether the subsystem accesses the background management system according to the specification and guarantee the data security of the enterprise.

[0004] The present application adopts the following scheme to realize:

[0005] A method for detecting security of background menu authority, the method steps are as follows:

[0006] Step 1: a user logs in the background management platform, and the background management platform stores the encrypted information in the cookie of the root domain name after verification by using the private key to encrypt the login username;

[0007] Step 2: the subsystem of the background management platform integrates the unified verification middleware SDK, and when the user accesses the subsystem page, the middleware SDK obtains the login cookie and uses the key to decrypt the user login account, and if the decryption result is empty, the middleware SDK adds the non-login identifier in the return header;

[0008] Step 3: the middleware SDK obtains the accessed subsystem page address and transmits the subsystem page address and the user login account to the verification interface of the background management platform, and the background management platform receives the verification request, finds the menu corresponding to the subsystem page address configured, and verifies whether the user corresponding role has access authority, if the user has access authority, the middleware SDK allows the user to access and display the content of the subsystem page address; if there is no authority, the middleware SDK adds the no authority identifier in the return header;

[0009] Step 4: The background management platform periodically traverses all configured menu data, checks whether the return header contains a non-logged-in identifier and a no permission identifier, and performs early warning according to the check result.

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

[0011] Further, the finding of the configured subsystem page address corresponding to the menu and the verification of whether the role corresponding to the user has access rights in step 3 are specifically: after the background management platform receives a verification request, it first finds whether the subsystem page address and its menu number exist in the menu resource table, and if they exist, it finds whether the user has the permission of the menu number in the permission table through the menu number.

[0012] Further, step 4 is further specifically: request menu check, check whether the return header contains a non-logged-in identifier, if not found, mark the menu as a risk menu and perform early warning;

[0013] If the non-logged-in identifier exists, a login cookie without the menu permission is generated, and the cookie is used to request menu check, if the return header contains the no permission identifier, the menu is marked as a risk menu and early warning is performed;

[0014] If the return header does not contain the non-logged-in identifier and the no permission identifier, a login cookie with the menu permission is generated, and the cookie is used to request menu check, if the return header contains any kind of identifier, the menu is marked as a risk menu and early warning is performed on the risk menu; if the return header does not contain the identifier, it means safety.

[0015] A system for detecting the security of background menu permissions, the system comprising: an encryption module, a login verification module, a permission verification module, and a sub-verification module;

[0016] The encryption module is used for user login on the background management platform, and the background management platform uses a private key to encrypt the login username after verification, and stores the encrypted information in the cookie of the root domain name;

[0017] The login verification module is used for integrating a unified verification middleware SDK in the background subsystem, when a user accesses a subsystem page, the middleware SDK obtains the login cookie and uses a secret key to decrypt the user login account, if the decryption result is empty, the middleware SDK adds a non-logged-in identifier in the return header;

[0018] The permission verification module is configured to acquire the accessed subsystem page address by using the middleware SDK, and transmit the subsystem page address and the user login account to a verification interface of the background management platform, the background management platform finds the menu corresponding to the configured subsystem page address after receiving the verification request, and verifies whether the role corresponding to the user has access permission, if the user has access permission, the middleware SDK allows the user to access and display the content of the subsystem page address, if the user has no permission, the middleware SDK adds no permission identifier in the return header;

[0019] The sub-verification module is configured to periodically traverse all configured menu data on the background management platform, check whether the return header contains the no login identifier and the no permission identifier, and perform early warning according to the checking result.

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

[0021] Further, the permission verification module is configured to find the menu corresponding to the configured subsystem page address, and verify whether the role corresponding to the user has access permission, specifically: after the background management platform receives the verification request, first, find whether the subsystem page address and the menu number exist in the menu resource table, if yes, find whether the user has the permission of the menu number in the permission table through the menu number.

[0022] Further, the sub-verification module is further specifically configured as follows: request menu check, check whether the return header contains the no login identifier, if not, mark the menu as a risk menu, and perform early warning;

[0023] If the no login identifier exists, generate a login cookie without the permission of the menu, and request menu check with the cookie, if the return header contains the no permission identifier, mark the menu as a risk menu, and perform early warning;

[0024] If the return header does not contain the no login identifier and the no permission identifier, generate a login cookie with the permission of the menu, and request menu check with the cookie, if the return header contains any identifier, mark the menu as a risk menu and perform early warning on the risk menu, if the return header does not contain the identifier, it means safety.

[0025] The application has the following advantages:

[0026] The application provides a method and system for detecting the security of background menu permissions, which integrates middleware SDK in a background subsystem, the middleware SDK can verify the login state and permissions of the current user, adds corresponding login identification and no permission identification in the return header according to the verification result, and can detect whether the subsystem accesses the unified permission authentication system according to the result of the return header, thereby ensuring the data security of enterprises. BRIEF DESCRIPTION OF DRAWINGS

[0027] Figure 1 A flowchart of the method of the application;

[0028] Figure 2 A structure block diagram of the system of the application. DETAILED DESCRIPTION

[0029] The application will be further described below in combination with the drawings.

[0030] Reference Figure 1 A method for detecting the security of background menu permissions, the method comprises the following steps:

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

[0032] Step 2: the background subsystem integrates the unified verification middleware SDK, when the user accesses the subsystem page, the middleware SDK obtains the login cookie and uses the key to decrypt the user login account, if the decryption result is empty, the middleware SDK adds the login identification in the return header;

[0033] Step 3: the middleware SDK obtains the accessed subsystem page address, and transmits the subsystem page address and the user login account to the verification interface of the background management platform, the background management platform receives the verification request, finds the menu corresponding to the subsystem page address, and verifies whether the role corresponding to the user has access permission, if the user has access permission, 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 the no permission identification in the return header;

[0034] Step 4: the background management platform periodically traverses all configured menu data, checks whether the login identification and the no permission identification are included in the return header, and performs early warning according to the checking result.

[0035] The application will be further described below in combination with a specific embodiment:

[0036] A method for detecting the security of background menu permissions, the method comprises the following steps:

[0037] Step 1, the user logs in to the background management platform, and the background management platform uses the key to encrypt the login username with DES symmetry after verification, and stores the encrypted information in the cookie of the root domain name.

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

[0039] Step 2, the background subsystem integrates the unified verification middleware SDK, and when the user accesses the subsystem page, the middleware SDK obtains the login cookie and uses the RSA public key to decrypt the user login account. If the decryption result is empty, the middleware SDK adds an unlogged identifier in the return header.

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

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

[0042] The middleware SDK decrypts login_name using the key 123456 of the background management platform to obtain the login username yewei. If the cookie cannot be obtained or the decryption fails, it indicates that the user is not logged in. In this case, the middleware SDK adds an unlogged identifier in the return header, such as head['flag'] = 'unlogin'.

[0043] Step 3, the middleware SDK obtains the accessed subsystem page address, and transmits 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 first searches the menu resource table to check whether the subsystem page address and the menu number exist. If they exist, the background management platform searches the permission table through the menu number to check whether the user has the permission of the menu number. If the user has no permission, the middleware SDK adds a no permission identifier in the return header.

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

[0045] After receiving the verification request, the background management platform first searches the menu resource table to check whether the menu number of the page address https: / / shop.mydomain.com / manage / order is configured. If the menu number exists, the background management platform searches the permission table through the menu number to check whether the user yewei has the permission of 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 has no permission of the corresponding menu number, the middleware SDK adds a no permission identifier in the return header, for example, head['flag']='unauth'.

[0046] Step 4, the background management platform periodically traverses all configured menu data, requests menu checking, checks whether the no login identifier is contained in the return header, if not found, marks the menu as a risk menu, and performs early warning; if the no login identifier exists, generates a login cookie without the permission of the menu, and requests menu checking with the cookie, if the return header contains the no permission identifier, marks the menu as a risk menu, and performs early warning; if the return header does not contain the no login identifier and the no permission identifier, generates a login cookie with the permission of the menu, and requests menu checking with the cookie, if the return header contains any identifier, marks the menu as a risk menu and performs early warning on the risk menu; if the return header does not contain the identifier, it means safety.

[0047] Steps 1 to 3 describe how the subsystem performs resource authentication to ensure security in the case of unified authentication middleware SDK integrated with the general management system package. Step 4 is to make a request by simulating three cases of not logged in, logged in but without permission, and logged in with permission, to determine whether the SDK is used.

[0048] The background management platform will traverse all configured menu data on the menu table every 10 minutes. First, the menu address is requested directly without any cookie. Since the current request is in the unlogged state, the middleware SDK returns the unlogged identifier, so it is checked whether the unlogged identifier head['flag'] = 'unlogin' is contained in the return header. If the unlogged identifier is not returned, the menu is marked as a risk menu.

[0049] If the unlogged identifier exists, a login cookie without the menu permission of the cookie is generated, for example, the RSA asymmetrically encrypted cookie of user yewei2, and the menu address is requested with the cookie. Since the cookie is in the logged state, the middleware SDK makes a request for the menu permission verification interface. Since there is no permission, the middleware SDK returns the no permission identifier, so it is checked whether the no permission identifier head['flag'] = 'unauth' is contained in the return header. If the no permission identifier is not returned, the menu is marked as a risk menu.

[0050] If the no permission identifier exists, the last step of verification is performed, a login cookie with the menu permission of the cookie is generated, for example, the login cookie of user yewei, and the menu is requested with the cookie. Since user yewei has the menu permission, the middleware SDK passes the verification and returns the specific menu page to the user, so it is checked whether any head['flag'] identifier exists in the return header. If the identifier exists, the menu is marked as a risk menu; the risk menu is prewarned, and the relevant department is notified to rectify.

[0051] Referring to Figure 2 A system for detecting the security of background menu permissions, 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 user login on the background management platform. After the background management platform is verified, the login username is encrypted using a private key, and the encrypted information is stored in the cookie of the root domain name.

[0053] The login verification module is used for integrating a unified verification middleware SDK in a background subsystem, when a user accesses a subsystem page, the middleware SDK acquires a login cookie, and uses a key to decrypt to acquire a user login account, if the decryption result is empty, the middleware SDK adds a non-login identifier in a return header;

[0054] The permission verification module is used for acquiring an accessed subsystem page address by using the middleware SDK, and transmitting the subsystem page address and the user login account to a verification interface of a background management platform, after the background management platform receives the verification request, the background management platform finds a menu corresponding to the subsystem page address configured, and verifies whether a role corresponding to the user has access permission, if the user has the access permission, the middleware SDK allows the user to access and display content of the subsystem page address, if the user does not have the permission, the middleware SDK adds a no permission identifier in the return header;

[0055] The sub verification module is used for periodically traversing all configured menu data by the background management platform, checking whether the return header contains the non-login identifier and the no permission identifier, and performing early warning according to the checking result.

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

[0057] In an embodiment of the present application, the permission verification module finds a menu corresponding to the subsystem page address configured, and verifies whether a role corresponding to the user has access permission, specifically: after the background management platform receives the verification request, first, whether the subsystem page address and a menu number exist are found in a menu resource table, if yes, whether the user has the menu number permission is found in a permission table through the menu number.

[0058] In an embodiment of the present application, the sub verification module is further specifically: a request menu check is performed, whether the non-login identifier is contained in the return header is checked, if not, the menu is marked as a risk menu, and early warning is performed;

[0059] If the non-login identifier exists, a login cookie without the menu permission is generated, and the cookie is requested to perform the menu check, if the no permission identifier is contained in the return header, the menu is marked as the risk menu, and early warning is performed;

[0060] If the non-login identifier and the no permission identifier do not exist in the return header, a login cookie with the menu permission is generated, and the cookie is requested to perform the menu check, if any kind of identifier exists in the return header, the menu is marked as the risk menu, and early warning is performed on the risk menu, if the identifier does not exist in the return header, it indicates safety.

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

[0062] The above merely illustrates the preferred embodiments of the present application, and any equivalent changes and modifications made within the scope of the present application should be included.

Claims

1. A method for detecting background menu authority security, characterized by, The method steps are as follows: Step 1: the user logs in the background management platform, and the background management platform uses a private key to encrypt the login username after verification, and stores the encrypted information in the cookie of the root domain name; Step 2: the subsystem of the background management platform integrates a unified verification middleware SDK, when the user accesses 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 login identification in the return header; Step 3: the middleware SDK obtains the accessed subsystem page address, and transmits 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 finds the menu corresponding to the subsystem page address, and verifies whether the user corresponding role has access right, if the user has access right, the middleware SDK allows the user to access and display the content of the subsystem page address; If there is no right, the middleware SDK adds a no right identification in the return header; Step 4: the background management platform periodically traverses all configured menu data, checks whether the return header contains the login identification and the no right identification, and performs early warning according to the checking result; The menu corresponding to the subsystem page address is found in step 3, and whether the user corresponding role has access right is verified, specifically: after receiving the verification request, the background management platform first finds whether the subsystem page address and the menu number exist in the menu resource table, if they exist, the user whether has the right of the menu number is found in the permission table through the menu number; Step 4 is further specific: the background management platform periodically requests menu check, directly requests the menu address without any cookie, checks whether the return header contains the login identification, if not found, the menu is marked as a risk menu, and early warning is performed; If the login identification exists, a login cookie without the right of the menu is generated, and the menu address is requested with the cookie, if the return header contains the no right identification, the menu is marked as a risk menu, and early warning is performed; If the return header does not contain the login identification and the no right identification, a login cookie with the right of the menu is generated, and the menu address is requested with the cookie, if the return header contains any kind of identification, the menu is marked as a risk menu and early warning is performed on the risk menu; If the return header does not contain the identification, it means safety.

2. The method of claim 1, wherein, The encryption in step 1 is RSA asymmetric encryption or DES symmetric encryption.

3. A system for background menu authority security detection, the system comprising: The system comprises an encryption module, a login verification module, a right verification module and a subsystem verification module; The encryption module is used for user login in the background management platform, and the background management platform uses a private key to encrypt the login username after verification, and stores the encrypted information in the cookie of the root domain name; The login verification module is used for integrating a unified verification middleware SDK in a background subsystem, when a user accesses a subsystem page, the middleware SDK acquires a login cookie, and uses a key to decrypt to acquire a user login account, if the decryption result is empty, the middleware SDK adds a non-login identifier in a return header; The permission verification module is used for acquiring an accessed subsystem page address by using the middleware SDK, and transmitting the subsystem page address and the user login account to a verification interface of a background management platform, after the background management platform receives the verification request, the background management platform finds a menu corresponding to the subsystem page address, and verifies whether a role corresponding to the user has access permission, if the user has the access permission, the middleware SDK allows the user to access and display content of the subsystem page address; if the user has no permission, the middleware SDK adds a no permission identifier in the return header; The sub verification module is used for periodically traversing all configured menu data by the background management platform, checking whether the return header contains the non-login identifier and the no permission identifier, and performing early warning according to the checking result; The permission verification module further comprises the following steps: after the background management platform receives the verification request, first, it is checked whether the subsystem page address and a menu number exist in a menu resource table, if yes, it is checked whether the user has the menu number permission in a permission table through the menu number; The sub verification module is further specifically used for request menu checking, checking whether the return header contains the non-login identifier, if not, the menu is marked as a risk menu, and early warning is performed; If the non-login identifier exists, a login cookie without the menu permission is generated, and the cookie is used to request the menu checking, if the return header contains the no permission identifier, the menu is marked as the risk menu, and early warning is performed; If the return header does not contain the non-login identifier and the no permission identifier, a login cookie with the menu permission is generated, and the cookie is used to request the menu checking, if the return header contains any identifier, the menu is marked as the risk menu, and early warning is performed on the risk menu; if the return header does not contain the identifier, it indicates safety.

4. The system for detecting background menu authority security according to claim 3, wherein, The encryption is RSA asymmetric encryption or DES symmetric encryption.

Images