An unauthorized access protection method and system, an electronic device and a storage medium

Abstract

The application discloses an over-privilege access protection method and system, electronic equipment and a storage medium, and relates to the technical field of network access control. The method is applied to a front-end server and comprises the following steps: in response to a first access request of a user, forwarding to a back-end server, extracting data identification from returned response data and storing the data identification in association with a session identification as white list data; in response to a second access request, extracting a target data identification and judging whether the target data identification exists in the white list, and if the target data identification exists in the white list, forwarding to the back-end server to obtain response data. The application establishes an access control mechanism based on a session context in the front-end server, and realizes real-time protection of over-privilege access in a non-intrusive manner.

Description

Technical Field

[0001] This invention relates to the field of network access control technology, and in particular to a method, system, electronic device, and storage medium for preventing unauthorized access. Background Technology

[0002] Web-based business systems are widely used in various enterprise digital platforms. They typically break down business logic into multiple interfaces such as list queries, detail viewing, and file upload / download, relying on front-end and back-end interaction to complete data display and resource distribution. Because resource identifiers (such as data IDs and file URLs) in these interfaces often exhibit predictable patterns, attackers can bypass the front-end page flow logic and directly access detailed data by brute-forcing IDs or sharing direct links. In scenarios with multiple concurrent users, the security risk of unauthorized access and data theft continues to increase. Therefore, how to implement low-cost, low-intrusion interface access control has become a key requirement for web security operations and maintenance.

[0003] The current mainstream solution in the industry is to add multiple layers of authentication logic in the backend business code. Each request verifies the user's identity and resource access permissions. Relying on code-level interface-by-interface authentication, users are only allowed to access their own associated data, thereby blocking unauthorized behaviors such as ID forgery and direct link access.

[0004] However, this transformation method requires large-scale modification of the original business code, which is highly invasive. Not only does it increase the server load due to repeated authentication, but once the authentication design flaw is discovered after going live, the repair cycle is long. Temporary solutions can only be made by sacrificing normal business by blocking accounts or removing resources. At the same time, there is still a security vulnerability that allows attackers to bypass the page flow logic by brute-forcing IDs and directly access detailed data, resulting in unauthorized theft. Summary of the Invention

[0005] This invention provides a method, system, electronic device, and storage medium for preventing unauthorized access, which can solve the problems of high backend redundant authentication load, delayed response to security vulnerabilities, and protection schemes intruding into business systems in the prior art.

[0006] To achieve the above objectives, the embodiments of the present invention adopt the following technical solutions: In a first aspect, a method for preventing unauthorized access is provided, applied to a front-end server, comprising: responding to a user's first access request, forwarding the first access request to a back-end server, extracting at least one data identifier from the first response data returned by the back-end server, and storing the at least one data identifier in association with the user's session identifier as whitelist data corresponding to the session identifier; responding to the user's second access request, extracting a target data identifier from the second access request, and determining whether the target data identifier exists in the whitelist data corresponding to the session identifier; if the target data identifier exists in the whitelist data, forwarding the second access request to the back-end server so that the back-end server returns response data corresponding to the target data identifier.

[0007] The method provided by this invention establishes a session context-based access control mechanism on the front-end server. When a user accesses list data, it extracts data identifiers from the response forwarded by the front-end server and establishes a whitelist. When a user requests detailed data, it performs whitelist verification before the back-end server, allowing only authorized data identifiers to pass. This intercepts unauthorized access requests from the front-end proxy layer without modifying the back-end business code. On the one hand, the whitelist data is automatically generated during the user's normal business process, requiring no additional permission configuration. On the other hand, unauthorized access determination is completed before the request reaches the back-end server, avoiding the performance overhead of repeated back-end authentication and achieving real-time blocking of unauthorized access.

[0008] In one possible implementation of the first aspect, the method further includes: if the target data identifier does not exist in the whitelist data, then the second access request is determined to be an unauthorized access, and a preset security action is performed.

[0009] In one possible implementation of the first aspect, the session identifier is obtained by extracting a session identifier field from the user's access request, the session identifier field being carried in a cookie or URL parameter.

[0010] In one possible implementation of the first aspect, extracting at least one data identifier from the first response data returned by the backend server includes: matching the response body of the first response data using a regular expression to extract a data identifier that conforms to a preset field format, wherein the preset field format is used to describe the key-value pair structure of the data identifier in the response body.

[0011] In one possible implementation of the first aspect, the step of associating and storing the at least one data identifier with the user's session identifier includes: storing the session identifier and the at least one data identifier in a red-black tree structure, wherein the red-black tree structure is organized with the session identifier as the dimension, and each session identifier corresponds to a set of data identifiers. As a self-balancing binary search tree, the time complexity of its insertion and search operations is logarithmic, which can adapt to the fast access requirements of whitelist data in high-concurrency request scenarios of the front-end server.

[0012] In one possible implementation of the first aspect, the data identifier set is maintained according to a caching strategy, which includes session-level caching and action-level caching. When the caching strategy is session-level caching, the data identifiers in the data identifier set remain valid within the session validity period corresponding to the session identifier, and all data identifiers obtained by the user in the preceding access request are retained in the whitelist data. When the caching strategy is action-level caching, the data identifier set is cleared each time a new first access request arrives and is refilled based on the response data of the current first access request.

