Access control method and device

Abstract

The present application provides an access control method and device, wherein the method includes: receiving an access request from a target user, wherein the access request carries a token; matching the user data of the target user according to the token; determining the user role to which the target user belongs according to the user data; calling a request rule library to obtain the request rule associated with the user role in the request rule library; determining whether the access request is compatible with the associated request rule, and if it is determined to be compatible, determining that the access verification is passed. The above scheme solves the problems of low security and excessive data load in the existing access control process, and achieves the technical effect of accurate security control and low data load.

Description

Technical Field

[0001] The present application belongs to the field of Internet technology, and in particular, relates to an access control method and device. Background Art

[0002] Privilege escalation means that an attacker can perform some operations that he is not qualified to perform, which is an "access control" issue. Privilege escalation is divided into vertical privilege escalation and horizontal privilege escalation. Vertical privilege escalation refers to privilege escalation between different user levels, such as ordinary users executing the permissions of administrator users. Horizontal privilege escalation refers to privilege escalation between users of the same level. For a normal web request, the general process is: login-submit request-verify permissions-database query-return results. If the front-end request is too trusting and there is no effective verification, it will lead to privilege escalation. Common programs will think that the user's identity can be verified after logging in, so they will not do the next step of verification, which will eventually lead to privilege escalation.

[0003] At present, there are several common unauthorized access attacks:

[0004] 1) By hiding the URL, this unauthorized method controls the URL that only has administrator privileges, but the URL leakage may lead to malicious attacks or be guessed by attackers, thus leading to unauthorized access;

[0005] 2) Direct object reference: This attack modifies the request parameters, such as changing the query user ID from a low-privilege ID to a high-privilege ID, thereby exceeding the authority;

[0006] 3) Upload and download files. This attack method attacks the download function of the website. Many websites have paid VIP download channels. If the attacker knows about it, the files will be downloaded without authorization.

[0007] 4) Multi-stage functions: If a function has multiple transaction stages, such as the password reset function, the first step of the transaction needs to verify the user information, and the second step is to reset the password after the verification is successful. If the second step of resetting the password does not perform identity authentication, the attacker can replay the request, bypass the first step of verification, and then reset the new password, resulting in a successful attack.

[0008] As to how to prevent and control the above-mentioned unauthorized behaviors, no effective solution has been proposed so far. Summary of the invention

[0009] The purpose of the present application is to provide an access control method and device, which can avoid unauthorized access.

[0010] The present application provides an access control method and device which are implemented as follows:

[0011] An access control method, the method comprising:

[0012] Receiving an access request from a target user, wherein the access request carries a token;

[0013] Matching user data of the target user according to the token;

[0014] Determining the user role to which the target user belongs according to the user data;

[0015] Retrieving a request rule library to obtain a request rule associated with the user role in the request rule library;

[0016] Determine whether the access request is compatible with the associated request rule, and if it is determined that they are compatible, determine that the access verification is passed.

[0017] In one embodiment, the access request further carries: request parameters and request path. Accordingly, determining whether the access request is compatible with the associated request rule includes:

[0018] Determining whether the request parameter and the request path exist in the associated request rule;

[0019] In the case of determining that the request parameter and the request path exist, determining adaptation;

[0020] In the case where it is determined that the request parameter and the request path do not exist, it is determined that there is no match.

[0021] In one embodiment, before calling the request rule library, the method further includes:

[0022] Determining whether the request rule base is stored in the target cache;

[0023] When it is determined that the request rule base is stored in the target cache, the request base rules are read from the database and stored in the target cache, so that they can be directly obtained from the target cache when the request rule base is called.

[0024] In one embodiment, after determining whether the access request is compatible with the associated request rule, the method further includes:

[0025] When it is determined that the access request does not match the associated request rule, a response message indicating access failure is returned to the front end.

[0026] In one embodiment, before receiving the access request of the target user, the method further includes:

[0027] Receive the target user's authentication and authorization request;

[0028] In response to the verification authorization request, authenticating the target user;

[0029] If the verification is successful, a token is issued to the target user, wherein the token is time-sensitive and associated with the user data of the target user.

[0030] In one embodiment, the rules in the request rule library are bound to user roles, different user roles correspond to different request rules, and the same user role corresponds to the same request rules.

[0031] An access control device, comprising:

[0032] A receiving module, used for receiving an access request from a target user, wherein the access request carries a token;

[0033] A matching module, used for matching the user data of the target user according to the token;

[0034] A first determination module, configured to determine the user role to which the target user belongs according to the user data;

[0035] A calling module, used for calling a request rule library, and obtaining a request rule associated with the user role in the request rule library;

[0036] The second determination module is used to determine whether the access request is compatible with the associated request rule, and if it is determined that it is compatible, determine that the access verification is passed.

[0037] In one embodiment, the access request further carries: request parameters and request path, and accordingly, the second determination module includes:

[0038] A first determining unit, configured to determine whether the request parameter and the request path exist in the associated request rule;

