Web system protection method and device based on interface management and storage medium

Abstract

The invention discloses a web system protection method and device based on interface management and a storage medium, and relates to the field of data security. The method comprises the following steps: after determining and updating a security interface in real time, synchronously updating a protection rule according to the updated security interface, judging an interface which does not exist in the protection rule as an abnormal interface, and determining an abnormal IP according to an IP corresponding to the abnormal interface. According to the method, real-time updating of the protection rules is realized through a dynamic interface scanning technology, and under the condition, interfaces and IPs which do not exist in the protection rules will be included in a blacklist; the high-frequency updating mechanism and the intelligent dynamic blacklist method can form cooperation, so that the accuracy of the IP blacklist and the IP whitelist is ensured, and the defect that attack and defense are not synchronous in traditional static configuration is fundamentally avoided.

Description

Technical Field

[0001] This application relates to the field of data security, specifically to a web system protection method, device, and storage medium based on interface management. Background Technology

[0002] Current web system firewall technology mainly revolves around three major directions: dynamic interface protection, access control, and threat detection, forming a technical system centered on automated rule generation, abnormal behavior identification, and malicious entity blocking.

[0003] For interface management: Interfaces not in the firewall need to be manually identified.

[0004] Regarding the dynamism of rules: protection rules require manual intervention to update, resulting in poor timeliness.

[0005] Regarding threat identification: Attackers can easily bypass IP-based detection mechanisms by switching IP addresses.

[0006] In summary, existing web system firewall technologies have significant shortcomings in core dimensions such as interface management, rule dynamism, and threat identification, resulting in poor protection and difficulty in coping with the current complex network attack environment. Summary of the Invention

[0007] In view of the deficiencies in the existing technology, the technical problem to be solved by this application is: how to improve the protection effect of the Web system through interface-based management.

[0008] To achieve the above objectives, in a first aspect, embodiments of this application provide a web system protection method based on interface management, the method comprising the following steps: After identifying and updating the security interfaces in real time, the protection rules are updated synchronously based on the updated security interfaces. Interfaces that do not exist in the protection rules are identified as abnormal interfaces, and the abnormal IPs are determined based on the IPs corresponding to the abnormal interfaces.

[0009] In conjunction with the first aspect, in one implementation, the process of determining and updating the security interface in real time includes: The system interfaces are obtained by traversing the server program; Once an interface update is detected, the security interface is updated synchronously.

[0010] In conjunction with the first aspect, in one implementation, the process for creating the protection rule includes: Map security interfaces to interface key-value pairs, create protection rules based on all interface key-value pairs, and cache them.

[0011] In conjunction with the first aspect, in one implementation, the process of synchronously updating the protection rules according to the updated security interface after determining and updating the security interface in real time includes: For newly added interfaces, add them to the protection rules; For obsolete interfaces, remove them from the protection rules; For interfaces that have undergone information changes, update the corresponding interfaces in the protection rules based on the changed information.

[0012] In conjunction with the first aspect, in one implementation, the method further includes the following steps: Based on the number of abnormal accesses to the security interface, a corresponding hierarchical protection scheme is formed, and the hierarchical protection scheme is added to the protection rules.

[0013] In conjunction with the first aspect, in one implementation, the graded protection scheme includes: Warning status: When a number of abnormal access behaviors occur consecutively within a specified time period, an abnormal log is recorded and the IP address is flagged; Blocked status: When a warning status is in effect and a number of abnormal access behaviors occur within a specified period of time; or when a warning status is in effect and a number of abnormal access behaviors occur consecutively, the interface corresponding to the abnormal access behavior will be determined as an abnormal interface, and the IP address corresponding to the abnormal interface will be determined as an abnormal IP address.

[0014] In conjunction with the first aspect, in one implementation, the process of determining the IP corresponding to the abnormal interface as an abnormal IP includes: adding the abnormal IP to the blacklist and setting the blocking duration according to the dynamic gradient policy settings; the more times the abnormal access behavior occurs, the longer the blocking duration; when no abnormal access behavior occurs within the blocking duration, the abnormal IP and abnormal interface are marked as normal.

