Back-end intrusion protection method and device, storage medium and computer equipment

Abstract

According to the back-end intrusion protection method and device, the storage medium and the computer equipment provided by the invention, after it is monitored that the calling party initiates the API request, multi-feature verification including link and parameter semantic verification is performed on the API request by adopting the semantic map, the verification results can be divided into qualification, mild anomaly and severe anomaly, and the verification efficiency is improved. And a basis is provided for pertinence and flexibility of subsequent defense. For example, qualified API requests can be directly released; for a heavily abnormal API request, the API request can be directly intercepted; for the slightly abnormal API request, in order to reduce the possibility of misjudgment, the habit difference of different calling parties during API calling can be fully considered, multi-dimensional habit verification is performed on the API request through the exclusive behavior model corresponding to the calling party, then the abnormal score of the API request is determined based on the verification result, and the defense action corresponding to the abnormal score is triggered. Therefore, a stepped defense mechanism is formed, and the problem of excessive defense or insufficient defense is avoided.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of computers, and in particular to a backend intrusion protection method and device, a storage medium and a computer device. BACKGROUND

[0002] With the popularity of distributed architecture, distributed architecture is widely used, and API, as the core channel for the interaction between the backend service and the outside, plays a key role in many fields such as finance, e-commerce, and government affairs, and its call volume is also increasing day by day. However, API involves a large amount of user privacy and core business data, so its security protection is crucial.

[0003] However, with the continuous upgrading of attack means, the obvious defects of existing protection methods are gradually exposed. For example, the static token verification method only verifies the eligibility of the token and cannot identify the behavior difference between the calling subject and the token subject; the abnormal detection scheme based on the call frequency focuses on the number of calls and ignores the call link logic; the general behavior link detection scheme checks the link order but does not check the parameter relevance. In summary, the current protection method cannot comprehensively and accurately consider the multi-dimensional characteristics of the calling behavior, resulting in the inability to effectively protect the backend security. SUMMARY

[0004] The purpose of the present application is to at least solve one of the above technical defects, in particular the technical defect that the protection method in the prior art cannot comprehensively and accurately consider the multi-dimensional characteristics of the calling behavior, resulting in the inability to effectively protect the backend security.

[0005] The present application provides a backend intrusion protection method, which comprises:

[0006] In response to an API request initiated by a calling party, a preset semantic graph is used to perform link semantic verification and parameter semantic verification on the API request to obtain a first verification result; the first verification result includes qualified, mild abnormality and severe abnormality;

[0007] When the first verification result is qualified, the API request is directly released;

[0008] When the first verification result is severe abnormality, the API request is intercepted;

[0009] When the first verification result is mild abnormality, an exclusive behavior model of the calling party is obtained, and a multi-dimensional habit verification of the API request is performed through the exclusive behavior model to obtain a second verification result;

[0010] Based on the second verification result, an abnormal score of the API request is determined, and a defense action corresponding to the abnormal score is triggered.

[0011] Optionally, the constructing process of the semantic graph comprises:

[0012] An initial graph is constructed by taking each API as a node and taking the qualified calling relationship between the APIs as an edge.

[0013] API information of each API is injected into the node corresponding to the initial graph to form node attributes, and calling information between the APIs is injected into the edge corresponding to the initial graph to form edge attributes.

[0014] The initial graph with the injected attributes is marked as a semantic graph.

[0015] Optionally, the link semantic verification and the parameter semantic verification of the API request by using the preset semantic graph to obtain a first verification result comprises:

[0016] The unique identifier of the calling party and the request information of the API request are determined; the request information comprises an API path, a request parameter and a request time;

[0017] Based on the unique identifier, the API path and the request time, link semantic verification is performed by using the preset semantic graph to obtain a link verification result;

[0018] Based on the request parameter and the API path, parameter semantic verification is performed by using the semantic graph to obtain a parameter verification result;

[0019] The first verification result of the API request is determined according to the link verification result and the parameter verification result.

[0020] Optionally, the link semantic verification based on the unique identifier, the API path and the request time by using the preset semantic graph to obtain a link verification result comprises:

[0021] The historical request record of the unique identifier and the preceding calling API in the historical request record are obtained, and the preceding API corresponding to the API path is queried from the preset semantic graph;

[0022] It is determined whether the preceding calling API is consistent with the preceding API and the request time does not exceed a preset time window;

[0023] If yes, it is confirmed that the link verification result is normal;

[0024] If no, it is confirmed that the link verification result is abnormal.

[0025] Optionally, the parameter semantic verification based on the request parameter and the API path by using the semantic graph to obtain a parameter verification result comprises:

[0026] querying the pre-API parameters corresponding to the API path from the semantic graph;

[0027] determining whether the request parameters are consistent with the request parameters and meet the parameter constraint conditions;

[0028] if yes, confirming that the parameter verification result is normal;

[0029] if no, confirming that the parameter verification result is abnormal.

[0030] Optionally, the first verification result of the API request is determined according to the link verification result and the parameter verification result, comprising:

[0031] determining the verification type of the API request; the verification type includes mandatory and optional;

[0032] determining whether the link verification result and the parameter verification result are both normal;

[0033] if yes, confirming that the first verification result of the API request is qualified;

[0034] if no, confirming that the first verification result of the API request is slight abnormality when the verification type is optional, and confirming that the first verification result of the API request is heavy abnormality when the verification type is mandatory.

[0035] Optionally, the second verification result is obtained by performing multi-dimensional habit verification on the API request through the exclusive behavior model, comprising:

[0036] determining the time habit data, link habit data and parameter habit data of the calling party through the exclusive behavior model, and obtaining the request time, API path and request parameters of the API request;

[0037] performing time habit verification based on the time habit data and the request time to obtain a time habit verification result;

[0038] performing link habit verification based on the link habit data and the API path to obtain a link habit verification result;

[0039] performing parameter habit verification based on the parameter habit data and the request parameters to obtain a parameter habit verification result;