[0013] Session-level caching is suitable for scenarios with lenient authorization where users can access browsed data multiple times during a session, while action-level caching is suitable for scenarios with strict authorization where data must be accessed in the logical order of the page. The two strategies can be flexibly switched through configuration to adapt to business needs with different security levels.

[0014] In one possible implementation of the first aspect, the method further includes: traversing the red-black tree structure at a preset time interval, and when it is detected that the time difference between the access timestamp corresponding to any session identifier and the current time exceeds a preset timeout duration, deleting the session identifier and the data identifier set corresponding to the session identifier.

[0015] The method provided by this invention avoids invalid sessions from occupying memory resources for a long time by periodically cleaning up timed-out sessions and their whitelist data, thus ensuring that the storage space of the front-end server is reused efficiently.

[0016] In one possible implementation of the first aspect, the method further includes: when a session heartbeat request is received from the user to maintain the session online, updating the access timestamp of the corresponding session identifier in the red-black tree structure.

[0017] In one possible implementation of the first aspect, the preset security action includes at least one of the following: returning a preset error status code to the client that initiated the second access request; and redirecting the client that initiated the second access request to a preset page.

[0018] Error status codes allow clients to be clearly informed that access has been denied, while redirection can lead users to the login page or other secure pages. Both methods can be configured and selected based on the actual needs of the business system.

[0019] In one possible implementation of the first aspect, the front-end server is an Nginx server.

[0020] In one possible implementation of the first aspect, the method further includes: receiving the first business request triggered by the backend server after the user successfully logs in, and creating a new session identifier for the user and recording the initial access timestamp in the frontend server.

[0021] Secondly, the present invention provides an unauthorized access protection system deployed on a front-end server, comprising: a session identification module for identifying a user's session identifier and maintaining session state; a data identifier whitelisting module for extracting at least one data identifier from the first response data returned by the back-end server after the user's first access request is forwarded to the back-end server, and storing the at least one data identifier in association with the session identifier as whitelist data corresponding to the session identifier; and an unauthorized access determination module for extracting a target data identifier from the second access request when the user's second access request arrives, determining whether the target data identifier exists in the whitelist data corresponding to the session identifier; if it exists, forwarding the second access request to the back-end server so that the back-end server returns response data corresponding to the target data identifier; if it does not exist, determining that the second access request is unauthorized access and executing a preset security action.

[0022] Thirdly, an electronic device is provided, the electronic device including a memory and one or more processors; the memory is coupled to the processors; wherein the memory stores computer program code, the computer program code including computer instructions, which, when executed by the processor, cause the electronic device to perform the method as described in any implementation of the first aspect.

[0023] Fourthly, a computer-readable storage medium is provided, including computer instructions that, when executed on an electronic device, cause the electronic device to perform a method as described in any implementation of the first aspect.

[0024] Fifthly, a computer program product is provided that, when run on a computer, causes the computer to perform the method in any implementation of the first aspect.

[0025] Understandably, the beneficial effects achieved by the system of the second aspect, the electronic device of the third aspect, the computer-readable storage medium of the fourth aspect, and the computer program product of the fifth aspect provided above can be referred to with reference to the beneficial effects of the first aspect and any of its possible design embodiments, which will not be repeated here. Attached Figure Description

[0026] Figure 1 This is a schematic diagram of the structure of an electronic device provided in an embodiment of the present invention; Figure 2 A flowchart illustrating an unauthorized access prevention method provided in an embodiment of the present invention; Figure 3 This is a schematic diagram illustrating an application scenario of an unauthorized access prevention method provided in an embodiment of the present invention; Figure 4 This is a schematic diagram of a protection system provided in an embodiment of the present invention. Detailed Implementation

[0027] The technical solutions of the embodiments of the present invention will be described below with reference to the accompanying drawings. In the description of the present invention, unless otherwise stated, " / " indicates that the objects before and after are in an "or" relationship. For example, A / B can represent A or B. The "or" in the present invention is merely a description of the relationship between the related objects, indicating that three relationships can exist. For example, A or B can represent: A alone, A and B simultaneously, and B alone. A and B can be singular or plural. Furthermore, in the description of the present invention, unless otherwise stated, "multiple" refers to two or more. "At least one of the following" or similar expressions refer to any combination of these items, including any combination of single or plural items.

[0028] Furthermore, to facilitate a clear description of the technical solutions of the embodiments of the present invention, the terms "first" and "second" are used in the embodiments of the present invention to distinguish identical or similar items with essentially the same function and effect. Those skilled in the art will understand that the terms "first" and "second" do not limit the quantity or execution order, and that the terms "first" and "second" are not necessarily different.

[0029] In this embodiment of the invention, the terms "exemplary" or "for example" are used to indicate that something is an example, illustration, or description. Any embodiment or design described as "exemplary" or "for example" in this embodiment of the invention should not be construed as superior or more advantageous than other embodiments or designs. Specifically, the use of terms such as "exemplary" or "for example" is intended to present the relevant concepts in a concrete manner for ease of understanding.