[0015] In conjunction with the first aspect, in one implementation, the hierarchical protection scheme is implemented through a state machine, the core states of which include the warning state and the blocking state; the addition of abnormal IPs to the blacklist and the setting of the blocking duration are implemented through a sliding time window.

[0016] Secondly, embodiments of this application provide a web system protection device based on interface management. The web system protection device based on interface management includes a processor, a memory, and a web system protection program based on interface management stored in the memory and executable by the processor. When the web system protection program based on interface management is executed by the processor, it implements the method provided in the first aspect.

[0017] Thirdly, embodiments of this application provide a computer-readable storage medium storing an interface-managed web system protection program, which, when executed, implements the method provided in the first aspect.

[0018] Compared with the prior art, the advantages of this application are: Compared to traditional firewalls that rely on manually configured static rule bases and generally suffer from rule update delays, this application updates security interfaces in real time. That is, it achieves real-time updates of protection rules through dynamic interface scanning technology. In this case, interfaces and IPs that do not exist in the protection rules will be included in the blacklist. This high-frequency update mechanism and intelligent dynamic blacklist method can work together to ensure the accuracy of IP blacklists and whitelists, fundamentally avoiding the defect of "asynchronous attack and defense" in traditional static configuration. Attached Figure Description

[0019] To more clearly illustrate the technical solutions in the embodiments of this application, the accompanying drawings used in the description of the embodiments will be briefly introduced below. Obviously, the accompanying drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0020] Figure 1 This is a schematic diagram of the state machine's workflow in an embodiment of this application; Figure 2 This is a schematic diagram of the hardware structure of the WEB system protection device based on interface management involved in the embodiments of this application. Detailed Implementation

[0021] To make the objectives, technical solutions, and advantages of the embodiments of this application clearer, the technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0022] The flowchart shown in the attached diagram is for illustrative purposes only and does not necessarily include all content and operations / steps, nor does it necessarily have to be performed in the order described. For example, some operations / steps can be broken down, combined, or partially merged, so the actual execution order may change depending on the actual situation.

[0023] First, the research and development process of this application will be described to enable those skilled in the art to understand this application.

[0024] Current status of dynamic interface scanning and rule matching technology Dynamic interface scanning technology generates protection rules by automatically analyzing the characteristics of web applications, and is one of the core capabilities of Web Application Firewalls (WAFs).

[0025] Existing technologies automatically generate WAF rules by analyzing web application data elements (focusing on the automated generation logic of rules) and support rule recommendations based on data types. The innovation lies in realizing a direct mapping from application data to protection rules. However, this method relies on static data element analysis, and rule updates require restarting the service, which has limitations in terms of dynamism and real-time performance.

[0026] To address this issue, we optimized the system by using the Hyperscan regular expression matching library to improve the rule matching performance of the Nginx+Lua module. We also implemented dynamic rule updates through shared memory (focusing on dynamic deployment and high-performance matching of rules in the production environment), reducing the rule activation time from minutes to milliseconds. At the same time, we reduced the single rule matching latency by more than 60%, significantly improving the rule processing efficiency in high-concurrency scenarios.

[0027] The two technologies mentioned above represent the optimization directions of the "generation end" and "execution end" in rule engineering, respectively, but neither of them solves the problem of dynamic binding between rules and interface legality baselines.

[0028] Limitations of Nginx+Lua access control technology The Nginx+Lua architecture is widely used in distributed access control scenarios due to its lightweight and scalability, but it has significant limitations in the completeness of interface security protection. A login verification scheme published on a CSDN blog shows that this technology achieves distributed single sign-on by parsing the token in a cookie using Lua scripts. Its core logic focuses on user authentication and does not involve verifying the legitimacy of the interface itself. While it identifies automated attacks by aggregating and analyzing interface access behavior sequences and establishes an abnormal behavior model, this model only focuses on abnormal behavior patterns and does not correlate this with whether the interface belongs to a predefined list of legitimate interfaces.