[0040] generating a second verification result according to the time habit verification result, the link habit verification result and the parameter habit verification result.

[0041] Optionally, the determining of the exception score of the API request based on the second check result comprises:

[0042] respectively determining exception weights of the time habit, the link habit and the parameter habit;

[0043] adding the exception weights of the habits with the check result being exception, to obtain the exception score of the API request.

[0044] The application further provides a backend intrusion protection device, comprising:

[0045] a first check module, configured to, in response to an API request initiated by a calling party, perform link semantic check and parameter semantic check on the API request by using a preset semantic atlas, to obtain a first check result; the first check result comprises qualified, slight exception and severe exception;

[0046] a request release module, configured to, when the first check result is qualified, directly release the API request;

[0047] a request interception module, configured to, when the first check result is severe exception, intercept the API request;

[0048] a second check module, configured to, when the first check result is slight exception, acquire an exclusive behavior model of the calling party, and perform multi-dimensional habit check on the API request by using the exclusive behavior model, to obtain a second check result;

[0049] a request defense module, configured to determine an exception score of the API request based on the second check result, and trigger a defense action corresponding to the exception score.

[0050] The application further provides a storage medium, wherein the storage medium stores computer readable instructions, and the computer readable instructions are executed by one or more processors to enable the one or more processors to perform the steps of the backend intrusion protection method according to any one of the above embodiments.

[0051] The application further provides a computer device, comprising one or more processors and a memory.

[0052] The memory stores computer readable instructions, and the computer readable instructions are executed by the one or more processors to perform the steps of the backend intrusion protection method according to any one of the above embodiments.

[0053] As can be seen from the above technical solutions, the embodiments of the application have the following advantages:

[0054] The backend intrusion protection method, device, storage medium and computer device provided by the application can perform multi-feature checking on the API request by using a preset semantic graph after monitoring that the calling party initiates the API request, including link semantic checking and parameter semantic checking, to obtain a first checking result. The first checking result can be divided into qualified, mild abnormality and severe abnormality, which provides a basis for the pertinence and flexibility of subsequent defense. For example, for a qualified API request, it can be directly released to ensure that normal business requests can pass quickly; for a severe abnormality API request, it can be directly intercepted to prevent potential high-risk attack behavior at the first time; and for a mild abnormality API request, to reduce the possibility of misjudgment, the differences of different calling parties when calling the API can be fully considered here, multi-dimensional habit checking of the API request is performed through the exclusive behavior model corresponding to the calling party to obtain a second checking result, then the abnormal score of the API request can be determined based on the second checking result, and the defense action corresponding to the abnormal score is triggered, so as to form a ladder defense mechanism, avoiding the problems of excessive defense or insufficient defense. BRIEF DESCRIPTION OF DRAWINGS

[0055] In order to more clearly illustrate the technical solutions in the embodiments of the present application or the prior art, the drawings needed to be used in the embodiments or prior art description will be briefly introduced. Obviously, the drawings in the following description only constitute some embodiments of the present application, and for those skilled in the art, other drawings can be obtained without creative labor.

[0056] Figure 1 A flowchart of a backend intrusion protection method provided by an embodiment of the present application;

[0057] Figure 2 A structural diagram of a backend intrusion protection device provided by an embodiment of the present application;

[0058] Figure 3 An internal structure diagram of a computer device provided by an embodiment of the present application. DETAILED DESCRIPTION

[0059] The technical solutions in the embodiments of the present application will be described clearly and completely in combination with the drawings in the embodiments of the present application. Obviously, the described embodiments only constitute some embodiments of the present application, not all embodiments. Based on the embodiments in the present application, all other embodiments obtained by those skilled in the art without creative labor are within the scope of protection of the present application.

[0060] As attack methods continue to evolve, the obvious shortcomings of existing protection methods are becoming increasingly apparent. For example, static token verification methods only verify the token's validity and cannot identify behavioral differences between the caller and the token holder; anomaly detection schemes based on call frequency focus on the number of calls but ignore the call chain logic; general behavior chain detection schemes verify the chain order but not the parameter correlation. In short, current protection methods cannot comprehensively and accurately consider the diverse characteristics of call behavior, thus failing to effectively guarantee backend security.

[0061] Based on this, this application proposes the following technical solution, as detailed below:

[0062] In one embodiment, such as Figure 1 As shown, Figure 1 This is a flowchart illustrating a backend intrusion prevention method provided in an embodiment of this application; this application provides a backend intrusion prevention method, specifically including the following:

[0063] S110: In response to the API request initiated by the caller, perform link semantic verification and parameter semantic verification on the API request using a preset semantic graph to obtain the first verification result; the first verification result includes qualified, slightly abnormal and severely abnormal.

[0064] In this step, after detecting that the caller has initiated an API request, the computer device can use a preset semantic graph to perform multi-feature verification on the API request, including link semantic verification and parameter semantic verification, to obtain the first verification result. The first verification result can be divided into qualified, slightly abnormal and severely abnormal, providing a basis for the targeted and flexible nature of subsequent defense.

[0065] Semantic graphs refer to a knowledge-based structural model used to represent the logical relationships and semantic constraints between APIs. It provides structured knowledge support for semantic understanding of API calls, link consistency verification, and parameter dependency analysis.

[0066] Specifically, by integrating the API call chain logic, parameter semantic relationships, and business context information from the semantic graph, computer devices can perform chain semantic verification and parameter semantic verification on API requests initiated by the caller. Chain semantic verification can be used to determine whether the current request's call path matches the predefined business call logic in the system, thereby identifying abnormal call chains or potential forged access. Parameter semantic verification can be used to analyze request parameters and their semantic dependencies, detecting issues such as incorrect parameter types, deviations in field meaning, or semantic inconsistencies.