[0039] A second determining unit, configured to determine adaptation when it is determined that the request parameter and the request path exist;

[0040] The third determining unit is configured to determine that there is no match when it is determined that the request parameter and the request path do not exist.

[0041] An electronic device comprises a processor and a memory for storing instructions executable by the processor, wherein the steps of the above method are implemented when the processor executes the instructions.

[0042] A computer-readable storage medium stores computer instructions, which implement the steps of the above method when executed.

[0043] The access control method and device provided by the present application, by carrying a token that can match user data in the access request, can authenticate the user after receiving the access request. After identity authentication, the user role can be determined, thereby determining the request rule associated with the user role, thereby determining whether there is a risk of unauthorized access, so as to achieve security control of access. Furthermore, because the request rule is associated with the user role rather than with a single user, the amount of data in the request rule can be reduced. The above scheme solves the problems of low security and excessive data load in the existing access control process, and achieves the technical effect of accurate security control and low data load. BRIEF DESCRIPTION OF THE DRAWINGS

[0044] In order to more clearly illustrate the embodiments of the present application or the technical solutions in the prior art, the drawings required for use in the embodiments or the description of the prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments recorded in the present application. For ordinary technicians in this field, other drawings can be obtained based on these drawings without paying creative labor.

[0045] Figure 1 is a method flow chart of an embodiment of the access control method provided by the present application;

[0046] Figure 2 This is a flowchart of a method for preventing web unauthorized access provided by this application;

[0047] Figure 3 This is a schematic diagram of the system structure for preventing web unauthorized access provided by this application;

[0048] Figure 4 It is a hardware structure block diagram of an electronic device of an access control method provided by the present application;

[0049] Figure 5 It is a schematic diagram of the module structure of an embodiment of the access control method device provided by the present application. DETAILED DESCRIPTION

[0050] In order to enable those skilled in the art to better understand the technical solutions in this application, the technical solutions in the embodiments of this application will be clearly and completely described below in conjunction with the drawings in the embodiments of this application. Obviously, the described embodiments are only part of the embodiments of this application, not all of them. Based on the embodiments in this application, all other embodiments obtained by ordinary technicians in this field without creative work should fall within the scope of protection of this application.

[0051] Figure 1It is a method flow chart of an embodiment of the access control method provided by the present application. Although the present application provides method operation steps or device structures as shown in the following embodiments or drawings, more or fewer operation steps or module units may be included in the method or device based on routine or no creative labor. In the steps or structures where there is no necessary causal relationship logically, the execution order of these steps or the module structure of the device is not limited to the execution order or module structure described in the embodiments of the present application and shown in the drawings. When the method or module structure is applied in an actual device or terminal product, it can be connected according to the method or module structure shown in the embodiments or drawings for sequential execution or parallel execution (for example, a parallel processor or a multi-threaded processing environment, or even a distributed processing environment).

[0052] Specifically, Figure 1 As shown, the above access control method may include the following steps:

[0053] Step 101: receiving an access request from a target user, wherein the access request carries a token;

[0054] That is, a token is issued to the user with user authorization. After the token is issued, it is bound to the user information and saved. The saved token is put into the request body of each request to prevent the user request from being tampered with, thereby ensuring the secure transmission of the request to the server.

[0055] Step 102: Matching the user data of the target user according to the token;

[0056] Step 103: Determine the user role to which the target user belongs according to the user data;

[0057] Step 104: Retrieve a request rule library and obtain a request rule associated with the user role in the request rule library;

[0058] That is, a request rule base is established on the server side, and the request rules in the request rule base are bound to the user role to verify each request sent by the client.

[0059] Step 105: Determine whether the access request is compatible with the associated request rule, and if it is determined that it is compatible, determine that the access verification is passed.

[0060] In the above example, by carrying a token that can match user data in the access request, the user can be authenticated after receiving the access request. After identity authentication, the user role can be determined, thereby determining the request rule associated with the user role, thereby determining whether there is a risk of unauthorized access, so as to achieve security control of access. Furthermore, because the request rule is associated with the user role rather than with a single user, the amount of data in the request rule can be reduced. The above solution solves the problems of low security and excessive data load in the existing access control process, and achieves the technical effect of accurate security control and low data load.

[0061] When actually performing request verification, i.e., the above-mentioned request rule adaptation, the access request may carry: request parameters and request path. Accordingly, determining whether the access request is adapted to the associated request rule may include: determining whether the request parameters and request path exist in the associated request rule; determining adaptation if the request parameters and request path exist; and determining incompatibility if the request parameters and request path do not exist. That is, by determining whether the request parameters and request path exist in the request rule, request rule adaptation is performed to implement verification of the user's access request.