[0029] The core limitation of existing technologies lies in the lack of a "API legitimacy-IP blacklist" linkage mechanism: traditional API access control processes typically make independent judgments in the order of "enabled status → IP whitelist → call limit." For example, in one solution, API calls need to pass enabled status checks, IP whitelist verification, and frequency limits in sequence, but the IP blacklist is not bound to API legitimacy—that is, for IPs clearly marked as malicious, even if they access a legitimate API and have a valid token, they may still be allowed access due to the fragmented rules. This independent judgment logic allows attackers to bypass IP blacklist restrictions by forging legitimate tokens or accessing public APIs, creating a security vulnerability.

[0030] Regarding malicious IP handling, while there are technologies such as dynamic blacklist generation based on historical behavior, setting blocking durations according to attack type, and compressing IP query latency to milliseconds using radix tree storage, these technologies operate as independent modules and do not form a closed-loop control with interface legitimacy verification, thus weakening the overall synergy of protection.

[0031] In summary, existing technologies have room for improvement in three dimensions: rule dynamism, access control coordination, and intelligent parsing capabilities, providing a clear direction for innovation for the "strict firewall technology based on interface management" proposed in this application.

[0032] Furthermore, a detailed analysis will be conducted from the perspective of technology categories: The lack of a dynamic discovery and management mechanism for interfaces Existing technologies have fundamental shortcomings in terms of interface asset coverage and automated management. On the one hand, service interfaces rely on manual addition and maintenance, and cannot automatically detect runtime interface changes, resulting in the long-term existence of "unmanaged assets" such as shadow interfaces and zombie interfaces, creating security blind spots. For example, relying on predefined regular expressions for interface matching lacks the ability to automatically discover interfaces based on traffic characteristics, and cannot adapt to modern application scenarios with frequent interface iterations.

[0033] On the other hand, unauthorized interface detection methods are rigid. Traditional scanners cannot automatically extract website interfaces and initiate targeted scans, and their configuration flexibility is insufficient, making it difficult to simulate access rules in real business environments, leading to the exposure of high-risk interfaces.

[0034] Key pain points: Insufficient coverage of interface assets due to reliance on manual intervention, static rules cannot adapt to dynamic interface environments, and the degree of automation in unauthorized interface detection is low.

[0035] Static rules and configuration lag bottleneck Traditional firewall rule management generally suffers from the "static fixation" flaw, meaning it generates rules through static code analysis, failing to capture runtime interface changes in real time. Rule updates require manual intervention, resulting in extremely poor timeliness. Similarly, iptables rule sets are fixed after being loaded at startup; any modification requires reapplying the entire rule set, potentially causing brief network outages. The Web Application Firewall (WAF) domain also faces rule maintenance challenges. Rule creation requires manual guessing of page field names and allowed values, leading to a sharp increase in the risk of rule invalidation as applications iterate, and persistently high false positive and false negative rates, forcing security teams to invest significant effort in manual adjustments.

[0036] Dynamic IP and blacklist mechanisms fail The conflict between dynamic IP allocation and static blacklist systems is becoming increasingly prominent. Attackers can easily bypass IP-based detection mechanisms by switching IP addresses, leading to the misjudgment of legitimate traffic from old IPs and the failure to detect malicious activity from new IPs. Meanwhile, the widespread use of NAT devices and HTTP proxies makes shared IP blacklists highly susceptible to false bans, resulting in denial of service for legitimate users. Traditional blacklist databases also suffer from outdated updates and limited coverage, making it difficult to cope with the trend of large-scale and professional attacks from cybercriminals, resulting in poor timeliness of protection.