[0067] Further, after multi-feature checking of the API request, the computer device can divide the checking result into three types: qualified, slight abnormality and severe abnormality, so as to realize more fine-grained security discrimination in the interface calling stage, so as to carry out targeted security response in the subsequent defense link, and prevent mis-interception or missed interception of the API request.

[0068] S120: When the first checking result is qualified, directly release the API request.

[0069] In this step, when the first checking result is qualified, the computer device can directly release the API request, ensuring that the normal business request can pass quickly.

[0070] It can be understood that when the first checking result is qualified, it means that the calling path, parameter semantics and timing characteristics of the API request are completely consistent with the standard specification recorded in the semantic graph, and the computer device can be sure that the request belongs to normal business behavior and there is no security risk or logical exception, so it can be directly released. After the API request is released, it will enter the back-end service for normal business processing flow, so as to ensure that the qualified interface call can be responded in the shortest path, avoiding system delay caused by redundant security verification or excessive interception, so as to improve the response speed of normal business request while effectively reducing the security verification burden of the system.

[0071] S130: When the first checking result is severe abnormality, intercept the API request.

[0072] In this step, when the first checking result is severe abnormality, the computer device can directly intercept the API request to prevent potential high-risk attack behavior in the first time.

[0073] It can be understood that when the first checking result is severe abnormality, it means that the semantic characteristics of the API request deviate significantly from the qualified calling chain, such as inconsistent calling path, incorrect key parameter mapping, or request initiated in illegal time window, etc. These characteristics usually correspond to high-risk attack behaviors such as interface forgery, session hijacking or logical intrusion. Therefore, the computer device can directly intercept the API request based on the security priority principle, block it before it enters the back-end service, significantly shorten the threat response time, and reduce the security risk diffusion range, so as to realize immediate defense and minimize security impact on potential attacks.

[0074] S140: When the first checking result is slight abnormality, obtain the exclusive behavior model of the calling party, and perform multi-dimensional habit checking on the API request through the exclusive behavior model to obtain a second checking result.

[0075] In this step, when the first verification result is determined to be slightly abnormal by step S110, in order to reduce the possibility of false interception, the application can fully consider the differences of different calling parties when calling the API, perform multi-dimensional habit verification on the API request through the exclusive behavior model corresponding to the calling party, and obtain a second verification result.

[0076] The exclusive behavior model refers to an individualized behavior characteristic model constructed for a specific calling party, which is used to depict the typical behavior pattern and semantic feature distribution of the calling party when calling the API in a normal business scenario. The model is usually trained and dynamically updated based on the historical API calling data of the calling party, and considers multi-dimensional features such as calling time habit, calling link habit and calling parameter habit, so as to form a statistical feature description and semantic portrait of the habit behavior of the calling party.

[0077] Specifically, when the first verification result is slightly abnormal, the computer device can use the exclusive behavior model of the calling party to perform similarity analysis or abnormal deviation detection on the current API request, to identify whether the slight abnormality of the first verification result belongs to the reasonable variation range of the calling party, and then generate a more accurate second verification result, so as to effectively reduce the probability of false interception caused by business policy changes or parameter fluctuations.

[0078] S150: determining an abnormal score of the API request based on the second verification result, and triggering a defense action corresponding to the abnormal score.

[0079] In this step, after obtaining the second verification result by step S140, the computer device can determine the abnormal score of the API request based on the second verification result, and trigger the defense action corresponding to the abnormal score, so as to form a step-by-step defense mechanism to avoid the problem of over-defense or under-defense.

[0080] Specifically, the computer device can further quantitatively evaluate the API request, comprehensively analyze the verification results of each habit dimension reflected in the second verification result, and then calculate the abnormal score of the request to realize the quantification of the potential risk level of the API request. Subsequently, the computer device can automatically match and trigger the corresponding defense action according to the distribution of the abnormal score in different intervals, such as monitoring record, risk alarm, secondary verification, permission freezing, etc., to realize the dynamic hierarchical response of the defense strategy.

[0081] In a specific embodiment, the score range of the anomaly score of the present application can be between [0, 1.0]. Wherein, when the anomaly score is 0, it means qualified, which corresponds to the triggered defense action of directly releasing to the backend service, and synchronously recording the log; when the anomaly score is [0.1, 0.5], it means mild anomaly, which corresponds to the triggered defense action of requiring secondary verification, and only allowing 3 retries, and failing to upgrade the defense; when the anomaly score is [0.6, 1.0], it means severe anomaly, which corresponds to the triggered defense action of temporarily freezing the API permission according to the anomaly score, and pushing the alarm to the administrator.

[0082] For example, when the second verification result is qualified, the API request is directly forwarded to the backend service, and the "qualified request" log is recorded; when the second verification result is mild anomaly, the gateway returns "verification SMS code is required", the caller inputs correctly and is released, and the permission is frozen for 1 hour for 3 errors; when the second verification result is severe anomaly, the API permission is frozen for 2 hours, and an alarm SMS is sent to the administrator, including user ID and anomaly details and other information.

[0083] Further, when the caller's permission is temporarily frozen, a thawing application can be initiated, such as an employee contacting the administrator, manually thawing by the administrator, or automatically thawing by the system after the freezing period expires. In addition, if the same caller triggers 3 severe anomalies within 24 hours, the alarm is automatically upgraded, such as changing from SMS alarm to phone alarm, and the freezing time is extended, such as from 2 hours to 24 hours.

[0084] In the above embodiment, after monitoring that the caller initiates an API request, a preset semantic graph can be used to perform multi-feature verification on the API request, including link semantic verification and parameter semantic verification, to obtain a first verification result. The first verification result can be divided into qualified, mild anomaly and severe anomaly, which provides a basis for the pertinence and flexibility of subsequent defense. For example, for a qualified API request, it can be directly released to ensure that normal business requests can pass quickly; for a severe anomaly API request, it can be directly intercepted to prevent potential high-risk attack behavior at the first time; and for a mild anomaly API request, to reduce the possibility of misjudgment, the differences between different callers when calling the API can be fully considered, a multi-dimensional habit verification of the API request is performed through the exclusive behavior model corresponding to the caller to obtain a second verification result, and then the anomaly score of the API request can be determined based on the second verification result, and the defense action corresponding to the anomaly score is triggered, thereby forming a step-by-step defense mechanism to avoid the problems of excessive defense or insufficient defense.