[0062] In order to improve the efficiency of data access, the request rule library can be stored in the cache by pre-caching the request rule library. That is, before calling the request rule library, it can be determined whether the request rule library is stored in the target cache; when it is determined that the request rule library is stored in the target cache, the request library rules are read from the database and stored in the target cache, so that they can be directly obtained from the target cache when calling the request rule library. In this way, when accessing the request rule library, it can be directly obtained from the cache, which improves the efficiency of data access.

[0063] During implementation, if it is determined that the access request is not compatible with the associated request rule, then the access request can be determined to be an unauthorized access request, and therefore, a response message indicating access failure can be returned to the front end.

[0064] For the token, it can be applied for by the user. For example, for the server, it can receive a verification authorization request from the target user; in response to the verification authorization request, the target user's identity is authenticated; if the verification is passed, a token is issued to the target user, wherein the token is time-limited and associated with the user data of the target user.

[0065] The rules in the request rule library are bound to user roles. Different user roles correspond to different request rules, and the same user roles correspond to the same request rules. That is, different request rules are set based on different roles, rather than different request rules based on different users. This can reduce the amount of data in the request rule library, and even if the number of users increases sharply, too many request rules will not be stored.

[0066] The above method is described below in conjunction with a specific embodiment. However, it should be noted that this specific embodiment is only for better illustrating the present application and does not constitute an improper limitation on the present application.

[0067] This example provides a way and method to prevent unauthorized attacks, which only involves attacks in the Web field. There are currently two commonly used methods to prevent unauthorized attacks in the Web field:

[0068] 1) Encryption is performed on the basis of each page request. After the encrypted ciphertext data is sent to the front end, the permission parameter information is obtained by obtaining the previously encrypted ciphertext data during the next request to perform anti-unauthorized verification.

[0069] 2) On the basis of preventing unauthorized access, the concept of a verification information database is proposed, in which the verification information database is bound to the business acceptance information and the business ID, and the business acceptance ID is generated based on the user's mobile phone number. Anti-unauthorized access verification is performed by comparing the unauthorized verification information database.

[0070] However, the above two methods have problems to varying degrees. Method 1) encrypts the request, but the transmission of each request requires the encrypted ciphertext data of the previous request to obtain the permission parameter information, which is strongly dependent on the permission information of the previous request; although method 2) provides a solution for the verification information library, it does not depend on the previous request permission information, but as time goes by and the system grows, the rules of the verification information library will grow with the increase in user mobile phone numbers, which will also cause the problem of slow request response time.

[0071] Based on this, a web-based method for preventing unauthorized access is provided in this example. A token (hereinafter referred to as: token) is issued to the user in a user authorization manner. After the token is issued, the token is bound to the user information and saved. The saved token information is placed in the request body for each request to prevent the user request from being tampered with, thereby ensuring that the request is securely transmitted to the server. At the same time, a request rule library is established on the server side, and the request rules in the request rule library are bound to the user role to verify each request sent by the client. Furthermore, for reading the request rule library, the request rule library can be stored in the cache by pre-caching the request rule library.

[0072] The above method first authorizes the page access request, and then binds the user information to the user page access permission instead of binding it to the user role each time. It determines whether the current user has the permission to access a certain type of user (such as administrator permission) according to the user role. Moreover, for the request rule base, since the vertical overreach is generally a request for low-authority users to overreach to high-authority users, only the accessible rules within the high-authority range can be saved to prevent vertical overreach, and it is not necessary to bind all rules to individual users; for horizontal overreach requests, the differences in requests between different user roles are also relatively small, and only the differences in the request rules between different roles can be saved in the request rule base. This greatly slows down the growth rate of the verification rule base. At the same time, due to the setting of the user authorization mechanism, the confidentiality of each request to send information is guaranteed, and unauthenticated access requests (such as file upload and download) are prevented. The above scheme not only prevents the risk of request message information being tampered with, but also does not cause the verification rules to be too complicated and difficult to maintain, and the request response is too slow because the verification rule base is bound to individual users. Furthermore, because the cache technology is used to pre-cache the request rules, the response speed of the request is greatly improved.

[0073] Specifically, the method for preventing unauthorized access to the web can be as follows: Figure 2 As shown, the following steps:

[0074] S1: The client sends verification information to the server for verification;

[0075] S2: The server verifies the customer information and whether the verification is successful;

[0076] S3: After successful verification, the server performs authorization processing and issues a token with a time limit to the client;

[0077] S4: The server binds the token and user information and stores them;

[0078] S5: The server returns the token to the client, which encrypts it and saves it in the front-end session.

[0079] S6: After obtaining the token, the client adds the token to the request body in subsequent accesses and sends the request normally;

[0080] S7: After receiving the request, the server obtains the token in the request and obtains the user information based on the token;

[0081] S8: After successfully obtaining the user information, query the authority information of the user according to the user information;

[0082] S9: According to the user authority information, obtain the accessible request rule library corresponding to the current authority;

[0083] S10: If the current user has the permission in the request rule base, the request is passed; otherwise, the request is not passed;

[0084] S11: For requests containing tokens that are about to expire, request a new token to be reissued. If successful, a new token is issued and returned to the front end, and the business continues to be processed. After processing, the new token is returned to the front end.