[0037] Insufficient multi-tenancy support and architectural scalability Existing solutions are clearly ill-suited for complex deployment scenarios. On one hand, most firewall technologies do not support multi-tenancy and multi-application isolation, failing to meet the customized security needs of different tenants in cloud environments. On the other hand, interface configurations have hard limitations. For example, CDO does not support passive interfaces, ERSPAN interfaces, or transparent firewall modes; EtherChannel is affected by VLAN tagging, leading to LACPDU dropping; and bridge groups only support a single group with member interfaces requiring no IP address, severely limiting deployment flexibility in hybrid architectures. Furthermore, traditional API gateway solutions are too "heavyweight," requiring additional maintenance of independent components, resulting in high learning and deployment costs, making them unsuitable for small and medium-sized teams and small intranet systems.

[0038] Performance bottlenecks and threat response latency Firewalls exhibit significant shortcomings in stability and threat response efficiency under high-concurrency scenarios. While virtual WAFs, deployed on internal enterprise hardware, meet localized management needs, they are prone to resource exhaustion and failure during peak data traffic. Traditional WAFs employ a "full rule matching" model, performing complete rule verification on every request, resulting in low concurrency processing capabilities. At the threat response level, identifying abnormal access and hybrid attacks is difficult, and the discovery-response path is lengthy. For example, financial institutions struggle to identify API callers with security vulnerabilities in real time, leading to the risk of user data breaches.

[0039] Overall conclusion: Existing technologies have systemic deficiencies in the three core dimensions of dynamism, adaptability, and accuracy, and there is an urgent need to reconstruct the firewall technology system through full lifecycle management of interfaces, dynamic rule engines, and intelligent threat identification.

[0040] Based on this, in order to make the objectives, technical solutions and advantages of this application clearer, the embodiments of this application will be described in further detail below with reference to the accompanying drawings.

[0041] In a first aspect, embodiments of this application provide a web system protection method based on interface management, the steps of which include: After identifying and updating the security interface in real time (the update frequency is less than 40 seconds, and 30 seconds in this embodiment), the protection rules are updated synchronously according to the updated security interface. Interfaces that do not exist in the protection rules are identified as abnormal interfaces, and the abnormal IP is determined according to the IP corresponding to the abnormal interface. For example, when 1 to N interfaces belonging to the same IP are identified as abnormal interfaces, the IP is identified as an abnormal IP.

[0042] Therefore, compared with the static rule base that traditional firewalls rely on manual configuration and generally suffer from rule update delays, this application updates security interfaces in real time. That is, it achieves real-time updates of protection rules through dynamic interface scanning technology. In this case, interfaces and IPs that do not exist in the protection rules will be included in the blacklist. This high-frequency update mechanism and the intelligent dynamic blacklist method can work together to ensure the accuracy of IP blacklists and whitelists, and fundamentally avoid the defect of "asynchronous attack and defense" in traditional static configuration.

[0043] At the same time, the aforementioned dynamic interface scanning technology allows a single firewall to be used on multiple systems while updating protection rules based on the interfaces of each system. This eliminates the need for additional maintenance of independent components, reducing learning and deployment costs and making it suitable for small and medium-sized teams and small intranet systems.

[0044] In one embodiment, the process of determining and updating the security interface in real time includes: During the system startup phase, the system interfaces are obtained by traversing the server program; Once an interface update is detected, the security interface is updated synchronously.

[0045] The specific implementation method can be: During the system startup phase: By traversing the classes and methods annotated with @RestController and @Controller in the server program, metadata such as interface access address, request method (e.g., GET / POST), and service name is extracted.

[0046] During the interface update phase, after developers complete the interface publishing operation through the interface management platform, an incremental scan is triggered to synchronize the latest interface information.

[0047] In one embodiment, the process for creating the above-mentioned protection rules includes: Map security interfaces to interface key-value pairs, create protection rules based on all interface key-value pairs and cache them. Specifically, use Redis cache as the interface asset library, and store the scan results with the key {interface path}_{request method} (e.g., / api / user_GET) and the interface metadata (including the service to which it belongs, permission requirements, etc.) as the value.