[0085] In an embodiment, the construction process of the semantic graph in step S110 can include:

[0086] S111: Take each API as a node, and take the qualified calling relationship between each API as an edge to construct an initial graph.

[0087] S112: Inject API information of each API into a node corresponding to the initial graph to form node attributes, and inject calling information between each API into an edge corresponding to the initial graph to form edge attributes.

[0088] S113: Mark the initial graph after injecting attributes as a semantic graph.

[0089] In this embodiment, when constructing the semantic graph, the computer device can take each API as a node, take the qualified calling relationship between each API as an edge to construct an initial graph, then inject API information of each API into a node corresponding to the initial graph to form node attributes, and inject calling information between each API into an edge corresponding to the initial graph to form edge attributes, and finally mark the initial graph after injecting attributes as a semantic graph, and store it using a Neo4j graph database or MySQL.

[0090] It can be understood that in the semantic graph, a node represents an API, and its node attributes can include an API unique identifier, an API type, and a parameter list, etc. For example, in one of the nodes, the API unique identifier can be / api / order / create, the API type can be core or non-core, / api / order / create is core, and the parameter list can include product_id, user_id, and amount. An edge represents a qualified calling relationship between two APIs, and its edge attributes can include calling order, associated parameter mapping, and a time window, etc. For example, in one of the edges, the calling relationship is API_A→API_B, indicating that A is a pre-API of B, and in their associated parameter mapping, the product_id of API_A needs to be consistent with the product_id of API_B. In addition, there is a 30-minute time window after API_A is called, during which API_B can be called, and the link will be invalid if the time is exceeded.

[0091] For example, taking the e-commerce "product query→add to cart→order" link as an example, the nodes and edges of the semantic graph can be represented as follows:

[0092] Node 1: API= / api / product / query, parameters=product_id, user_id, type=non-core;

[0093] Node 2: API= / api / cart / add, parameters=product_id, user_id, quantity, type=non-core;

[0094] Node 3: API= / api / order / create, parameters=product_id, user_id, amount, type=core;

[0095] Edge 1: Node 1→Node 2, attribute=30min time window, no parameter mapping, that is, the product_id of the added product can be consistent with the query or be new;

[0096] Edge 2: Node 2→Node 3, attribute=15min time window, parameter mapping=Node 2.product_id=Node 3.product_id.

[0097] Specifically, when building a semantic graph, an administrator can directly input business rules through a configuration terminal, and then the computer device automatically converts the business rules into "node-edge-attribute" of the semantic graph. In an e-commerce scenario, the configuration items of the semantic graph can be represented as follows:

[0098]

[0099] After the administrator inputs the above configuration items in the configuration terminal, the computer device can automatically synchronize the business rules and cache them through Redis to ensure low-latency reading. In addition, when the business rules are updated, such as adding a "coupon API" to the order link, the computer device can automatically trigger incremental updates without restarting the gateway, avoiding business interruption.

[0100] In one embodiment, the process of adopting a preset semantic graph to perform link semantic verification and parameter semantic verification on the API request in step S110 to obtain a first verification result can include:

[0101] S114: Determine the unique identifier of the calling party and the request information of the API request; the request information includes API path, request parameters, and request time.

[0102] S115: Based on the unique identifier, API path, and request time, perform link semantic verification using the preset semantic graph to obtain a link verification result.

[0103] S116: Based on the request parameters and API path, perform parameter semantic verification using the semantic graph to obtain a parameter verification result.

[0104] S117: Determine the first verification result of the API request according to the link verification result and the parameter verification result.

[0105] In this embodiment, when performing multi-feature semantic verification, the computer device can first determine the unique identifier of the calling party and the request information of the API request; the request information includes the API path, the request parameter and the request time. Based on this, the computer device can perform link semantic verification based on the unique identifier, the API path and the request time using the preset semantic graph to obtain a link verification result, and perform parameter semantic verification based on the request parameter and the API path using the semantic graph to obtain a parameter verification result, and then determine a first verification result of the API request according to the link verification result and the parameter verification result.

[0106] It can be understood that, through the unique identifier of the calling party and the API path, request parameter and request time of the API request, the computer device can explicitly determine the source subject, calling target and occurrence timing of the API request, laying a foundation for subsequent semantic correlation analysis. For example, based on the unique identifier, API path and request time, and in combination with the semantic graph for link semantic verification, the computer device can determine whether the calling behavior conforms to the qualified calling link and time constraint defined by the system, and identify whether there is an unauthorized calling, incorrect calling sequence or abnormal timing access; based on the request parameter and API path, and in combination with the semantic graph for parameter semantic verification, the computer device can analyze the matching relationship between the parameter value and the expected semantics, detect whether the parameter type, meaning or dependency mapping conforms to the specification, and thus identify potential parameter forgery, injection or tampering risks.

[0107] In one embodiment, the process of performing link semantic verification based on the unique identifier, API path and request time using the preset semantic graph to obtain a link verification result in step S115 can include:

[0108] S1151: Obtain the historical request record of the unique identifier and the previous calling API in the historical request record, and query the previous API corresponding to the API path from the preset semantic graph.

[0109] S1152: Determine whether the previous calling API is consistent with the previous API and the request time does not exceed the preset time window.

[0110] S1153: If yes, it is confirmed that the link verification result is normal.

[0111] S1154: If no, it is confirmed that the link verification result is abnormal.

[0112] In this embodiment, during link checking, the computer device can first obtain the historical request record of the calling party and the preceding API in the historical request record through the unique identifier, and query the preceding API corresponding to the API path from the preset semantic graph; if the preceding API and the preceding API are consistent and the request time does not exceed the preset time window, the computer device can confirm that the link checking result is normal, otherwise, the computer device can confirm that the link checking result is abnormal.