[0030] Web-based business systems are widely used in various enterprise digital platforms. They typically break down business logic into multiple interfaces such as list queries, detail viewing, and file upload / download, relying on front-end and back-end interaction to complete data display and resource distribution. Because resource identifiers (such as data IDs and file URLs) in these interfaces often exhibit predictable patterns, attackers can bypass the front-end page flow logic and directly access detailed data by brute-forcing IDs or sharing direct links. In scenarios with multiple concurrent users, the security risk of unauthorized access and data theft continues to increase. Therefore, how to implement low-cost, low-intrusion interface access control has become a key requirement for web security operations and maintenance.

[0031] The current mainstream solution in the industry is to add multiple layers of authentication logic in the backend business code. Each request verifies the user's identity and resource access permissions. Relying on code-level interface-by-interface authentication, users are only allowed to access their own associated data, thereby blocking unauthorized behaviors such as ID forgery and direct link access.

[0032] However, this transformation method requires large-scale modification of the original business code, which is highly invasive. Not only does it increase the server load due to repeated authentication, but once the authentication design flaw is discovered after going live, the repair cycle is long. Temporary solutions can only be made by sacrificing normal business by blocking accounts or removing resources. At the same time, there is still a security vulnerability that allows attackers to bypass the page flow logic by brute-forcing IDs and directly access detailed data, resulting in unauthorized theft.

[0033] In view of this, embodiments of the present invention provide a method for preventing unauthorized access, the method comprising: responding to a user's first access request, forwarding the first access request to a backend server, extracting at least one data identifier from the first response data returned by the backend server, and storing the at least one data identifier in association with the user's session identifier as whitelist data; responding to the user's second access request, extracting a target data identifier from the second access request, determining whether the target data identifier exists in the whitelist data; if it exists, forwarding the request to the backend server so that the backend server returns corresponding response data.

[0034] The method provided by this invention establishes a session context-based access control mechanism on the front-end server. When a user accesses list data normally, it automatically extracts the identifiers in the returned data to create a whitelist. When a user requests detailed data, it performs whitelist verification before the back-end server. Thus, it intercepts unauthorized access requests from the front-end proxy layer without modifying the back-end business code, achieving non-intrusive real-time unauthorized access protection.

[0035] In some embodiments, an unauthorized access protection method provided by the present invention can be executed by an unauthorized access protection system 100.

[0036] As an example, the unauthorized access protection system 100 can be any electronic device 200 with data processing capabilities, such as a general-purpose computer, personal computer, laptop computer, switch, or tablet computer. The specific implementation method of the unauthorized access protection system 100 is not limited here.

[0037] Figure 1 A schematic diagram of the hardware structure of an electronic device provided in an embodiment of the present invention is shown. The electronic device 200 includes a processor 210, a memory 220, and a communication interface 230.

[0038] Processor 210 may include one or more processing cores. Processor 210 connects to various parts within electronic device 200 using various interfaces and lines, and performs various functions and processes data of electronic device 200 by running or executing instructions, programs, code sets, or instruction sets stored in memory 220, and by calling data stored in memory 220. Optionally, processor 210 may be implemented using at least one of the following hardware forms: Central Processing Unit (CPU), Graphics Processing Unit (GPU), Digital Signal Processing (DSP), Field-Programmable Gate Array (FPGA), and Programmable Logic Array (PLA).

[0039] The memory 220 may include random access memory (RAM) or read-only memory (ROM). Optionally, the memory 220 may include a non-transitory computer-readable storage medium. The memory 220 may be used to store instructions, programs, code, code sets, or instruction sets. The memory 220 may include a program storage area. This program storage area may store instructions for implementing an operating system, instructions for implementing at least one function, instructions for implementing the various method embodiments described above, etc.

[0040] Communication interface 230 is used to communicate with other devices, equipment or communication networks, such as data storage devices, image processing devices or Ethernet, wireless access network (RAN), wireless local area network (WLAN), etc.

[0041] In terms of physical implementation, the aforementioned devices (such as processor 210, memory 220, and communication interface 230) can each be devices within the same device (such as a laptop computer). Alternatively, at least two of these devices can be located within the same device, i.e., as different devices within the same device, similar to the deployment of devices or components in a distributed system.

[0042] It is understood that the structure illustrated in this embodiment does not constitute a specific limitation on the electronic device 200. In other embodiments of the present invention, the electronic device 200 may include more or fewer components than illustrated, or combine some components, or split some components, or have different component arrangements. The illustrated components may be implemented in hardware, software, or a combination of software and hardware.

[0043] The following description, in conjunction with the accompanying drawings, illustrates an embodiment of the unauthorized access protection method provided by the present invention.

[0044] Figure 2 This is a flowchart illustrating an unauthorized access prevention method provided in an embodiment of the present invention. Optionally, this method can be... Figure 1 The illustrated electronic device 200 performs this method, which includes the following steps: S1. In response to the user's first access request, forward the first access request to the backend server, extract at least one data identifier from the first response data returned by the backend server, and associate and store the at least one data identifier with the user's session identifier as whitelist data corresponding to the session identifier.