[0048] Protection rules formed using key-value pairs can support millisecond-level query responses. Meanwhile, when protection is provided through cached protection rules, the interception speed is relatively fast.

[0049] In one embodiment, after determining and updating the security interface in real time, the process of synchronously updating the protection rules according to the updated security interface includes: For newly added interfaces, add them to the protection rules; For obsolete interfaces, remove them from the protection rules; For interfaces that have undergone information changes, update the corresponding interfaces in the protection rules based on the changed information.

[0050] The following is an example from a code perspective of determining and updating the security interface in real time, and then synchronously updating the protection rules based on the updated security interface.

[0051] Lua Validation: Real-time Request Interception Logic Integrating Lua modules into an Nginx service creates the first line of defense for request authentication. The core logic is implemented using two Lua scripts: URL matching logic By comparing the requested URL with the Redis cached API repository, unregistered API access can be identified. The code snippet is as follows: / / lua -- Retrieve the list of interfaces from Redis (Example: Assuming they have been loaded into shared memory via init_by_lua) local allowed_urls = ngx.shared.interface_cache:get("allowed_urls") local request_url = ngx.var.uri .. "_" .. ngx.req.get_method() -- URL Match Validation if not string.find(allowed_urls, request_url) then ngx.log(ngx.ERR, "Unregistered API access: ", request_url) ngx.exit(403) -- Intercepts unmatched requests end Blacklist lookup function By combining a dynamic blacklist database, malicious IPs are blocked in real time. The code snippet is as follows: / / lua -- Extract the client IP from the request local client_ip = ngx.var.remote_addr -- Query the Redis blacklist (key: "blacklist:{IP}", value: expiration timestamp) local blacklist_key = "blacklist:" .. client_ip local block_expire = redis_client:get(blacklist_key) if block_expire and tonumber(block_expire)>ngx.time() then ngx.log(ngx.ERR, "IP has been blocked: ", client_ip, ", remaining time: ", block_expire - ngx.time(), " seconds") ngx.exit(403) -- Blocks blacklisted IPs end The above logic is embedded in the Nginx configuration through the `access_by_lua_file` directive to achieve real-time verification for each request. The core time points are: Interface scan trigger time: Dynamic interface scan starts within 10 ms after the client initiates the first access request. The scan cycle is configurable (default 500 ms / scan).

[0052] • URL matching time: The dynamic interface scanner takes ≤20 ms to match the request URL with the preset interface rule base, including regular expression parsing and parameter format validation.

[0053] • Blacklist activation delay: When a request is determined to be malicious, the time it takes for the blacklist rules to be synchronized to the interception engine is less than 50ms, ensuring that the attack source is blocked in a short time.

[0054] Therefore, while addressing core functionalities, this application ensures business continuity under high concurrency scenarios through an Nginx+Lua module architecture. Referring to performance test data from China Telecom Cloud's patent, this architecture can support a stable processing speed of 30,000 requests per second (QPS) in a single-node configuration, representing a 275% improvement over the traditional WAF's rule-based full-match mode (approximately 8,000 QPS). Dynamic loading of protection rules further reduces rule matching overhead—loading targeted rules only for newly added interfaces, avoiding full rule traversal, and reducing the average request processing latency from 120ms to 35ms. This dual design of "precise protection + performance optimization" enables the solution to maintain a 99.99% interception accuracy rate while keeping business response speed within an acceptable range for users when dealing with DDoS attacks (traffic redirection to cloud platform filtering) and automated attacks (behavioral sequence feature identification).

[0055] In one embodiment, the above method further includes the following steps: Based on the number of abnormal accesses to the aforementioned security interfaces, a corresponding tiered protection scheme is formed, and the tiered protection scheme is added to the protection rules.