[0113] Specifically, taking an API request initiated by a calling party as an example, the unique identifier ID of the calling party is 1001, the API path of the API request is / api / order / create, and the request time is 2024-10-01 09:10:00. During link checking, the computer device can first query the preceding API of / api / order / create from the semantic graph, that is, / api / cart / add, and can obtain the historical request record of user 1001 from Redis, and the API called by the user 1001 most recently is used as the preceding API. If the calling result does not find the preceding API or the preceding API is inconsistent with the preceding API, the computer device can trigger a link checking exception; if the calling result finds that the preceding API is consistent with the preceding API, but the request time exceeds the preset time window of the preceding API, the computer device can also trigger a link checking exception; only when the preceding API is consistent with the preceding API and the request time does not exceed the preset time window of the preceding API, the computer device can confirm that the link checking is normal.

[0114] For example, the API called by user 1001 most recently in the historical request record is "2024-10-01 09:05:00, API= / api / product / query, product_id=456", it can be seen that the calling party has not called the preceding API of / api / order / create, that is, / api / cart / add, which indicates that the link checking result of the API request initiated by the calling party is abnormal.

[0115] In one embodiment, the process of performing parameter semantic checking based on the request parameter and the API path using the semantic graph to obtain the parameter checking result in step S116 can include:

[0116] S1161: Query the preceding API parameter corresponding to the API path from the semantic graph.

[0117] S1162: Determine whether the request parameter is consistent with the request parameter and meets the parameter constraint condition.

[0118] S1163: If yes, confirm that the parameter checking result is normal.

[0119] S1164: If no, it is confirmed that the parameter verification result is abnormal.

[0120] In this embodiment, during the parameter verification, the computer device can query the pre-API parameters corresponding to the API path from the semantic graph. If the request parameters are consistent with the request parameters and meet the parameter constraint conditions, the computer device can confirm that the parameter verification result of the API request is normal, otherwise, the computer device can confirm that the parameter verification result of the API request is abnormal.

[0121] Specifically, taking an API request initiated by a calling party as an example, the API path of the API request is / api / order / create, the request parameter product_id=789, and the amount=1000. During the parameter verification, the computer device can query the edge corresponding to / api / order / create from the semantic graph, that is, cart / add→order / create, and obtain the parameter mapping rule cart.add.product_id=order.create.product_id. Based on this, the computer device can compare the request parameters of the API request with the pre-API parameters in the parameter mapping rule, if they are consistent, it can further verify the request parameters and the parameter constraint conditions, if the request parameters meet the parameter constraint conditions, it means that the parameter verification of the API request is normal, if the request parameters of the API request and the pre-API parameters in the parameter mapping rule are inconsistent or the request parameters do not meet the parameter constraint conditions, it means that the parameter verification of the API request is abnormal.

[0122] For example, the pre-API parameters queried by the computer device from the semantic graph are cart.add.product_id=456, and the request parameters product_id=789 of the calling party do not match, at this time, even if the amount=1000 meets the parameter constraint condition of ">0 and ≤10000", the parameter verification result of the API request of the calling party is still determined to be abnormal.

[0123] In one embodiment, the process of determining the first verification result of the API request according to the link verification result and the parameter verification result in step S117 can include:

[0124] S1171: Determine the verification type of the API request; the verification type includes mandatory and optional.

[0125] S1172: Determine whether the link verification result and the parameter verification result are both normal.

[0126] S1173: If yes, it is confirmed that the first check result of the API request is qualified.

[0127] S1174: If no, it is confirmed that the first check result of the API request is a slight abnormality when the check type is optional, and is a serious abnormality when the check type is mandatory.

[0128] In this embodiment, after obtaining the link check result and the parameter check result of the API request through the check, the computer device can directly confirm that the first check result of the API request is qualified when both the link check result and the parameter check result are normal. If any check result is abnormal, the computer device can determine the check type of the API request, which includes mandatory and optional; when the check type is optional, it is confirmed that the first check result is a slight abnormality; when the check type is mandatory, it is confirmed that the first check result is a serious abnormality.

[0129] It can be understood that when both the link check result and the parameter check result are determined to be normal, it means that the API request conforms to the qualified rules defined in the semantic graph in terms of call path, timing logic and parameter semantics, and therefore the computer device can directly confirm that the first check result is qualified, so as to quickly release the request and ensure efficient flow of normal business calls. When any check result is abnormal, the computer device further analyzes the check type corresponding to the abnormality to distinguish the potential impact degree on system security and business logic.

[0130] Specifically, the check type of the semantic check of the API request can include two types of mandatory and optional. The mandatory type corresponds to a system critical link or a core parameter, and its abnormality means that there may be a high-risk risk, such as business logic destruction, data leakage or unauthorized access; the optional type is usually used for non-core logic or weakly dependent parameters, and its abnormality usually does not directly affect the core business security. Therefore, when it is detected that the abnormal item belongs to the optional type, the computer device can mark the first check result as a slight abnormality to trigger subsequent behavior model analysis or dynamic review to avoid false interception due to slight deviation; and when the abnormal item belongs to the mandatory type, the first check result can be determined as a serious abnormality, and the computer device can immediately perform the interception operation to prevent the potential attack from further spreading.

[0131] In one embodiment, the process of performing multi-dimensional habit check on the API request through the exclusive behavior model in step S140 to obtain the second check result can include:

[0132] S141: determining the time habit data, link habit data and parameter habit data of the calling party through the exclusive behavior model, and obtaining the request time, API path and request parameter of the API request.

[0133] S142: Perform time habit verification based on the time habit data and the request time to obtain a time habit verification result.

[0134] S143: Perform link habit verification based on the link habit data and the API path to obtain a link habit verification result.