[0085] S12: After the front end obtains the new token, it deletes the original token and replaces it with the new token. It also carries the new token in subsequent requests and sends the request to the server.

[0086] Furthermore, for the above steps S8 and S9, in this example, the method of pre-reading the request rules is adopted: since the rule data in the request rule library needs to be used frequently, in high-concurrency business scenarios, the database is mostly a weak link in user concurrent access. Therefore, it is generally necessary to use buffer operations for processing rather than directly accessing databases such as Mysql.

[0087] In order to solve the problem of excessive amount of high-concurrency business data, in this example, the data in the request rule base is cached by caching the request rule base. For example, Figure 1 The cache operation is performed in a way to determine whether there is a cache. If there is data in the cache, it is returned to the caller. If there is no data in the cache, the data is loaded from the database and written to the cache, and then returned to the caller.

[0088] For unauthorized operations, Figure 3 The module implementation shown:

[0089] User management module 1, used to verify user information and request authorization;

[0090] Authorization management module 2 is used to authorize users who have passed the verification and issue a time-limited token;

[0091] Furthermore, for requests containing tokens that are about to expire, the authorization management module will be called to request a re-issued token. If successful, a new token will be issued and returned to the front end;

[0092] The unauthorized management module 3 is used to maintain the increase and query of the server-side request rule library and bind it with the user role ID so that each different role can access different request rules;

[0093] The request rule base is divided into: vertical unauthorized request detection rule base and horizontal unauthorized request detection rule base. The vertical unauthorized library binds the request path to the role according to the role classification; the horizontal unauthorized library is classified according to the role.

[0094] Business processing module 4, a module for subsequent business processing after successful unauthorized verification;

[0095] Specifically, in order to prevent the Web system from exceeding its authority, in this example, the main tables used are: user information table user_tbl, user role table role_tbl, role rule table role_rule_relation; the roles used are: administrator role_admin, ordinary user A role_user_a, ordinary user B role_user_b, among which role_admin>role_user_a>role_user_b.

[0096] Furthermore, after the client request is sent to the server, a filter can be used to obtain the parameters in the request. For example, in this example, the parameters obtained are: request parameters, request path, and token used for each request. At this time, in order to prevent unauthorized access, the token and request parameters can be verified to prevent the client from sending unauthorized requests.

[0097] The table structure (role_rule_relation) used by the request rule base can be shown in the following table:

[0098] Field Name Data Types Role_id Char(10) Type Char(1) Role_rule Char(200)

[0099] The type field is divided into vertical override and horizontal override. The role_rule is the rule for horizontal override, such as related URLs or user-specific information. The stored information varies depending on the horizontal and vertical override methods.

[0100] Assume the following scenario: the attacker illegally obtains the account of role_user_b, and now wants to use the account of role_user_b to unauthorize and access the permissions of role_admin. Then the attacker can implement the attack in the following steps: the attacker logs in to the account of role_user_b and obtains its token permissions. The attacker uses illegal means to initiate a request to the server. The data or path contained in this request can be viewed by role_admin.

[0101] For role_user_b, the specific steps to prevent web privilege escalation in this example are as follows:

[0102] S2.1: User role_user_b obtains token data;

[0103] S2.2: role_user_b sends a request to the server;

[0104] S2.3: The server intercepts the request sent by the client through the filter program and reads the data in the request. The data example is as follows:

[0105] Parameter name Location data Token Requet header ff6a1593-0c09-49ff-b4c2-7a6087b9238 Request path Request URL management / role_admin_info Request parameters Request body {usr_pho:12212345678}

[0106] S2.4: The server reads the user data through the token. The user data example is as follows:

[0107]

[0108] S2.5: The server determines whether there is role_rule_relation data in the cache redis based on user_pho;

[0109] S2.6: If it exists, directly return its rule data to the filter program, read the rule data of role_user_b, and for the convenience of display, the data can be in json format, as shown below:

[0110]

[0111] S2.7: If it is found that there is no cached data in the cache redis, the program calls the data of the database table role_rule_relation and role_inf database table, and writes them to redis and the data table;

[0112] S2.8: After matching the data requested by role_user_b in the rule base, the program finds that the management / role_admin_info path does not exist in the rule base, and determines that role_user_b has exceeded his authority. The server-side program finds that role_user_b does not have permission to read this data request, and returns a response message indicating that the front end has failed.

[0113] S2.9: The front-end interface reports an error.

[0114] In the above example, a solution to web unauthorized access is proposed, which optimizes security and response efficiency, greatly reducing the hidden dangers of complicated maintenance and slow user response caused by binding rules to user information during the establishment of the request rule base. Specifically, the use of token technology not only prevents the intrusion of attackers without permission to access the system, or the tampering of request information by the client, but also blocks the unauthorized attack method. At the same time, the solution is modularized, which greatly facilitates the convenience and convenience of actual production use. The method of using token authentication to read user information and the method of using token technology to read bound user information greatly facilitate the back-end server to read user data and prevent the possibility of client request tampering. It also proposes a method of using cache technology to store the request rule base.