[0056] Therefore, compared with traditional IP blacklist mechanisms that only block IPs based on a single IP dimension and are prone to IP misses, this application provides IP protection through multiple dimensions, specifically: The first dimension verifies the match between the access interface and the secure interfaces (i.e., whitelisted interfaces) in the protection rules; The second dimension counts the number of abnormal visits; This can be achieved: Although the access interface is a secure interface, when abnormal access occurs to the interface and the number of abnormal accesses is not allowed, it will still be protected by a hierarchical protection scheme corresponding to the number of abnormal accesses.

[0057] Comparative experiments show that the above multi-dimensional protection mechanism can improve the F1-score from 0.72 in the traditional IP blacklist to 0.91, reducing the false alarm rate by 58%. This is better than the WAF rule intelligent optimization solution, which optimizes the false alarm rate through log analysis (average reduction of 45%).

[0058] Specifically, the tiered protection scheme based on the number of abnormal accesses to the aforementioned security interfaces includes: Normal state: When the number of abnormal accesses is 0, no protection is provided, that is, normal communication is allowed; Warning status: When a number of abnormal access behaviors occur consecutively within a specified time period (60s in this example, 3 times in this example), an abnormal log is recorded and the IP is marked; Blocking status: When the system is in a warning state and a certain number of abnormal access behaviors occur within a specified time period (60s in this embodiment, 2 times in this embodiment); or when the system is in a warning state and a certain number of abnormal access behaviors occur consecutively (5 times in this embodiment), the interface corresponding to the abnormal access behavior will be determined as an abnormal interface, and the IP corresponding to the abnormal interface will be determined as an abnormal IP and added to the blacklist.

[0059] Specifically, the statistics of the above-mentioned abnormal access behaviors can be implemented through a state machine, and the normal state, warning state and blocked state are the core states of the state machine.

[0060] Meanwhile, the process of identifying the IP corresponding to the abnormal interface as an abnormal IP and adding it to the blacklist includes: adding the abnormal IP to the blacklist and setting the blocking duration according to the dynamic gradient strategy settings, that is, the more times there is abnormal access behavior, the longer the blocking duration; when no abnormal access behavior occurs within the blocking duration, the abnormal IP and abnormal interface are marked as normal.

[0061] The above-mentioned setting of adding the abnormal IPs to the blacklist and setting the blocking duration based on the dynamic gradient strategy can be considered as an error count reset mechanism, implemented based on a sliding time window, specifically as follows: The Redis INCR command is used to record the number of errors, and an EXPIRE command is used to set a 60-second expiration time. If no errors occur within the window, the count is automatically reset. The ban duration follows a dynamic gradient strategy, with an initial blocking time of 15 minutes. If the error is triggered again within 24 hours, it will be extended to 1 hour. After accumulating 3 or more violations, the user will be banned for 1 day to reduce the risk of mistakenly banning legitimate users.

[0062] The implementation scheme of state machine combined with sliding time window in this embodiment is described in [reference needed]. Figure 1 As shown, specifically: Normal state (S0): Initial state, error count = 0. When an interface parameter error or permission verification failure occurs during a single access, the system jumps to the warning state (S1), and the error count is incremented by 1.

[0063] Warning state (S1): Error count ∈ [1, 4]. If the error count does not reach the threshold (5 times) within 30 seconds, it will automatically reset to S0; if the error count accumulates to 5 times, it will jump to the blacklist state (S2).

[0064] Blacklist Status (S2): Error count ≥ 5, triggering IP / URL blacklist rules. After continuous blocking for 5 minutes, automatically redirect to S0 and reset the error count, entering the observation period.

[0065] In summary, this application systematically solves the core problems of traditional Web firewalls, namely "static lag," "high false positive rate," and "poor adaptability to high concurrency," through collaborative innovation of dynamic rule updates, multi-dimensional accurate judgment, and high-performance architecture. Its technical advantages have been fully verified in scenarios such as API security management and automated attack protection.

[0066] Secondly, embodiments of this application provide a web system protection device based on interface management. The web system protection device based on interface management can be a personal computer (PC), a laptop, a server, or other device with data processing capabilities.