[0135] S144: Perform parameter habit verification based on the parameter habit data and the request parameter to obtain a parameter habit verification result.

[0136] S145: Generate a second verification result according to the time habit verification result, the link habit verification result, and the parameter habit verification result.

[0137] In this embodiment, before the personalized habit verification, the computer device can first obtain the request time, the API path, and the request parameter of the API request, and at the same time, confirm the time habit data, the link habit data, and the parameter habit data of the calling party through the exclusive behavior model. Based on these data, the computer device can perform time habit verification, link habit verification, and parameter habit verification on the API request respectively, and then can generate a second verification result according to each habit verification result.

[0138] Specifically, in an API request initiated by a calling party, the request time = 2024-10-01 20:00, the API path = / api / order / create, and the request parameter amount = 2500. Through the exclusive behavior model corresponding to the calling party, it can be queried that in the calling habit of the calling party, the time habit is 9:00-18:00, the link habit is “goods query -> add to cart -> order”, and the parameter habit is amount = 100-2000. Therefore, by comparing the two, it can be known that the request time of the calling party exceeds its time habit, the API path is “goods query -> order”, which does not match its link habit, and in addition, the request parameter exceeds its parameter habit, so the verification result can be obtained. The verification results of the time habit, the link habit, and the parameter habit of the calling party are all abnormal.

[0139] Further, when constructing the exclusive behavior model of the calling party, the computer device can obtain the historical calling log of the calling party and identify the core data of the three baseline dimensions of time, link, and parameter as the basic data for constructing the exclusive behavior model. Among them, the process of obtaining the calling habit data can be as follows:

[0140]

[0141] Furthermore, when a new caller, such as a newly added employee, lacks historical call logs that meet the model building requirements, the computer device can use a general behavioral model built from the call habits of all employees to perform personalized habit verification on the new caller's call requests. Once the new caller's call count meets the model building conditions, a corresponding exclusive behavioral model is built for them. In addition, the computer device can periodically retrieve the previous day's new logs and update the exclusive behavioral model daily. If a significant change is found in any caller's call habits, such as an employee's call time changing from "9:00-18:00" to "19:00-23:00," the exclusive behavioral model will be automatically updated after their call time has stabilized for 7 days.

[0142] In one embodiment, the process of determining the anomaly score of the API request based on the second verification result in step S150 may include:

[0143] S151: Determine the abnormal weights for time habits, link habits, and parameter habits respectively.

[0144] S152: Add up the abnormal weights of the habitual requests that have abnormal verification results to obtain the abnormal score of the API request.

[0145] In this embodiment, to avoid misjudging a single anomaly, after determining the verification results of each habit, the computer device can determine the anomaly weights of time habit, link habit, and parameter habit respectively, and then add up the anomaly weights of the habits whose verification results are abnormal to obtain the anomaly score of the API request.

[0146] For example, when the verification results of the time habit, link habit, and parameter habit of an API request are abnormal, the abnormal weight of each habit can be obtained. For example, the habit weight of the time habit is 0.2, the habit weight of the link habit is 0.3, and the habit weight of the parameter habit is 0.5. At this time, the total abnormal score of the API request is 0.2 + 0.3 + 0.5 = 1.0. Under this abnormal score, the computer device can determine that the request is severely abnormal.

[0147] The back-end intrusion protection device provided in the embodiments of this application is described below. The back-end intrusion protection device described below can be referred to in correspondence with the back-end intrusion protection method described above.

[0148] In one embodiment, such as Figure 2 As shown, Figure 2 This application provides a schematic diagram of a backend intrusion prevention device according to an embodiment of the present application; the present application also provides a schematic diagram of a backend intrusion prevention device, including a first verification module 210, a request allowing module 220, a request intercepting module 230, a second verification module 240, and the second verification module 240 specifically includes the following:

[0149] The first checking module 210 is configured to, in response to an API request initiated by a calling party, perform link semantic checking and parameter semantic checking on the API request by using a preset semantic graph, and obtain a first checking result; the first checking result includes qualified, slight abnormality and severe abnormality.

[0150] The request release module 220 is configured to, when the first checking result is qualified, directly release the API request.

[0151] The request interception module 230 is configured to, when the first checking result is severe abnormality, intercept the API request.

[0152] The second checking module 240 is configured to, when the first checking result is slight abnormality, obtain an exclusive behavior model of the calling party, and perform multi-dimensional habit checking on the API request by using the exclusive behavior model, and obtain a second checking result.

[0153] The request defense module 250 is configured to determine an abnormality score of the API request based on the second checking result, and trigger a defense action corresponding to the abnormality score.

[0154] In the above embodiment, after monitoring that the API request is initiated by the calling party, the preset semantic graph can be used to perform multi-feature checking on the API request, including link semantic checking and parameter semantic checking, to obtain the first checking result; the first checking result can be divided into qualified, slight abnormality and severe abnormality, which provides a basis for the pertinence and flexibility of subsequent defense. For example, for the qualified API request, the API request can be directly released to ensure that the normal business request can pass quickly; for the API request with severe abnormality, the API request can be directly intercepted to prevent potential high-risk attack behavior at the first time; and for the API request with slight abnormality, to reduce the possibility of misjudgment, the differences of different calling parties in calling API can be fully considered, the multi-dimensional habit checking on the API request is performed by using the exclusive behavior model corresponding to the calling party to obtain the second checking result, and then the abnormality score of the API request can be determined based on the second checking result, and the defense action corresponding to the abnormality score is triggered, so as to form a ladder type defense mechanism, and the problems of excessive defense or insufficient defense are avoided.

[0155] In one embodiment, the first checking module 210 can include:

[0156] The graph construction submodule is configured to construct an initial graph by taking each API as a node and taking the qualified calling relationship between the APIs as an edge.

[0157] The attribute injection submodule is configured to inject API information of each API into a node corresponding to the initial graph to form a node attribute, and inject calling information between the APIs into an edge corresponding to the initial graph to form an edge attribute.