[0115] The method embodiments provided in the above embodiments of the present application can be executed in a mobile terminal, a computer terminal or a similar computing device. Taking running on an electronic device as an example, Figure 4 1 is a hardware structure diagram of an electronic device of an access control method provided by this application. Figure 4 As shown, the electronic device 10 may include one or more (only one is shown in the figure) processors 02 (the processor 02 may include but is not limited to a processing device such as a microprocessor MCU or a programmable logic device FPGA), a memory 04 for storing data, and a transmission module 06 for communication functions. It can be understood by those skilled in the art that Figure 4 The structure shown is only for illustration and does not limit the structure of the above electronic device. Figure 4 More or fewer components as shown, or with Figure 4 Different configurations are shown.

[0116] The memory 04 can be used to store software programs and modules of application software, such as program instructions / modules corresponding to the access control method in the embodiment of the present application. The processor 02 executes various functional applications and data processing by running the software programs and modules stored in the memory 04, that is, the access control method of the above-mentioned application is realized. The memory 04 may include a high-speed random access memory, and may also include a non-volatile memory, such as one or more magnetic storage devices, flash memory, or other non-volatile solid-state memory. In some examples, the memory 04 may further include a memory remotely arranged relative to the processor 02, and these remote memories can be connected to the electronic device 10 via a network. Examples of the above-mentioned network include, but are not limited to, the Internet, an intranet, a local area network, a mobile communication network, and combinations thereof.

[0117] The transmission module 06 is used to receive or send data via a network. The specific example of the above network may include a wireless network provided by a communication provider of the electronic device 10. In one example, the transmission module 06 includes a network adapter (Network Interface Controller, NIC), which can be connected to other network devices through a base station so as to communicate with the Internet. In one example, the transmission module 06 can be a radio frequency (Radio Frequency, RF) module, which is used to communicate with the Internet wirelessly.

[0118] At the software level, the access control device can be Figure 5 As shown, including:

[0119] The receiving module 501 is used to receive an access request from a target user, wherein the access request carries a token;

[0120] A matching module 502, configured to match the user data of the target user according to the token;

[0121] A first determination module 503, configured to determine the user role to which the target user belongs according to the user data;

[0122] A calling module 504 is used to call a request rule library to obtain a request rule associated with the user role in the request rule library;

[0123] The second determination module 505 is used to determine whether the access request is compatible with the associated request rule, and if it is determined that it is compatible, determine that the access verification is passed.

[0124] In one implementation, the access request may also carry: request parameters and request path. Accordingly, the second determination module may include:

[0125] A first determining unit, configured to determine whether the request parameter and the request path exist in the associated request rule;

[0126] A second determining unit, configured to determine adaptation when it is determined that the request parameter and the request path exist;

[0127] The third determining unit is configured to determine that there is no match when it is determined that the request parameter and the request path do not exist.

[0128] In one embodiment, the access control device may also determine whether the request rule library is stored in the target cache before calling the request rule library; if it is determined that the request rule library is stored in the target cache, the request library rules are read from the database and stored in the target cache, so as to be directly obtained from the target cache when calling the request rule library.

[0129] In one embodiment, after determining whether the access request is compatible with the associated request rule, the access control device may also return an access failure response message to the front end if it is determined that the access request is not compatible with the associated request rule.

[0130] In one embodiment, the access control device may also receive a verification authorization request from the target user before receiving the access request from the target user; in response to the verification authorization request, the target user may be authenticated; and if the verification is successful, a token may be issued to the target user, wherein the token is time-sensitive and associated with the user data of the target user.

[0131] In one embodiment, the rules in the request rule library are bound to user roles, different user roles correspond to different request rules, and the same user role corresponds to the same request rules.

[0132] The embodiments of the present application also provide a specific implementation of an electronic device capable of implementing all the steps in the access control method in the above embodiments, wherein the electronic device specifically includes the following contents: a processor, a memory, a communication interface, and a bus; wherein the processor, the memory, and the communication interface communicate with each other through the bus; the processor is used to call a computer program in the memory, and when the processor executes the computer program, all the steps in the access control method in the above embodiments are implemented. For example, when the processor executes the computer program, the following steps are implemented:

[0133] Step 1: Receive an access request from a target user, wherein the access request carries a token;

[0134] Step 2: Match the user data of the target user according to the token;

[0135] Step 3: Determine the user role to which the target user belongs based on the user data;

[0136] Step 4: Retrieve the request rule library and obtain the request rule associated with the user role in the request rule library;

[0137] Step 5: Determine whether the access request is compatible with the associated request rule, and if it is determined that it is compatible, determine that the access verification is passed.