[0067] Reference Figure 2 , Figure 2 This is a schematic diagram of the hardware structure of the interface-managed web system protection device involved in the embodiments of this application. In the embodiments of this application, the interface-managed web system protection device may include a processor, a memory, a communication interface, and a communication bus.

[0068] The communication bus can be of any type and is used to interconnect the processor, memory, and communication interface.

[0069] Communication interfaces include input / output (I / O) interfaces, physical interfaces, and logical interfaces used for interconnecting devices within the interface-managed web system protection equipment, as well as interfaces used for interconnecting the interface-managed web system protection equipment with other devices (such as other computing devices or user equipment). Physical interfaces can be Ethernet interfaces, fiber optic interfaces, ATM interfaces, etc.; user equipment can be displays, keyboards, etc.

[0070] Memory can be various types of storage media, such as random access memory (RAM), read-only memory (ROM), non-volatile RAM (NVRAM), flash memory, optical storage, hard disk, programmable ROM (PROM), erasable PROM (EPROM), electrically erasable PROM (EEPROM), etc.

[0071] The processor can be a general-purpose processor, which can call the interface-managed WEB system protection program stored in memory and execute the interface-managed WEB system protection method provided in the embodiments of this application. For example, the general-purpose processor can be a central processing unit (CPU). The method executed when the interface-managed WEB system protection program is called can be referred to the various embodiments of the interface-managed WEB system protection method of this application, and will not be repeated here.

[0072] Those skilled in the art will understand that Figure 2 The hardware structure shown does not constitute a limitation of this application and may include more or fewer components than shown, or combine certain components, or have different component arrangements.

[0073] Thirdly, embodiments of this application also provide a computer-readable storage medium.

[0074] The computer-readable storage medium of this application stores an interface-managed WEB system protection program, wherein when the interface-managed WEB system protection program is executed by a processor, it implements the steps of the interface-managed WEB system protection method described above.

[0075] The method implemented when the interface-managed WEB system protection program is executed can be referred to in the various embodiments of the interface-managed WEB system protection method of this application, and will not be repeated here.

[0076] It should be noted that the sequence numbers of the embodiments in this application are for descriptive purposes only and do not represent the superiority or inferiority of the embodiments.

[0077] The terms "comprising" and "having," and any variations thereof, in the specification, claims, and accompanying drawings of this application are intended to cover non-exclusive inclusion. For example, a process, method, system, product, or apparatus that includes a series of steps or units is not limited to the listed steps or units, but may optionally include steps or units not listed, or may optionally include other steps or units inherent to such process, method, product, or apparatus. The terms "first," "second," and "third," etc., are used to distinguish different objects, etc., and do not indicate a sequence, nor do they limit "first," "second," and "third" to different types.

[0078] In the description of the embodiments of this application, terms such as "exemplary," "for example," or "for instance" are used to indicate examples, illustrations, or explanations. Any embodiment or design described as "exemplary," "for example," or "for instance" in the embodiments of this application should not be construed as being more preferred or advantageous than other embodiments or designs. Specifically, the use of terms such as "exemplary," "for example," or "for instance" is intended to present the relevant concepts in a concrete manner.

[0079] In the description of the embodiments of this application, unless otherwise stated, " / " means "or". For example, A / B can mean A or B. The "and / or" in the text is merely a description of the relationship between related objects, indicating that there can be three relationships. For example, A and / or B can mean: A exists alone, A and B exist simultaneously, and B exists alone. In addition, in the description of the embodiments of this application, "multiple" means two or more.

[0080] In some processes described in the embodiments of this application, multiple operations or steps are included in a specific order. However, it should be understood that these operations or steps may not be executed in the order they appear in the embodiments of this application, or they may be executed in parallel. The sequence number of the operation is only used to distinguish different operations, and the sequence number itself does not represent any execution order. In addition, these processes may include more or fewer operations, and these operations or steps may be executed sequentially or in parallel, and these operations or steps may be combined.