[0158] The graph generation submodule is configured to mark the initial graph after the attribute injection as a semantic graph.

[0159] In an embodiment, the first verification module 210 can further include:

[0160] The data determination submodule is configured to determine a unique identifier of the calling party and request information of the API request; the request information includes an API path, request parameters and a request time.

[0161] The link verification submodule is configured to perform link semantic verification based on the unique identifier, the API path and the request time, using a preset semantic graph to obtain a link verification result.

[0162] The parameter verification submodule is configured to perform parameter semantic verification based on the request parameters and the API path, using the semantic graph to obtain a parameter verification result.

[0163] The result generation submodule is configured to determine a first verification result of the API request according to the link verification result and the parameter verification result.

[0164] In an embodiment, the link verification submodule can include:

[0165] The API acquisition unit is configured to acquire a historical request record of the unique identifier and a preceding calling API in the historical request record, and query a preceding API corresponding to the API path from the preset semantic graph.

[0166] The first judgment unit is configured to determine whether the preceding calling API is consistent with the preceding API and the request time does not exceed a preset time window.

[0167] The first result determination unit is configured to confirm that the link verification result is normal when the preceding calling API is consistent with the preceding API and the request time does not exceed the preset time window.

[0168] The second result determination unit is configured to confirm that the link verification result is abnormal when the preceding calling API is inconsistent with the preceding API and / or the request time exceeds the preset time window.

[0169] In an embodiment, the parameter verification submodule can include:

[0170] The parameter query unit is configured to query a preceding API parameter corresponding to the API path from the semantic graph.

[0171] The second judging unit is configured to judge whether the request parameter is consistent with the request parameter and meets the parameter constraint condition.

[0172] The third result confirming unit is configured to confirm that the parameter verification result is normal when the request parameter is consistent with the request parameter and meets the parameter constraint condition.

[0173] The fourth result confirming unit is configured to confirm that the parameter verification result is abnormal when the request parameter is inconsistent with the request parameter and / or does not meet the preset parameter constraint.

[0174] In an embodiment, the result generating submodule can include:

[0175] The type determining unit is configured to determine the verification type of the API request; the verification type includes mandatory and optional.

[0176] The third judging unit is configured to judge whether the link verification result and the parameter verification result are both normal.

[0177] The first result determining unit is configured to confirm that the first verification result of the API request is qualified when the link verification result and the parameter verification result are both normal.

[0178] The second result determining unit is configured to confirm that the first verification result of the API request is slightly abnormal when the verification type is optional and the link verification result and / or the parameter verification result is not normal, and confirm that the first verification result of the API request is severely abnormal when the verification type is mandatory.

[0179] In an embodiment, the second verification module 240 can include:

[0180] The habit data determining submodule is configured to determine the time habit data, the link habit data and the parameter habit data of the calling party through the exclusive behavior model, and obtain the request time, the API path and the request parameter of the API request.

[0181] The time habit verification submodule is configured to perform time habit verification based on the time habit data and the request time to obtain a time habit verification result.

[0182] The link habit verification submodule is configured to perform link habit verification based on the link habit data and the API path to obtain a link habit verification result.

[0183] The parameter habit verification submodule is configured to perform parameter habit verification based on the parameter habit data and the request parameter to obtain a parameter habit verification result.

[0184] The verification result generating submodule is configured to generate a second verification result according to the time habit verification result, the link habit verification result and the parameter habit verification result.

[0185] In one embodiment, the request defense module 250 may include:

[0186] The weight determination submodule is used to determine the abnormal weights of time habits, link habits, and parameter habits, respectively.

[0187] The score calculation submodule is used to sum the abnormal weights of the habits whose verification results are abnormal, and obtain the abnormal score of the API request.

[0188] In one embodiment, this application also provides a storage medium storing computer-readable instructions that, when executed by one or more processors, cause the one or more processors to perform the steps of the back-end intrusion prevention method as described in any of the above embodiments.

[0189] In one embodiment, this application also provides a computer device storing computer-readable instructions that, when executed by one or more processors, cause the one or more processors to perform the steps of the back-end intrusion prevention method as described in any of the above embodiments.

[0190] Indicatively, such as Figure 3 As shown, Figure 3 This is a schematic diagram of the internal structure of a computer device 300 provided in an embodiment of this application. The computer device 300 can be provided as a server. (Refer to...) Figure 3 The computer device 300 includes a processing component 302, which further includes one or more processors, and memory resources represented by memory 301 for storing instructions, such as application programs, that can be executed by the processing component 302. The application programs stored in memory 301 may include one or more modules, each corresponding to a set of instructions. Furthermore, the processing component 302 is configured to execute instructions to perform the back-end intrusion prevention method of any of the above embodiments.

[0191] The computer device 300 may also include a power supply component 303 configured to perform power management of the computer device 300, a wired or wireless network interface 304 configured to connect the computer device 300 to a network, and an input / output (I / O) interface 305. The computer device 300 may operate on an operating system stored in memory 301, such as Windows Server™, Mac OS X™, Unix™, Linux™, Free BSD™, or similar.

[0192] Those skilled in the art will understand that Figure 3The structure shown in the figure is only a block diagram of part of the structure related to the scheme of the present application, and does not constitute a limitation on the computer device to which the scheme of the present application is applied. The specific computer device can include more or fewer components than those shown in the figure, or combine certain components, or have a different arrangement of components.

[0193] Finally, it should be noted that in this document, the terms such as first and second are used only to distinguish one entity or operation from another, and do not necessarily require or imply any such actual relationship or order between such entities or operations. Also, the terms "comprises", "comprising", or any other variations thereof are intended to cover non-exclusive inclusions, so that a process, method, article, or apparatus that comprises a list of elements does not only include those elements, but also includes other elements not expressly listed, or other elements inherent in such process, method, article, or apparatus. Without more limitations, the element defined by the statement "comprises a" does not exclude the presence of additional identical elements in the process, method, article, or apparatus that includes the element.