[0138] From the above description, it can be seen that the embodiment of the present application carries a token that can match user data in the access request, so that after receiving the access request, the user can be authenticated. After identity authentication, the user role can be determined, thereby determining the request rule associated with the user role, thereby determining whether there is a risk of unauthorized access, so as to achieve security control of access. Furthermore, because the request rule is associated with the user role rather than with a single user, the amount of data in the request rule can be reduced. The above scheme solves the problems of low security and excessive data load in the existing access control process, and achieves the technical effect of accurate security control and low data load.

[0139] The embodiments of the present application also provide a computer-readable storage medium capable of implementing all the steps in the access control method in the above embodiments. The computer-readable storage medium stores a computer program. When the computer program is executed by a processor, all the steps in the access control method in the above embodiments are implemented. For example, when the processor executes the computer program, the following steps are implemented:

[0140] Step 1: Receive an access request from a target user, wherein the access request carries a token;

[0141] Step 2: Match the user data of the target user according to the token;

[0142] Step 3: Determine the user role to which the target user belongs based on the user data;

[0143] Step 4: Retrieve the request rule library and obtain the request rule associated with the user role in the request rule library;

[0144] Step 5: Determine whether the access request is compatible with the associated request rule, and if it is determined that it is compatible, determine that the access verification is passed.

[0145] From the above description, it can be seen that the embodiment of the present application carries a token that can match user data in the access request, so that after receiving the access request, the user can be authenticated. After identity authentication, the user role can be determined, thereby determining the request rule associated with the user role, thereby determining whether there is a risk of unauthorized access, so as to achieve security control of access. Furthermore, because the request rule is associated with the user role rather than with a single user, the amount of data in the request rule can be reduced. The above scheme solves the problems of low security and excessive data load in the existing access control process, and achieves the technical effect of accurate security control and low data load.

[0146] Each embodiment in this specification is described in a progressive manner, and the same or similar parts between the embodiments can be referred to each other, and each embodiment focuses on the differences from other embodiments. In particular, for the hardware + program embodiment, since it is basically similar to the method embodiment, the description is relatively simple, and the relevant parts can be referred to the partial description of the method embodiment.

[0147] The above is a description of a specific embodiment of the specification. Other embodiments are within the scope of the appended claims. In some cases, the actions or steps recorded in the claims can be performed in an order different from that in the embodiments and still achieve the desired results. In addition, the processes depicted in the drawings do not necessarily require the specific order or continuous order shown to achieve the desired results. In some embodiments, multitasking and parallel processing are also possible or may be advantageous.

[0148] Although the present application provides method operation steps as described in the embodiments or flowcharts, more or fewer operation steps may be included based on conventional or non-creative labor. The order of steps listed in the embodiments is only one way of executing the order of many steps and does not represent the only execution order. When the actual device or client product is executed, it can be executed in the order of the method shown in the embodiments or the drawings or in parallel (for example, in a parallel processor or multi-threaded processing environment).

[0149] The systems, devices, modules or units described in the above embodiments may be implemented by computer chips or entities, or by products with certain functions. A typical implementation device is a computer. Specifically, the computer may be, for example, a personal computer, a laptop computer, a vehicle-mounted human-computer interaction device, a cellular phone, a camera phone, a smart phone, a personal digital assistant, a media player, a navigation device, an email device, a game console, a tablet computer, a wearable device, or a combination of any of these devices.

[0150] Although the present specification embodiment provides the method operation steps as described in the embodiment or flow chart, more or less operation steps may be included based on conventional or non-creative means. The order of steps listed in the embodiment is only one way in the order of execution of many steps, and does not represent a unique execution order. When the device or terminal product in practice is executed, it can be executed in sequence or in parallel (such as a parallel processor or a multi-threaded processing environment, or even a distributed data processing environment) according to the method shown in the embodiment or the accompanying drawings. The term "include", "comprise" or any other variant thereof is intended to cover non-exclusive inclusion, so that the process, method, product or equipment including a series of elements not only includes those elements, but also includes other elements not clearly listed, or also includes elements inherent to such process, method, product or equipment. In the absence of more restrictions, it is not excluded that there are other identical or equivalent elements in the process, method, product or equipment including the elements.

[0151] For the convenience of description, the above devices are described in various modules according to their functions. Of course, when implementing the embodiments of this specification, the functions of each module can be implemented in the same or more software and / or hardware, or the module implementing the same function can be implemented by a combination of multiple sub-modules or sub-units. The device embodiments described above are only schematic. For example, the division of the units is only a logical function division. There may be other division methods in actual implementation. For example, multiple units or components can be combined or integrated into another system, or some features can be ignored or not executed. Another point is that the mutual coupling or direct coupling or communication connection shown or discussed can be through some interfaces, indirect coupling or communication connection of devices or units, which can be electrical, mechanical or other forms.