[0081] Through the above description of the embodiments, those skilled in the art can clearly understand that the methods of the above embodiments can be implemented by means of software plus necessary general-purpose hardware platforms. Of course, they can also be implemented by hardware, but in many cases the former is a better implementation method. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, can be embodied in the form of a software product. This computer software product is stored in a storage medium (such as ROM / RAM, magnetic disk, optical disk) as described above, and includes several instructions to cause a terminal device to execute the methods described in the various embodiments of this application.

[0082] The above are merely specific embodiments of this application, but the protection scope of this application is not limited thereto. Any person skilled in the art can easily conceive of various equivalent modifications or substitutions within the technical scope disclosed in this application, and these modifications or substitutions should all be covered within the protection scope of this application. Therefore, the protection scope of this application should be determined by the scope of the claims.

Claims

1. A web system protection method based on interface management, characterized in that, The method includes the following steps: After identifying and updating the security interfaces in real time, the protection rules are updated synchronously based on the updated security interfaces. Interfaces that do not exist in the protection rules are identified as abnormal interfaces, and the abnormal IPs are determined based on the IPs corresponding to the abnormal interfaces.

2. The web system protection method based on interface management as described in claim 1, characterized in that, The process of determining and updating the security interface in real time includes: The system interfaces are obtained by traversing the server program; Once an interface update is detected, the security interface is updated synchronously.

3. The web system protection method based on interface management as described in claim 1, characterized in that, The process for creating the protection rules includes: Map security interfaces to interface key-value pairs, create protection rules based on all interface key-value pairs, and cache them.

4. The web system protection method based on interface management as described in claim 1, characterized in that, The process of determining and updating the security interface in real time, and then synchronously updating the protection rules according to the updated security interface, includes: For newly added interfaces, add them to the protection rules; For obsolete interfaces, remove them from the protection rules; For interfaces that have undergone information changes, update the corresponding interfaces in the protection rules based on the changed information.

5. The web system protection method based on interface management as described in claim 1, characterized in that, The method also includes the following steps: Based on the number of abnormal accesses to the security interface, a corresponding hierarchical protection scheme is formed, and the hierarchical protection scheme is added to the protection rules.

6. The web system protection method based on interface management as described in claim 5, characterized in that, The graded protection scheme includes: Warning status: When a number of abnormal access behaviors occur consecutively within a specified time period, an abnormal log is recorded and the IP address is flagged; Blocked status: When a warning status is in effect and a number of abnormal access behaviors occur within a specified period of time; or when a warning status is in effect and a number of abnormal access behaviors occur consecutively, the interface corresponding to the abnormal access behavior will be determined as an abnormal interface, and the IP address corresponding to the abnormal interface will be determined as an abnormal IP address.

7. The web system protection method based on interface management as described in claim 6, characterized in that, The process of determining the IP corresponding to the abnormal interface as an abnormal IP includes: adding the abnormal IP to the blacklist according to the dynamic gradient policy setting and setting the blocking duration. The more times the abnormal access behavior occurs, the longer the blocking duration will be; when no abnormal access behavior occurs within the blocking duration, the abnormal IP and abnormal interface will be marked as normal.

8. The web system protection method based on interface management as described in claim 7, characterized in that: The hierarchical protection scheme is implemented through a state machine, the core states of which include the warning state and the blocking state; the addition of abnormal IPs to the blacklist and the setting of the blocking duration are implemented through a sliding time window.

9. A web system protection device based on interface management, characterized in that, The interface-managed web system protection device includes a processor, a memory, and an interface-managed web system protection program stored in the memory and executable by the processor. When the interface-managed web system protection program is executed by the processor, it implements the steps of the interface-managed web system protection method as described in any one of claims 1 to 8.

10. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores an interface-managed web system protection program, wherein when the interface-managed web system protection program is executed, it implements the steps of the interface-managed web system protection method as described in any one of claims 1 to 8.

Images