[0194] The various embodiments in the specification are described in a progressive manner, and each embodiment focuses on the difference from other embodiments. The various embodiments can be combined as needed, and the same and similar parts refer to each other.

[0195] The above description of the disclosed embodiments enables a person skilled in the art to implement or use the present application. Various modifications to the embodiments will be apparent to those skilled in the art, and the general principles defined herein can be implemented in other embodiments without departing from the spirit or scope of the present application. Therefore, the present application will not be limited to the embodiments shown herein, but will conform to the widest scope consistent with the principles and novel features disclosed herein.

Claims

1. A method of backend intrusion prevention, the method comprising: The method includes: In response to an API request initiated by the caller, the API request is subjected to link semantic verification and parameter semantic verification using a preset semantic graph to obtain a first verification result; the first verification result includes qualified, slightly abnormal, and severely abnormal. If the first verification result is qualified, the API request is allowed directly; When the first verification result is a severe anomaly, the API request is intercepted; When the first verification result is a minor anomaly, the caller's exclusive behavior model is obtained, and the API request is subjected to multi-dimensional habit verification through the exclusive behavior model to obtain the second verification result. Based on the second verification result, the abnormal score of the API request is determined, and the defense action corresponding to the abnormal score is triggered.

2. The back-end IPS method of claim 1, wherein, The process of constructing the semantic graph includes: An initial graph is constructed by using each API as a node and the qualified call relationships between APIs as edges. The API information of each API is injected into the nodes corresponding to the initial graph to form node attributes, and the call information between each API is injected into the edges corresponding to the initial graph to form edge attributes. The initial graph after attribute injection is labeled as a semantic graph.

3. The backend intrusion prevention method according to claim 1, characterized in that, The step of performing link semantic verification and parameter semantic verification on the API request using a preset semantic graph to obtain a first verification result includes: The unique identifier of the caller and the request information of the API request are determined; the request information includes the API path, request parameters, and request time. Based on the unique identifier, the API path, and the request time, a link semantic verification is performed using a preset semantic graph to obtain the link verification result; Based on the request parameters and the API path, the semantic graph is used to perform parameter semantic verification to obtain the parameter verification result. The first verification result of the API request is determined based on the link verification result and the parameter verification result.

4. The backend intrusion prevention method according to claim 3, characterized in that, The step of performing link semantic verification based on the unique identifier, the API path, and the request time using a preset semantic graph to obtain the link verification result includes: Obtain the historical request records of the unique identifier and the preceding API calls in the historical request records, and query the preceding APIs corresponding to the API paths from the preset semantic graph; Determine whether the preceding API call is consistent with the preceding API and whether the request time does not exceed a preset time window; If so, then the link verification result is confirmed to be normal; If not, then the link verification result is confirmed to be abnormal.

5. The backend intrusion prevention method according to claim 3, characterized in that, The step of performing parameter semantic verification based on the request parameters and the API path using the semantic graph to obtain parameter verification results includes: Query the preceding API parameters corresponding to the API path from the semantic graph; Determine whether the request parameters are consistent with the request parameters and satisfy the parameter constraints; If so, then the parameter verification result is confirmed to be normal; If not, then the parameter verification result is confirmed to be abnormal.

6. The backend intrusion prevention method according to claim 3, characterized in that, The step of determining the first verification result of the API request based on the link verification result and the parameter verification result includes: Determine the validation type of the API request; the validation type includes mandatory and optional. Determine whether both the link verification result and the parameter verification result are normal; If so, then the first verification result of the API request is confirmed to be qualified; If not, when the verification type is optional, the first verification result of the API request is confirmed as a minor anomaly; and when the verification type is mandatory, the first verification result of the API request is confirmed as a severe anomaly.

7. The backend intrusion prevention method according to claim 1, characterized in that, The step of performing multi-dimensional habit verification on the API request using the specific behavior model to obtain a second verification result includes: The caller's time habit data, link habit data, and parameter habit data are determined through the exclusive behavior model, and the request time, API path, and request parameters of the API request are obtained. Based on the time habit data and the request time, a time habit verification is performed to obtain the time habit verification result; Based on the link habit data and the API path, link habit verification is performed to obtain the link habit verification result. Based on the parameter habit data and the request parameters, parameter habit verification is performed to obtain the parameter habit verification result; A second verification result is generated based on the time habit verification result, the link habit verification result, and the parameter habit verification result.

8. The backend intrusion prevention method according to claim 7, characterized in that, The step of determining the anomaly score of the API request based on the second verification result includes: Determine the abnormal weights for time habits, link habits, and parameter habits respectively; The abnormal weights of the habitually abnormal verification results are summed to obtain the abnormal score of the API request.

9. A back-end intrusion protection device, characterized in that, include: The first verification module is used to respond to API requests initiated by the caller, and to perform link semantic verification and parameter semantic verification on the API request using a preset semantic graph to obtain the first verification result. The first verification result includes qualified, slightly abnormal, and severely abnormal; The request release module is used to directly release the API request when the first verification result is qualified; The request interception module is used to intercept the API request when the first verification result is a severe anomaly; The second verification module is used to obtain the caller's exclusive behavior model when the first verification result is a slight anomaly, and to perform multi-dimensional habit verification on the API request through the exclusive behavior model to obtain the second verification result. The request defense module is used to determine the abnormal score of the API request based on the second verification result and trigger the defense action corresponding to the abnormal score.

10. A storage medium, characterized in that: The storage medium stores computer-readable instructions that, when executed by one or more processors, cause the one or more processors to perform the steps of the back-end intrusion prevention method as described in any one of claims 1 to 8.

11. A computer device, characterized in that, include: One or more processors, and memory; The memory stores computer-readable instructions that, when executed by the one or more processors, perform the steps of the back-end intrusion prevention method as described in any one of claims 1 to 8.

Images