[0152] Those skilled in the art also know that, in addition to implementing the controller in a purely computer-readable program code, the controller can be made to implement the same function in the form of logic gates, switches, application-specific integrated circuits, programmable logic controllers, and embedded microcontrollers by logically programming the method steps. Therefore, such a controller can be considered as a hardware component, and the devices for implementing various functions included therein can also be considered as structures within the hardware component. Or even, the devices for implementing various functions can be considered as both software modules for implementing the method and structures within the hardware component.

[0153] The present application is described with reference to the flowcharts and / or block diagrams of the methods, devices (systems), and computer program products according to the embodiments of the present application. It should be understood that each process and / or box in the flowchart and / or block diagram, as well as the combination of the processes and / or boxes in the flowchart and / or block diagram, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, a special-purpose computer, an embedded processor, or other programmable data processing device to generate a machine, so that the instructions executed by the processor of the computer or other programmable data processing device generate instructions for implementing the processes in the flowchart and / or block diagram. Figure 1 A process or multiple processes and / or boxes Figure 1 A device that provides the functions specified in a block or multiple blocks.

[0154] These computer program instructions may also be stored in a computer-readable memory capable of directing a computer or other programmable data processing device to operate in a specific manner, so that the instructions stored in the computer-readable memory produce an article of manufacture comprising an instruction device, which implements the process Figure 1 A process or multiple processes and / or boxes Figure 1 A function specified in one or more boxes.

[0155] These computer program instructions can also be loaded onto a computer or other programmable data processing device so that a series of operating steps are executed on the computer or other programmable device to produce a computer-implemented process, thereby providing instructions for implementing the process. Figure 1 A process or multiple processes and / or boxes Figure 1 A step that specifies a function in one or more boxes.

[0156] In a typical configuration, a computing device includes one or more processors (CPU), input / output interfaces, network interfaces, and memory.

[0157] The memory may include non-permanent storage in a computer-readable medium, random access memory (RAM) and / or non-volatile memory in the form of read-only memory (ROM) or flash RAM. The memory is an example of a computer-readable medium.