[0045] Specifically, the first access request is a request initiated by the user in the normal business process, whose response data contains identifiers of data that may be requested later, such as a list data query request. Taking a task management system as an example, after logging into the system, the user initiates a request to "get my to-do list". This request is forwarded by the front-end server to the back-end server. The back-end server queries according to the user's identity and business rules and returns response data in JSON format. The data contains multiple task records, and each record has a unique data identifier (such as a task ID).

[0046] Before returning the response data to the client, the front-end server parses the response body and extracts all data identifiers according to the preset field format.

[0047] In one possible implementation, extracting at least one data identifier from the first response data returned from the backend server includes: The response body of the first response data is matched using regular expressions to extract data identifiers that conform to a preset field format. The preset field format is used to describe the key-value pair structure of the data identifiers in the response body.

[0048] The default field format is a key-value pair structure, such as "id":"001" in JSON and "id":"001" in XML. <id> 001< / id> wait.

[0049] For example, the response body returned by the backend server is as follows: {"tasks":[{"id":"001","title":"Contract Approval"},{"id":"002","title":"Complete Weekly Report"},{"id":"003","title":"Attend Meeting"}]} The front-end server extracts data identifiers based on preset field formats: "001", "002", and "003".

[0050] It should be noted that the embodiments of the present invention do not impose any particular limitation on the specific implementation method of extracting data identifiers from response data. In one possible implementation, the response body is matched and extracted using regular expressions. For example, the regular expression is "id":"([^\"]*)", where ([^\"]*) matches any non-double-quoted character sequence within the double quotes, that is, extracting the value corresponding to the id field. In practical applications, the specific content of the regular expression is determined according to the field name of the data identifier and the response body format in the business system, and the embodiments of the present invention do not impose any particular limitation on this.

[0051] In some embodiments, the step of associating and storing the at least one data identifier with the user's session identifier includes: The session identifier and the at least one data identifier are stored in a red-black tree structure, which is organized with the session identifier as the dimension, and each session identifier corresponds to a set of data identifiers.

[0052] The front-end server associates the extracted data identifiers with the current user's session identifier and stores them together. The session identifier uniquely identifies a user session and serves as the index key for that user across all whitelisted data on the front-end server. In one possible implementation, the associated storage uses a red-black tree data structure, with the session identifier as the key and the set of data identifiers as the value, where each session identifier corresponds to an independent set of data identifiers. As a self-balancing binary search tree, the red-black tree has a time complexity of O(log n) for both insertion and search operations, making it suitable for the front-end server's need for fast access to whitelisted data in high-concurrency request scenarios.

[0053] S2. In response to the user's second access request, extract the target data identifier from the second access request and determine whether the target data identifier exists in the whitelist data corresponding to the session identifier.

[0054] Specifically, the second access request is a detailed data query request initiated by the user based on a record in the first response data after completing the first access request. For example, if the user clicks on the "Approve Contract" task in the task list obtained in the previous step, the browser sends a request to the server to "get details of task 001", which carries the target data identifier "001".

[0055] In one possible implementation, the session identifier is obtained in the following way: Extract the session identifier field from the user's access request. The session identifier field is carried in a cookie or URL parameter.

[0056] Specifically, the front-end server intercepts the second access request, extracts the target data identifier from the request parameters (such as URL query parameters or request body), searches for the corresponding data identifier set in the red-black tree using the current user's session identifier as an index, and determines whether the target data identifier exists in the set.

[0057] Based on the above example, the URL of the second access request is: GET / getTaskDetail?id=001. The front-end server extracts the target data identifier "001", uses the session identifier to search the red-black tree to obtain the data identifier set {"001","002","003"}, and determines that "001" exists in the set.

[0058] S3. If the target data identifier exists in the whitelist data, the second access request is forwarded to the backend server so that the backend server returns response data corresponding to the target data identifier.

[0059] Specifically, if the whitelist verification passes, it means that the data identifier requested by the user was authorized and returned by the backend server during the normal business process, and this access is legitimate. The frontend server forwards the second access request to the backend server normally. After processing the business logic, the backend server returns the corresponding detailed data, and the frontend server returns the detailed data to the client for rendering and display.

[0060] In one possible implementation, if the target data identifier does not exist in the whitelist data, the second access request is determined to be an unauthorized access, and a preset security action is performed.

[0061] Specifically, a failed whitelist check indicates that the user has never obtained this data identifier in normal business processes, and the current request may be an unauthorized access. A typical unauthorized access scenario is as follows: An attacker obtains a data identifier (such as task id="999") through enumeration, speculation, or other channels, and directly constructs a detailed data request GET / getTaskDetail?id=999 without accessing the list page. Since "999" does not exist in the whitelist data corresponding to this user session, the front-end server determines that the request is an unauthorized access and does not forward it to the back-end server, but instead performs security actions directly at the front-end server level.

[0062] In one possible implementation, the preset security actions include at least one of the following: returning a preset error status code, such as the HTTP 404 status code, to the client that initiated the second access request, so that the client knows that the request is rejected but cannot determine whether the resource exists in the backend; redirecting the client that initiated the second access request to a preset page, such as the system login page, so that the attacker cannot obtain any valid information.

[0063] It should be noted that the above security actions are merely illustrative examples. Those skilled in the art can configure other handling methods according to actual security strategies, such as recording alarm logs or triggering security alarm notifications. This embodiment of the invention does not impose any special limitations on this.

[0064] The following combination Figure 3 The application scenarios of this invention will be described in general. Figure 3 This is a schematic diagram illustrating an application scenario of an unauthorized access protection method provided in an embodiment of the present invention, showing a comparison between a normal business process and an unauthorized access attack process.

[0065] Scenario 1: Normal and legitimate access process: After a user logs into the business system, they initiate a list data request (the first access request). This request is forwarded from the front-end server to the back-end server, which returns response data containing multiple data identifiers. The front-end server extracts all data identifiers from the response data and associates them with the user's session identifier, storing them as a whitelist. Next, the user selects a specific item from the list, initiating a detailed data request (the second access request). The front-end server extracts the target data identifier from this request, finds the identifier in the corresponding whitelist, determines it as legitimate access, and forwards the request to the back-end server, which then returns the detailed data.

[0066] Scenario 2: Unauthorized Access Interception Process: An attacker bypasses the list page access process, obtaining data identifiers through speculation or enumeration, and directly constructs a detailed data request (the second access request) and sends it to the front-end server. The front-end server extracts the target data identifier from this request and searches the whitelist using the user's session identifier. Since the user has never accessed list data containing that identifier, and the target data identifier is not in the whitelist, the front-end server determines this as unauthorized access, directly returning an error status code or redirecting to a preset page. The request does not reach the back-end server, thus protecting the back-end business data.

[0067] As can be seen from the above process, the protection method provided by this invention does not require any code modification or permission logic adjustment on the backend server. The frontend server automatically builds a whitelist by listening to normal business responses, and completes the unauthorized access judgment and interception before subsequent requests reach the backend, achieving non-intrusive real-time protection.

[0068] In the above embodiments, the session identifier is the core of the whitelist data organization.

[0069] In one possible implementation, the session identifier is obtained by extracting a session identifier field from the user's access request. This session identifier field is carried in a cookie or URL parameter. For example, when the session identifier is carried in a cookie, the configuration parameter is "cookie:jsession", where "jsession" is the name of the cookie storing the session identifier; when the session identifier is carried in a URL parameter, the configuration parameter is "url:token", where "token" is the name of the parameter in the URL that carries the session identifier. After parsing the session identifier from the request, the front-end server first checks whether a node corresponding to the session identifier already exists in the red-black tree. If it exists, it indicates that a session has been established; if it does not exist, it indicates that the user is initiating a business request for the first time, and a new session identifier node is created for it, with the current time recorded as the initial access timestamp.

[0070] In one possible implementation, after a user successfully logs in, when the backend server triggers its first business request, the frontend server creates a new session identifier for that user and records the initial access timestamp. This step is a prerequisite for the whitelist mechanism to operate, ensuring that each legitimate user has a valid session identifier before initiating a list data request, and that subsequently extracted data identifiers can be correctly associated with that session identifier.

[0071] In the above embodiments, the lifecycle of the whitelist data is closely related to the session lifecycle. In one possible implementation, the method provided by this embodiment further includes an automatic session timeout cleanup mechanism: traversing the red-black tree structure at preset time intervals, and when the time difference between the access timestamp corresponding to any session identifier and the current time exceeds a preset timeout duration, deleting the session identifier and the corresponding data identifier set. For example, the preset timeout duration is 1800 seconds (30 minutes), and the timed traversal interval is 60 seconds. This timeout cleanup mechanism prevents historical sessions of logged-out users and their whitelist data from occupying memory resources for extended periods, ensuring efficient reuse of the front-end server's storage space.

[0072] Furthermore, in one possible implementation, the method provided by this embodiment of the invention also includes a session heartbeat maintenance mechanism: when a session heartbeat request is received from a user to maintain the session online, the access timestamp of the corresponding session identifier in the red-black tree structure is updated. The session heartbeat request is a lightweight keep-alive request sent periodically by the user client (e.g., sent every few minutes). After the front-end server identifies the request, it updates the timestamp of the corresponding session, so that the sessions of active users are not mistakenly cleaned up due to timeout.

[0073] In the above embodiments, the strategy for filling and updating whitelist data directly affects the flexibility and security of protection.

[0074] In one possible implementation, the data identifier set is maintained according to a caching strategy, which includes session-level caching and action-level caching. The two strategies can be flexibly switched through configuration.

[0075] Session-level caching: Data identifiers in the data identifier set remain valid throughout the session corresponding to the session identifier. All data identifiers obtained by the user through each list data request during the session are accumulated and retained in the whitelist data. This strategy is suitable for lenient authorization scenarios where users can review viewed data multiple times during the session. For example, if a user enters the details page of task A from the task list page and then returns to the list page, there is no need to go through the list page validation again when entering task A again.

[0076] Action-level caching: The data identifier set is cleared each time a new list data request arrives and is repopulated based on the response data of that list data request. This strategy is suitable for strictly authorized scenarios that require access to data in the logical order of the page, such as when users must see the latest list before accessing its details, preventing users from using expired list data identifiers to access data whose authorization has been revoked.

[0077] The choice between the two caching strategies mentioned above can be specified through the configuration parameters of the front-end server. There is no need to modify the back-end business code or restart the service, and the changes take effect immediately after configuration.

[0078] In one possible implementation, the front-end server is an Nginx server. The unauthorized access protection method provided in this embodiment of the invention is implemented through an extension plugin for the Nginx server. The protection logic is embedded in the Nginx reverse proxy configuration in the form of a configuration file, without intruding on the back-end business system. The implementation of the above three functional modules is explained below with specific configuration examples.

[0079] For example, the following three configuration parts can be added to the reverse proxy configuration of an Nginx server.

[0080] (a) Session identification configuration This is used to identify user session identifiers and maintain session state. Add a session identification parameter to the reverse proxy address configuration that needs to maintain session awareness. An example configuration is as follows: location / keepalive { proxy http: / / xxxx / keepalive; unisessionmark'cookie:jsession''jsession'1800; } "unisessionmark" is a module configuration parameter name that identifies and processes the request content when accessed from the address " / keepalive". "cookie:jsession" / "url:token" are the identification modes, currently supporting both cookies and URL parameters. 'jsession' is the cookie name, and 'token' is the URL parameter name. After obtaining the session, the module checks if the session exists in the red-black tree. If it does, the timestamp is updated; otherwise, a new session is created, and its timestamp is recorded.

[0081] 1800 is the timeout period of 30 minutes (30 * 60 seconds).

[0082] This configuration needs to be set in two places: one is the session heartbeat request, and the other is the first service request after the user successfully logs in.

[0083] When a user request reaches this address, the front-end server extracts the session identifier from the request and searches for the identifier in a red-black tree: if it does not exist, a new node is created and the current timestamp is recorded as the access timestamp; if it exists, the access timestamp is updated. This configuration needs to be configured in two places: one is the session heartbeat request address, used to maintain the session's online status; the other is the address of the first business request after successful user login verification, used to create a new session.

[0084] (ii) Configuration of white-labeled data identifiers This is used to extract data identifiers from the response data returned by the backend and store them in a whitelist. Add a data identifier extraction parameter to the reverse proxy configuration. An example configuration is as follows: location / getTaskList{ proxy http: / / xxxx / getTaskList; unidefendermark'taskdefender''unisession''"id":"([^\"]*)"'; } Here, unidefendermark is the module configuration name, which Nginx uses to load external plugin identifiers.

[0085] `taskdefender` is the name of the cache used to add items to the whitelist, and it needs to be consistent with the name of the decision-making module that follows.

[0086] `uniaction` is the caching strategy; here it's session-level caching. If it were action-level caching, change it to `uniaction`. Session-level caching caches data throughout the entire session, meaning that data that has been accessed remains valid and allows legitimate access within the valid session later. Action-level caching, on the other hand, automatically clears historical cached data each time it's cached, meaning that access is only considered legitimate if it strictly follows the page logic. "id":"([^\"]*)" is a regular expression for retrieving identifier data. Note the identifiers and corresponding character escaping rules reserved by Nginx when writing it.

[0087] (III) Configuration for determining unauthorized access This is used to identify data identifiers in a request and compare them with whitelist data to determine if unauthorized access has been granted. An example configuration is as follows: location / getTaskDetail{ proxy http: / / xxxx / getTaskDetail; unidefenderaction'taskdefender''"id":"([^\"]*)"''return:404'; } Where unidefenderaction is the module configuration name, which Nginx uses to load external plugin identifiers.

[0088] taskdefender is the cache name used to determine whether it is a whitelisted data identifier, and it needs to be consistent with the name of the data identifier identification and whitelisting module mentioned above.

[0089] "id":"([^\"]*)" is a regular expression for retrieving identifier data. Note the identifiers and corresponding character escaping rules reserved by Nginx when writing it.

[0090] `return: 404` indicates an invalid request and directly returns a 404 error code. The specific setting can be adjusted according to the project's needs. For example, setting it to `rewrite: / login` will redirect to the system's login page.

[0091] It should be noted that the configuration format and command names of the Nginx extension plugins described above are illustrative. In practical applications, the specific implementation of the plugin module can adopt Nginx's native module development interface or a Lua script-based extension mechanism (such as OpenResty), and the naming and parameter format of the configuration commands can be defined according to engineering practice. This invention does not impose any particular restrictions on the specific type of front-end server or the plugin implementation method. Any solution that can achieve session identification, response data extraction, and whitelist comparison at the front-end proxy server level falls within the protection scope of this invention.

[0092] In one possible implementation, the method provided in this embodiment of the invention further includes multi-session parallel management capabilities. The front-end server simultaneously maintains session identifiers for multiple active users and their corresponding whitelist data. Each user's session and cached data are independent of each other in a red-black tree, isolated based on the session identifier. When requests arrive from different users, the front-end server extracts their respective session identifiers and performs whitelist queries in their respective cache spaces, without interference. When a user's session times out and is cleaned up, it does not affect the normal access of other active users.

[0093] As described above, the method provided by this invention establishes a session context-based access control mechanism on the front-end server, extracts data identifiers to build a whitelist in the preceding context (response to the first access request), and compares the whitelist in the following context (second access request) to determine unauthorized access, thus achieving non-intrusive real-time protection against unauthorized access. Compared with existing back-end duplicate authentication schemes, this invention moves the authentication logic from the back-end business server to the front-end proxy server without modifying the back-end business code or increasing the back-end computing load. Compared with existing post-event handling schemes, this invention can block unauthorized access requests in real time before they reach the back-end, eliminating the need for a patching delay window. The whitelist data is automatically generated and updated along with the user's normal business process, requiring no additional permission rule maintenance, significantly reducing deployment and maintenance costs.

[0094] This invention can also be understood as follows: Based on sessions, it establishes context relationships through normal user access to the business system. In the preceding text, it acquires and caches data identifiers as whitelisted data. In the following text, it checks whether the target data identifier is whitelisted data and, based on the judgment result, allows access or performs security measures. Automatic session timeout cleanup and heartbeat keep-alive mechanisms ensure the timeliness of cached data and efficient utilization of memory resources. Through both session-level and action-level caching strategies, it adapts to business scenarios with different security levels. The entire protection mechanism is deployed non-intrusively on the front-end server, independent of the back-end business system's technology stack and programming language, and can be quickly integrated into existing systems.

[0095] The foregoing mainly describes the solutions of the embodiments of the present invention from a methodological perspective. It is understood that, in order to achieve the above-mentioned functions, the unauthorized access protection system 100 includes at least one of the hardware structures and software modules corresponding to the execution of each function. Those skilled in the art should readily recognize that, in conjunction with the units and algorithm steps of the various examples described in the embodiments disclosed herein, the embodiments of the present invention can be implemented in hardware or a combination of hardware and computer software. Whether a function is executed in hardware or by computer software driving hardware depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of the embodiments of the present invention.

[0096] In this embodiment of the invention, the unauthorized access protection system 100 can be divided into functional units according to the above method example. For example, the unauthorized access protection system 100 can be divided into functional units corresponding to each function, or two or more functions can be integrated into one processing unit. The integrated unit can be implemented in hardware or as a software functional unit. It should be noted that the unit division in this embodiment of the invention is illustrative and only represents one logical functional division; other division methods may be used in actual implementation.

[0097] For example, Figure 4This diagram illustrates the structure of an unauthorized access prevention system according to an embodiment of the present invention. The unauthorized access prevention system 100 is deployed on a front-end server and includes: a session identification module 110, used to identify a user's session identifier and maintain session state; a data identifier whitelisting module 120, used to extract at least one data identifier from the first response data returned by the back-end server after the user's first access request is forwarded to the back-end server, and associate the at least one data identifier with the session identifier for storage as whitelist data corresponding to the session identifier; and an unauthorized access determination module 130, used to extract a target data identifier from the second access request when the user's second access request arrives, and determine whether the target data identifier exists in the whitelist data corresponding to the session identifier; if it exists, the second access request is forwarded to the back-end server so that the back-end server returns response data corresponding to the target data identifier; if it does not exist, the second access request is determined to be unauthorized access and a preset security action is executed.

[0098] It should be understood that specific descriptions of the above-mentioned optional methods can be found in the foregoing method embodiments, and will not be repeated here. Furthermore, explanations of any of the above-provided unauthorized access protection systems 100 and descriptions of their beneficial effects can be found in the corresponding method embodiments, and will not be repeated here.

[0099] This invention also provides a computer-readable storage medium storing at least one computer instruction, which is loaded and executed by a processor to implement the methods of the various embodiments described above. Explanations of the relevant content and descriptions of the beneficial effects of any of the computer-readable storage media provided above can be found in the corresponding embodiments described above, and will not be repeated here.

[0100] This invention also provides a chip. This chip integrates a control circuit for implementing the functions of the aforementioned unauthorized access protection system 100 and one or more ports. Optionally, the functions supported by this chip are as described above and will not be repeated here.

[0101] Those skilled in the art will understand that the program for implementing all or part of the steps of the above embodiments, which can be executed by a program instructing related hardware, can be stored in a computer-readable storage medium. The storage medium mentioned above can be a read-only memory, a random access memory, etc. The processing unit or processor mentioned above can be a central processing unit, a general-purpose processor, an application-specific integrated circuit (ASIC), a microprocessor (DSP), a field-programmable gate array (FPGA), or other programmable logic devices, transistor logic devices, hardware components, or any combination thereof.

[0102] This invention also provides a computer program product containing instructions that, when executed on a computer, cause the computer to perform any of the methods described in the above embodiments. The computer program product includes one or more computer instructions. When the computer program instructions are loaded and executed on a computer, all or part of the flow or function according to the embodiments of this invention is generated. The computer can be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. The computer instructions can be stored in a computer-readable storage medium or transmitted from one computer-readable storage medium to another. For example, computer instructions can be transmitted from one website, computer, server, or data center to another via wired (e.g., coaxial cable, fiber optic, digital subscriber line (DSL)) or wireless (e.g., infrared, wireless, microwave, etc.) means. The computer-readable storage medium can be any available medium accessible to a computer or a data storage device such as a server or data center that integrates one or more available media. The available medium can be a magnetic medium (e.g., floppy disk, hard disk, magnetic tape), an optical medium (e.g., DVD), or a semiconductor medium (e.g., SSD), etc.

[0103] It should be noted that the devices for storing computer instructions or computer programs provided in the embodiments of the present invention, such as, but not limited to, the aforementioned memory, computer-readable storage medium, and communication chip, are all non-transitory. Those skilled in the art should recognize that the functions described in the embodiments of the present invention in one or more of the above examples can be implemented using hardware, software, firmware, or any combination thereof. When implemented using software, these functions can be stored in a computer-readable storage medium or transmitted as one or more instructions or code on a computer-readable storage medium. Computer-readable storage media include computer storage media and communication media, wherein communication media include any medium that facilitates the transmission of computer programs from one place to another. Storage media can be any available medium accessible to general-purpose or special-purpose computers.

[0104] Although embodiments of the present invention have been shown and described above, it is understood that the above embodiments are exemplary and should not be construed as limiting the present invention. Those skilled in the art can make changes, modifications, substitutions and variations to the above embodiments within the scope of the present invention.

Claims

1. A method for preventing unauthorized access, characterized in that, Applied to front-end servers, including: In response to a user’s first access request, the first access request is forwarded to a backend server. At least one data identifier is extracted from the first response data returned by the backend server. The at least one data identifier is associated with the user’s session identifier and stored as whitelist data corresponding to the session identifier. In response to the user's second access request, a target data identifier is extracted from the second access request, and it is determined whether the target data identifier exists in the whitelist data corresponding to the session identifier; If the target data identifier exists in the whitelist data, the second access request is forwarded to the backend server so that the backend server returns response data corresponding to the target data identifier.

2. The method according to claim 1, characterized in that, The method further includes: If the target data identifier does not exist in the whitelist data, the second access request is determined to be an unauthorized access, and a preset security action is executed.

3. The method according to claim 1, characterized in that, The session identifier is obtained in the following way: Extract the session identifier field from the user's access request. The session identifier field is carried in a cookie or URL parameter.

4. The method according to claim 1, characterized in that, Extracting at least one data identifier from the first response data returned from the backend server includes: The response body of the first response data is matched using regular expressions to extract data identifiers that conform to a preset field format. The preset field format is used to describe the key-value pair structure of the data identifiers in the response body.

5. The method according to claim 1, characterized in that, The step of associating and storing the at least one data identifier with the user's session identifier includes: The session identifier and the at least one data identifier are stored in a red-black tree structure, which is organized with the session identifier as the dimension, and each session identifier corresponds to a set of data identifiers.

6. The method according to claim 5, characterized in that, The data identifier set is maintained according to a caching strategy, which includes session-level caching and action-level caching. When the caching strategy is session-level caching, the data identifiers in the data identifier set remain valid within the session validity period corresponding to the session identifier, and all data identifiers obtained by the user in the preceding access request are retained in the whitelist data; When the caching strategy is action-level caching, the data identifier set is cleared each time a new first access request arrives, and then refilled based on the response data of the current first access request.

7. The method according to claim 5, characterized in that, The method further includes: The red-black tree structure is traversed at preset time intervals. When the time difference between the access timestamp corresponding to any session identifier and the current time exceeds a preset timeout duration, the session identifier and the data identifier set corresponding to the session identifier are deleted.

8. The method according to claim 7, characterized in that, The method further includes: When a session heartbeat request is received from the user to maintain the session online, the access timestamp of the corresponding session identifier in the red-black tree structure is updated.

9. The method according to claim 2, characterized in that, The preset safety response actions include at least one of the following: Return a preset error status code to the client that initiated the second access request; The client that initiated the second access request will be redirected to a preset page.

10. The method according to any one of claims 1 to 9, characterized in that, The front-end server is an Nginx server.

11. The method according to claim 1, characterized in that, The method further includes: Upon receiving the first business request triggered by the backend server after the user successfully logs in, the frontend server creates a new session identifier for the user and records the initial access timestamp.

12. An unauthorized access prevention system, characterized in that, Deployed on the front-end server, including: The session identification module is used to identify the user's session identifier and maintain the session state; The data identifier whitelisting module is used to extract at least one data identifier from the first response data returned by the backend server after the user's first access request is forwarded to the backend server, and to associate and store the at least one data identifier with the session identifier as whitelist data corresponding to the session identifier. The unauthorized access determination module is used to extract a target data identifier from the second access request when the user's second access request arrives, and determine whether the target data identifier exists in the whitelist data corresponding to the session identifier; if it exists, the second access request is forwarded to the backend server so that the backend server returns response data corresponding to the target data identifier; if it does not exist, the second access request is determined to be unauthorized access and a preset security action is performed.

13. An electronic device, characterized in that, include: processor; Memory used to store the processor's executable instructions; The processor is configured to execute the instructions to implement the method as described in any one of claims 1-11.

14. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores at least one computer program, which is loaded and executed by a processor to enable the computer to perform the method as described in any one of claims 1-11.

Images