[0158] Computer readable media include permanent and non-permanent, removable and non-removable media that can be implemented by any method or technology to store information. Information can be computer readable instructions, data structures, program modules or other data. Examples of computer storage media include, but are not limited to, phase change memory (PRAM), static random access memory (SRAM), dynamic random access memory (DRAM), other types of random access memory (RAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory or other memory technology, compact disk read-only memory (CD-ROM), digital versatile disk (DVD) or other optical storage, magnetic cassettes, magnetic tape magnetic disk storage or other magnetic storage devices or any other non-transmission media that can be used to store information that can be accessed by a computing device. As defined herein, computer readable media does not include temporary computer readable media (transitory media), such as modulated data signals and carrier waves.

[0159] Those skilled in the art will appreciate that the embodiments of this specification may be provided as methods, systems or computer program products. Therefore, the embodiments of this specification may take the form of complete hardware embodiments, complete software embodiments or embodiments combining software and hardware. Moreover, the embodiments of this specification may take the form of a computer program product implemented on one or more computer-usable storage media (including but not limited to disk storage, CD-ROM, optical storage, etc.) containing computer-usable program codes.

[0160] The present specification embodiments may be described in the general context of computer-executable instructions executed by a computer, such as program modules. Generally, program modules include routines, programs, objects, components, data structures, etc. that perform specific tasks or implement specific abstract data types. The present specification embodiments may also be practiced in distributed computing environments where tasks are performed by remote processing devices connected through a communication network. In a distributed computing environment, program modules may be located in local and remote computer storage media, including storage devices.

[0161] Each embodiment in this specification is described in a progressive manner, and the same and similar parts between the embodiments can be referred to each other, and each embodiment focuses on the differences from other embodiments. In particular, for the system embodiment, since it is basically similar to the method embodiment, the description is relatively simple, and the relevant parts can be referred to the partial description of the method embodiment. In the description of this specification, the description of the reference terms "one embodiment", "some embodiments", "example", "specific example", or "some examples" means that the specific features, structures, materials or characteristics described in conjunction with the embodiment or example are included in at least one embodiment or example of the embodiment of this specification. In this specification, the schematic representation of the above terms does not necessarily target the same embodiment or example. Moreover, the specific features, structures, materials or characteristics described can be combined in any one or more embodiments or examples in a suitable manner. In addition, in the absence of contradiction, a person skilled in the art can combine and combine the different embodiments or examples described in this specification and the features of different embodiments or examples.

[0162] The above is only an example of the embodiment of the present specification and is not intended to limit the embodiment of the present specification. For those skilled in the art, the embodiment of the present specification may have various changes and variations. Any modification, equivalent replacement, improvement, etc. made within the spirit and principle of the embodiment of the present specification shall be included in the scope of the claims of the embodiment of the present specification.

Claims

1. An access control method, characterized in that: Used to prevent unauthorized attacks in the web field, the method includes: Receiving an access request from a target user, wherein the access request carries a token; Matching user data of the target user according to the token; Determining the user role to which the target user belongs according to the user data; Retrieving a request rule library to obtain a request rule associated with the user role in the request rule library; Determining whether the access request is compatible with the associated request rule, and if it is determined that they are compatible, determining that the access verification is passed; Before receiving the access request of the target user, the process also includes: the client sends verification information to the server for verification. After the verification is successful, the server performs authorization processing and issues a token with a time limit to the client. The server binds the token with the user information and stores it, and returns the token to the client. The client encrypts it and saves it in the front-end session. After the token is issued, the stored token is added to the request body at each request to prevent the user request from being tampered with. Correspondingly, after receiving the access request of the target user, it also includes: for the access request containing the token that is about to expire, the client requests to reissue a new token. If successful, the new token is issued to the client. After obtaining the new token, the client deletes the original token and replaces it with the new token, and carries the new token in the subsequent request and sends the request to the server. Among them, user information is not directly bound to the user's page access authority, but is bound to the user role, and whether the current user has the authority to access a certain type of user is determined based on the user role; in the request rule library, for vertical unauthorized access, only accessible rules with a high authority range are saved, and there is no need to bind all rules to individual users. For horizontal unauthorized access, since the differences in requests between different user roles are small, only the differences in request rules between different roles are saved in the request rule library; Among them, before calling the request rule library, it also includes: determining whether the request rule library is stored in the target cache; when it is determined that the request rule library is not stored in the target cache, reading the request rule library from the database and storing it in the target cache, so as to directly obtain it from the target cache when calling the request rule library.

2. The method according to claim 1, characterized in that The access request also carries: request parameters and request path. Accordingly, determining whether the access request is compatible with the associated request rule includes: Determining whether the request parameter and the request path exist in the associated request rule; In the case of determining that the request parameter and the request path exist, determining adaptation; In the case where it is determined that the request parameter and the request path do not exist, it is determined that there is no match.

3. The method according to claim 1, characterized in that After determining whether the access request is compatible with the associated request rule, the method further includes: When it is determined that the access request does not match the associated request rule, a response message indicating access failure is returned to the front end.

4. The method according to claim 1, characterized in that: Before receiving the target user's access request, it also includes: Receive the target user's authentication and authorization request; In response to the verification authorization request, authenticating the target user; If the verification is successful, a token is issued to the target user, wherein the token is time-sensitive and associated with the user data of the target user.

5. The method according to claim 1, characterized in that The rules in the request rule library are bound to user roles, different user roles correspond to different request rules, and the same user roles correspond to the same request rules.

6. An access control device, characterized in that: Used to prevent unauthorized attacks in the web domain, including: A receiving module, used for receiving an access request from a target user, wherein the access request carries a token; A matching module, used for matching the user data of the target user according to the token; A first determination module, configured to determine the user role to which the target user belongs according to the user data; A calling module, used for calling a request rule library, and obtaining a request rule associated with the user role in the request rule library; A second determination module is used to determine whether the access request is compatible with the associated request rule, and if it is determined that the access request is compatible, determine that the access verification is passed; Before receiving the access request of the target user, the process also includes: the client sends verification information to the server for verification. After the verification is successful, the server performs authorization processing and issues a token with a time limit to the client. The server binds the token with the user information and stores it, and returns the token to the client. The client encrypts it and saves it in the front-end session. After the token is issued, the stored token is added to the request body at each request to prevent the user request from being tampered with. Correspondingly, after receiving the access request of the target user, it also includes: for the access request containing the token that is about to expire, the client requests to reissue a new token. If successful, the new token is issued to the client. After obtaining the new token, the client deletes the original token and replaces it with the new token, and carries the new token in the subsequent request and sends the request to the server. Among them, user information is not directly bound to the user's page access authority, but is bound to the user role, and whether the current user has the authority to access a certain type of user is determined based on the user role; in the request rule library, for vertical unauthorized access, only accessible rules with a high authority range are saved, and there is no need to bind all rules to individual users. For horizontal unauthorized access, since the differences in requests between different user roles are small, only the differences in request rules between different roles are saved in the request rule library; Among them, before calling the request rule library, it also includes: determining whether the request rule library is stored in the target cache; when it is determined that the request rule library is not stored in the target cache, reading the request rule library from the database and storing it in the target cache, so as to directly obtain it from the target cache when calling the request rule library.

7. The device according to claim 6, characterized in that The access request also carries: request parameters and request path. Accordingly, the second determination module includes: A first determining unit, configured to determine whether the request parameter and the request path exist in the associated request rule; A second determining unit, configured to determine adaptation when it is determined that the request parameter and the request path exist; The third determining unit is configured to determine that there is no match when it is determined that the request parameter and the request path do not exist.

8. An electronic device, comprising a processor and a memory for storing processor-executable instructions, wherein the processor implements the steps of the method according to any one of claims 1 to 5 when executing the instructions.

9. A computer-readable storage medium having computer instructions stored thereon, wherein the instructions, when executed, implement the steps of the method according to any one of claims 1 to 5.

Images