Method for identifying edge cache content drift associated CDN node covert attack

Abstract

The application relates to the technical field of network security, and specifically discloses a CDN node concealed attack identification method based on edge cache content drift correlation, which comprises the following steps: periodically collecting a cryptography security policy contract in the cache content of each CDN edge node, quantifying constraint strength and comparing with a source station benchmark to generate a contract drift calibration sequence with a time stamp; calculating the contract constraint correlation strength of each node pair, constructing a cross-node drift correlation topology, identifying a timing abnormal condensed state substructure of multi-node constraint synchronization relaxation without global source station updating; tracing a drift propagation path, calculating a transmission delay deviation degree between nodes to verify an attacked node, and performing cryptography security policy contract back-to-source rechecking and cache immune isolation. The application utilizes the distributed architecture characteristics of CDN, performs cross-node cryptography contract drift correlation analysis, effectively identifies a gradual security boundary erosion attack, and improves the accuracy and coverage range of edge cache content security detection.

Description

Technical Field

[0001] This invention relates to the field of network security technology, and specifically to a method for identifying covert attacks on CDN nodes based on the correlation of edge cached content drift. Background Technology

[0002] Content delivery networks (CDNs) reduce access latency and alleviate the load on origin servers by deploying edge nodes globally to cache content from origin servers at the network edge closest to users. With the evolution of edge computing and distributed architectures, edge nodes have become critical infrastructure for network services, and their security is directly related to content integrity and user data security.

[0003] Existing CDN security technologies primarily focus on two types of methods: traffic layer attack detection and vertical content verification from the origin server to edge nodes. At the traffic layer, distributed denial-of-service attacks are defended through abnormal traffic identification and access frequency limiting. At the content layer, the main reliance is on the origin server to perform hash value comparisons or digital signature verification on the cached content at the edge to detect whether the content has been tampered with. However, all of the above technologies have significant detection blind spots: hash verification can only reflect the integrity of the content state at a certain moment and cannot identify progressive, minimized content drift attacks; single-point detection mechanisms lack a horizontal examination of the content evolution correlation between multiple edge nodes, making it difficult to detect covert attacks that only affect some nodes, specific time periods, and involve extremely small amounts of tampering each time.

[0004] More critically, existing technologies lack effective monitoring methods for cryptographic security policy contracts at the Hypertext Transfer Protocol (HTTP) level. Attackers can exploit the asynchronous update mechanism of edge nodes and differences in caching policies to gradually erode the security boundaries of cached content without triggering hash verification alarms. This can be achieved through long-term, phased, and selective relaxation of content security policies, removal of sub-resource integrity verification attributes, expansion of cross-domain resource sharing permissions, or shortening of the lifespan of strict transmission security policies. Such covert attacks leverage the inherent characteristics of CDN distributed architecture, effectively circumventing traditional threshold-based or signature-based detection methods. Furthermore, single-point detection is completely unable to identify the synchronous relaxation of security policies across multiple nodes.

[0005] Therefore, there is an urgent need for a method that can utilize the inherent characteristics of CDN distributed architecture to identify covert attacks through cross-edge node cryptographic security policy contract drift correlation analysis, in order to fill the gap in existing technologies for detecting progressive security boundary erosion attacks. Summary of the Invention

[0006] The technical problem to be solved by this invention is that existing CDN edge caching security detection technologies lack the ability to analyze the drift correlation of cross-node cryptographic security policy contracts, and cannot identify covert attacks that synchronously erode the security boundary of multiple nodes without global update triggering.

[0007] The technical solution of this invention to solve the above-mentioned technical problems is as follows: a method for identifying covert attacks on CDN nodes based on edge cache content drift correlation, specifically including the following steps:

[0008] S1. Periodically collect the cryptographic security policy contract set from the cached content response of each CDN edge node. The cryptographic security policy contract set includes at least one of the following: content security policy instruction set, sub-resource integrity verification attribute set, cross-domain resource sharing policy instruction set, and strict transmission security policy parameters. Simultaneously extract the origin server policy version identifier and cache timestamp corresponding to each contract set. Quantize the constraint strength of each contract set to generate a constraint strength time series sequence. Couple and compare the constraint strength time series sequence with the origin server policy version identifier to identify cryptographic contract drift nodes that deviate from the origin server benchmark and generate a timestamped cryptographic contract drift identification sequence.

[0009] S2. Based on the cryptographic contract drift calibration sequence, calculate the cryptographic contract constraint association strength between each pair of edge nodes. The constraint association strength includes at least one of the following: content security policy constraint strength similarity, sub-resource integrity coverage consistency, cross-domain resource sharing policy strictness matching degree, and strict transmission security policy survival time synchronization degree; construct a cross-node cryptographic contract drift association topology with edge nodes as vertices, constraint association strength as edge weights, and cache timestamp as edge attributes; identify a temporal anomalous condensed state substructure in which multiple nodes synchronously relax cryptographic contract constraints and the cache time interval between adjacent nodes deviates from the global statistical feature value under the absence of a global origin server policy version update event.

[0010] S3. Based on the edge weight temporal direction, vertex in-degree distribution, and cache time interval between adjacent nodes in the temporal anomaly condensed state substructure, trace the starting node and diffusion path of cryptographic contract drift propagation; calculate the deviation between the actual transmission delay and the historical transmission delay benchmark value between nodes on each diffusion path, verify and mark the attacked nodes; execute cryptographic security policies to force back-to-origin re-verification and resynchronize the origin server policy version on the marked nodes; trigger cache immunity isolation.

[0011] The beneficial effects of this invention are:

[0012] 1. This invention transforms cryptographic security policy contracts such as content security policies and sub-resource integrity into quantifiable constraint strength time-series sequences, breaking through the limitation of traditional single-point hash verification that only detects content integrity. It can accurately identify covert erosion attacks carried out by attackers by progressively relaxing the boundaries of security policies, and significantly improve the ability to detect micro-drift content tampering.

[0013] 2. This invention utilizes the characteristics of CDN distributed architecture to construct a cross-node cryptographic contract drift association topology. By identifying abnormal condensed state substructures where multi-node constraints are synchronously relaxed without global origin server update triggering, it effectively discovers group-based covert attack patterns that existing single-point detection mechanisms cannot identify, thus enhancing the detection coverage of distributed edge cache collaborative pollution behavior.

[0014] 3. This invention traces the drift propagation path based on the graph features of the abnormal condensed state substructure, locates the attacked node by cross-validation of transmission delay deviation, and triggers cryptographic security policy contract back-to-origin re-verification and cache immune isolation, realizing a closed-loop process from attack discovery, node tracing to pollution blocking, and improving the response efficiency and processing accuracy of CDN edge cache security protection. Attached Figure Description

[0015] Figure 1 This is a flowchart illustrating the method described in Embodiments 1-4 of the present invention;

[0016] Figure 2 This is a framework diagram of the system described in Embodiment 5 of the present invention. Detailed Implementation

[0017] The principles and features of the present invention are described below. The examples given are only for explaining the present invention and are not intended to limit the scope of the present invention.

[0018] Example 1

[0019] like Figure 1 As shown, this invention provides a method for identifying CDN node covert attacks based on edge cache content drift correlation, specifically including the following steps:

[0020] S1. Periodically collect the cryptographic security policy contract in the cached content of each CDN edge node, extract the origin server policy version identifier and cache timestamp, and quantify the constraint strength; compare the quantified constraint strength value with the origin server benchmark to generate a contract drift calibration sequence with timestamp;

[0021] S2. Calculate the contract constraint association strength of each node pair based on the contract drift calibration sequence, construct the cross-node drift association topology with cache timestamp as the edge attribute; extract candidate condensed substructures, and identify the temporal anomalous condensed substructures of multi-node constraint synchronous relaxation under the condition of no global source station update;

[0022] S3. Trace the drift propagation path based on the temporal orientation of edge weights and the in-degree distribution of vertices in the temporally anomalous condensed state substructure; calculate the transmission delay deviation between nodes and verify the attacked node; execute the cryptographic security strategy contract back-to-origin re-verification and cache immune isolation.

[0023] Example 2

[0024] Preferably, in Embodiment 1, step S1 is specifically implemented through the following steps:

[0025] S11. Edge Cache Cryptographic Contract Acquisition and Constraint Strength Quantization, specifically including:

[0026] S111. Send a cache status query command carrying a content URP locator to each CDN edge cache node. The query command is constructed using the HTTP GET request method, and the target content URP locator is embedded in the request header. After receiving the query command, each edge cache node returns a cached content response message, which includes a response header and a response body. Extract the cryptographic security policy contract set from the response header. Specifically, extract the content security policy directive set from the Content-Security-Policy field, which includes at least one directive from default-src, script-src, style-src, img-src, connect-src, font-src, object-src, media-src, frame-src, sandbox, and report-uri. Extract the sub-resource integrity verification attribute set from the sub-resource link tags contained in the response body, which includes integrity verification attributes declared in script tags, link tags, and embedded object tags. Extract the cross-origin resource sharing policy directive set from the Access-Control-Allow-Origin, Access-Control-Allow-Methods, and Access-Control-Allow-Headers fields. Extract the strict transport security policy parameters from the Strict-Transport-Security field.

[0027] The origin server policy version identifier is extracted from the ETag or X-Policy-Version field in the response header. This identifier, either a string or a numeric code, uniquely identifies the currently effective security policy version on the origin server. The cached timestamp is read from the Date or Age field in the response header, combined with the system clock. The timestamp precision is in milliseconds, and the value range is from 0 to 2147483647 (Unix timestamps), with the preferred value being a millisecond-level timestamp corresponding to the current system time. The extracted set of cryptographic security policy contracts, the origin server policy version identifier, and the cached timestamp are used as the raw data collected by the edge cache node at that collection moment.

[0028] S112. Count the number of security policy directive entries in the content security policy directive set and determine the constraint severity level of each directive. The constraint severity level is divided into integer levels from 1 to 5 according to the degree of restriction on resource loading by the directive. Directives allowing any source are at level 1, directives allowing resources from the same source are at level 3, directives prohibiting loading are at level 5, directives allowing specific domains are at level 4, and directives allowing resources from the same source and specific trusted domains are at level 2. The specific trusted domains are a set of trusted domains pre-configured and whitelisted by the origin server. Assign a weight coefficient to each directive, with a value ranging from 0.5 to 1.0, preferably 1.0. Multiply the constraint severity level of each directive by its corresponding weight coefficient, sum the results, and then divide by the total number of entries to obtain the quantified value of the content security policy constraint strength. When the content security policy directive set is empty, this quantified value is set to 0; when the directive set is not empty, this quantified value ranges from 0.5 to 5.0.

[0029] The ratio of the number of sub-resources with integrity verification attributes in the sub-resource integrity verification attribute set to the total number of sub-resources is calculated to obtain the quantified value of sub-resource integrity coverage. This ratio ranges from 0 to 1, with an optimal value of 0.8 to 1.0 depending on the origin server's security configuration. In the above calculation, the total number of entries refers to the number of all valid instructions in the content security policy instruction set, and the total number of sub-resources refers to the total number of all sub-resource reference tags declared in the current cached content response body, including script resources, style resources, and embedded object resources. The sub-resource reference tags are the script tags, link tags, and embedded object tags explicitly declared in the response header. If the total number of sub-resources is zero, the quantified value of sub-resource integrity coverage is set to 0.

[0030] S113. Based on the value type of the Access-Control-Allow-Origin directive in the cross-domain resource sharing policy directive set, map the value type to the cross-domain resource sharing policy strictness quantification value according to the preset strictness mapping table. The mapping rules of the preset strictness mapping table are as follows: when the value is a wildcard asterisk, it is mapped to 1; when the value is a list of multiple allowed domains, it is mapped to 2; when the value is a specific allowed domain, it is mapped to 3; when the value is null, it is mapped to 4; when the value is only allowed for same-origin transactions and requires credentials, it is mapped to 5; when the directive is not set, it is mapped to 0, indicating that this dimension is not enabled and is only used as a consistency matching item in the association strength calculation, and does not participate in the comparison of the absolute value of strictness. The strictness quantification value ranges from 0 to 5, with a preferred value of 3.

[0031] Extract the `max-age` field value from the strict transport security policy parameters. This field, located in the `Strict-Transport-Security` response header, represents the lifetime of the strict transport security policy. The `max-age` field value is in seconds (s), ranging from 0 to 31,536,000 seconds, with 31,536,000 seconds being the preferred value. Use the mapped strict metric value of the cross-domain resource sharing policy and the extracted strict transport security policy lifetime quantization value as the cryptographic security policy quantization parameter for this edge cache node at the time of data collection. When the cross-domain resource sharing policy instruction set does not contain the `Access-Control-Allow-Origin` instruction, the strict metric value of the cross-domain resource sharing policy is set to the default value of 0. When the `Strict-Transport-Security` response header is missing, the strict transport security policy lifetime quantization value is set to the default value of 0.

[0032] S114. Arrange the quantified values ​​of content security policy constraint strength, sub-resource integrity coverage, cross-domain resource sharing policy strictness, and strict transmission security policy survival time, along with the corresponding origin server policy version identifier, in chronological order of cache timestamps. Each element contains the above four quantified values, an origin server policy version identifier, and the corresponding cache timestamp, forming a six-dimensional data structure time-series element. Organize all time-series elements sequentially to form the constraint strength time-series sequence of the edge cache node. The periodic collection time interval ranges from 30s to 300s, with a preferred value of 60s. The time interval between adjacent elements in the sequence is equal to the above periodic collection time interval, and the total sequence length is set to no less than 100 time-series elements according to monitoring requirements.

[0033] The source server policy version identifier changes as the source server policy is updated within the sequence. When the identifier changes, subsequent comparison operations will call the source server baseline constraint strength value corresponding to the new version. The cached timestamps of each element in the sequence are recorded with millisecond precision, using a Unix timestamp format, ranging from 0 to 2147483647 ms, with the preferred value being the system millisecond timestamp corresponding to the current acquisition time. The constraint strength time series is stored locally on the edge monitoring node using a circular buffer, with a buffer capacity ranging from 1000 to 10000 records, with a preferred value of 5000 records.

[0034] S12. Source station baseline coupling comparison and contract drift calibration, specifically including:

[0035] S121. Based on the origin server policy version identifier, retrieve the corresponding origin server baseline constraint strength value from the origin server policy version repository. The origin server policy version repository resides on the origin server side. When the origin server updates its cryptographic security policy contract set, the system generates a new origin server policy version identifier and writes it to the repository. The repository uses the origin server policy version identifier as the primary key and contains four origin server baseline constraint strength values: origin server content security policy baseline constraint strength, origin server sub-resource integrity baseline coverage, origin server cross-domain resource sharing baseline strictness, and origin server strict transmission security baseline lifetime. The origin server content security policy baseline constraint strength is a weighted average of the constraint strictness levels of each instruction in the current content security policy instruction set, ranging from 0 to 5, with 3.5 being preferred. The origin server sub-resource integrity baseline coverage is determined according to the proportion of sub-resource integrity verification attributes in the origin server configuration, ranging from 0 to 1, with 1 being preferred. The origin server cross-domain resource sharing baseline strictness is converted from the Access-Control-Allow-Origin instruction value type using a mapping table, ranging from 0 to 5, with 3 being preferred. The origin server's strict transmission security baseline lifetime is extracted from the `max-age` field of the `Strict-Transport-Security` header, in seconds, ranging from 0 to 31,536,000, with 31,536,000 being the preferred value. Monitoring nodes retrieve matching records from the version control repository via a secure communication channel based on the origin server policy version identifier extracted from S111.

[0036] S122. Normalize the quantized value of the survival time of the strict transmission security policy by dividing it by the preset maximum survival time benchmark value to obtain the normalized quantized value of the survival time of the strict transmission security policy. The maximum survival time benchmark value is 31536000, and the normalized value ranges from 0 to 1.

[0037] For each edge cache node, the quantized value of the content security policy constraint strength at each moment in the constraint strength time series is calculated by subtracting the source site's content security policy baseline constraint strength. Similarly, the quantized value of the sub-resource integrity coverage is calculated by subtracting the source site's sub-resource integrity baseline coverage. The quantized value of the cross-domain resource sharing policy strictness is calculated by subtracting the source site's cross-domain resource sharing baseline strictness. Finally, the quantized value of the normalized strict transmission security policy lifetime is calculated by subtracting the normalized value of the source site's strict transmission security baseline lifetime. The normalized value of the source site's strict transmission security baseline lifetime is the source site's strict transmission security baseline lifetime divided by 31,536,000. All four subtraction operations use the quantized value on the edge cache node side as the minuend and the source site's baseline constraint strength value as the subtrahend. In other words, the deviations are calculated by subtracting the source site's baseline constraint strength value from the node constraint strength quantized value. These results in the deviations for the content security policy constraint strength, sub-resource integrity coverage, cross-domain resource sharing policy strictness, and strict transmission security policy lifetime. The above four deviations are collectively referred to as the constraint strength deviations of each contract item of the edge cache node at that moment. If there is no baseline record corresponding to the current source policy version identifier in the source policy version repository, the difference calculation at the current moment is paused, and a version missing alarm is returned to the upper-layer monitoring module. This step is then re-executed after the version repository is synchronized and updated.

[0038] S123. Perform a weighted summation of the constraint strength deviations of each contract item obtained in S122 to obtain the comprehensive constraint strength deviation of the edge cache node at that moment. The weighted summation uses a linear weighted model, assigning weighting coefficients to the content security policy constraint strength deviation, sub-resource integrity coverage deviation, cross-domain resource sharing policy strictness deviation, and strict transmission security policy survival time deviation. The values ​​of the four weighting coefficients are all in the range of 0.05 to 0.5, and the sum of the four weighting coefficients is equal to 1.0. The preferred values ​​are 0.3 for the content security policy constraint strength deviation, 0.3 for the sub-resource integrity coverage deviation, 0.2 for the cross-domain resource sharing policy strictness deviation, and 0.2 for the strict transmission security policy survival time deviation.

[0039] The weighted deviation of each contractual item constraint strength is multiplied by its corresponding weighting coefficient to obtain the weighted individual item deviation. The four weighted individual item deviations are then algebraically summed to obtain the comprehensive constraint strength deviation. In the comprehensive constraint strength deviation, the weighted contribution range of the content security policy constraint strength deviation and the cross-domain resource sharing policy strictness deviation is approximately -2.5 to +2.5; the weighted contribution range of the sub-resource integrity coverage deviation and the strict transmission security policy survival time deviation is approximately -0.5 to +0.5; and the overall comprehensive constraint strength deviation ranges from -3.0 to +3.0. When all constraint strengths on the node side are lower than the source station benchmark, the comprehensive constraint strength deviation is negative, indicating relaxed constraints; when all constraint strengths on the node side are higher than the source station benchmark, the comprehensive constraint strength deviation is positive, indicating strengthened constraints.

[0040] S124. When the absolute value of the comprehensive constraint strength deviation exceeds a preset deviation threshold, the edge cache node is marked as a cryptographic contract drift node at that moment. The preset deviation threshold is determined by multiplying the maximum absolute value of the comprehensive constraint strength deviation during historical attack-free runtime periods by a preset security factor. The preset security factor ranges from 1.2 to 2.0, with a preferred value of 1.5. The constraint strength deviation of each contract item, the comprehensive constraint strength deviation, the marking result, and the original constraint strength quantization value of each contract item are arranged in chronological order to generate a timestamped cryptographic contract drift marking sequence.

[0041] Each element in the sequence contains the following parameters for that moment: content security policy constraint strength deviation, sub-resource integrity coverage deviation, cross-domain resource sharing policy strictness deviation, strict transmission security policy survival time deviation, overall constraint strength deviation, drift calibration Boolean value, original quantized values ​​for content security policy constraint strength, sub-resource integrity coverage, cross-domain resource sharing policy strictness, and strict transmission security policy survival time, as well as the corresponding cache timestamp. The sequence is stored in the local database of the edge monitoring node. The database table uses the cache timestamp as the primary key index and supports queries by time range and by node identifier.

[0042] Example 3

[0043] Preferably, in Embodiment 1, step S2 is specifically implemented through the following steps:

[0044] S21. Calculation of cross-node cryptographic contract constraint association strength, specifically including:

[0045] S211. From the cryptographic contract drift labeling sequence, select any two different edge cache nodes and extract the quantized values ​​of the content security policy constraint strength of the two nodes at the same time. The criterion for determining the same time is that the difference between the cache timestamps of the corresponding sequence elements of the two nodes is less than a preset time alignment tolerance. This tolerance ranges from 1s to 10s, with a preferred value of 5s. If the difference between the timestamps of the two nodes exceeds this tolerance, then search for the nearest sequence element of the node with the later timestamp within the tolerance range. If a match still cannot be found, skip the association calculation at that time.

[0046] The absolute value of the difference between two content security policy constraint strength quantification values ​​is calculated. The reciprocal of the result after adding 1 to the absolute value of the difference is used as the content security policy constraint strength similarity between the two nodes. The similarity value ranges from greater than 0 to less than or equal to 1. When the content security policy constraint strength quantification values ​​of the two nodes are equal, the absolute value of the difference is 0, and the similarity is 1. As the absolute value of the difference increases, the similarity monotonically decreases and approaches 0. The content security policy constraint strength quantification value is derived from the weighted average calculation result of S112, and the value ranges from 0 to 5. During the calculation, the absolute value of the difference is calculated using double-precision floating-point arithmetic, retaining 4 significant digits after the decimal point. The reciprocal calculation result is retained to 6 significant digits after the decimal point. The final result is stored in the node pair association data structure.

[0047] S212. Extract the quantized values ​​of sub-resource integrity coverage of the two edge cache nodes at the same time from the cryptographic contract drift calibration sequence. The criterion for determining the same time is consistent with the time alignment rule described in S211, that is, matching is performed based on the difference in cache timestamps and a preset time alignment tolerance. Calculate the ratio of the two quantized values ​​of sub-resource integrity coverage, using the larger value as the numerator and the smaller value as the denominator, ensuring that the ratio is always greater than or equal to 1.

[0048] Calculate the absolute value of the difference between this ratio and the value 1, add 1 to this absolute value, and take the reciprocal. This reciprocal is used as the consistency of sub-resource integrity coverage between the two nodes. The consistency value ranges from greater than 0 to less than or equal to 1. When the coverage of the two nodes is equal, the ratio is 1, the absolute value of the difference is 0, and the consistency is 1. The quantized value of sub-resource integrity coverage comes from the ratio calculation result in S112, and the value ranges from 0 to 1. If the denominator in the ratio calculation is 0, the quantized value of the coverage of that node is replaced by the minimum value, which ranges from 0.0001 to 0.001, with 0.0001 being the preferred value to avoid division by zero errors and ensure calculation continuity. The calculation result is retained to 6 significant decimal places.

[0049] S213. Extract the strict metric values ​​of the cross-domain resource sharing strategy at the same time from the cryptographic contract drift calibration sequence. The criterion for determining the same time is consistent with the time alignment rule described in S211. Calculate the absolute value of the difference between the two strict metric values ​​of the cross-domain resource sharing strategy, and normalize this absolute value by dividing it by a preset maximum strictness difference benchmark value. The preset maximum strictness difference benchmark value is the difference between the upper and lower limits of the range of the strict metric values ​​of the cross-domain resource sharing strategy, and this strictness difference benchmark value ranges from 0 to 5, so the maximum strictness difference benchmark value is 5. The normalization operation yields a normalized value, ranging from 0 to 1.

[0050] The normalized value is incremented by 1, and the reciprocal is taken as the cross-domain resource sharing policy strictness matching degree between the two nodes. This matching degree ranges from 0.5 to 1. When the strictness of the two nodes is equal, the normalized value is 0, and the matching degree is 1. The cross-domain resource sharing policy strictness metric is derived from the mapping table transformation result of S113 and is an integer or floating-point number in the range of 0 to 5. If the strictness metric of both nodes is 0 and no cross-domain resource sharing policy is set, the matching degree is set to 1, indicating that the two nodes have the same state on this policy item. The calculation result is rounded to 6 decimal places.

[0051] S214. Extract the strict transmission security policy lifetime quantization values ​​of the two edge buffer nodes at the same time from the cryptographic contract drift calibration sequence. The criteria for determining the same time are consistent with the time alignment rule described in S211. Calculate the ratio of the two strict transmission security policy lifetime quantization values, using the larger lifetime quantization value as the numerator and the smaller lifetime quantization value as the denominator.

[0052] Calculate the absolute value of the difference between this ratio and the value 1. Add 1 to this absolute value and take the reciprocal. This reciprocal is used as the synchronization degree of the strict transmission security policy survival time between the two nodes. The synchronization degree ranges from greater than 0 to less than or equal to 1. When the survival times of the two nodes are equal, the ratio is 1, the absolute value of the difference is 0, and the synchronization degree is 1. The quantized value of the strict transmission security policy survival time is derived from the max-age field extracted from S113, with the unit being seconds and a value range of 0 to 31,536,000 seconds. If the quantized survival time values ​​of both nodes are 0, meaning that neither node has a strict transmission security policy configured, the synchronization degree is set to 1. If the denominator in the ratio calculation is 0, it is replaced by the minimum value, which ranges from 0.1 to 1.0 seconds, with a preferred value of 1.0 seconds. The calculation result is stored with 6 significant decimal places.

[0053] S215. The cryptographic contract constraint strength between two edge cache nodes is obtained by weighted summation of the similarity of content security policy constraint strength, consistency of sub-resource integrity coverage, matching degree of cross-domain resource sharing policy strictness, and synchronization degree of strict transmission security policy lifetime. A linear weighted model is used for the weighted summation, and weighting coefficients are assigned to each of the four indicators. The values ​​of the four weighting coefficients range from 0.05 to 0.5, and the sum of the four weighting coefficients equals 1.0. The preferred values ​​are: content security policy constraint strength similarity weighting coefficient 0.25, sub-resource integrity coverage consistency weighting coefficient 0.25, cross-domain resource sharing policy strictness matching degree weighting coefficient 0.25, and strict transmission security policy lifetime synchronization degree weighting coefficient 0.25.

[0054] Each indicator value is multiplied by its corresponding weighting coefficient to obtain a weighted sub-association value. The four weighted sub-association values ​​are then algebraically summed to obtain the cryptographic contract constraint association strength. This association strength ranges from 0 to 1; a value closer to 1 indicates a stronger constraint association between the two nodes on the cryptographic security policy contract, while a value closer to 0 indicates a weaker association. The association strength calculation result is retained to six decimal places and stored in a cross-node association matrix. The matrix rows and columns correspond to the identifiers of each edge cache node, and the matrix elements have a symmetric structure, meaning the association strength between node A and node B is equal to the association strength between node B and node A.

[0055] S22. Construction of cross-node cryptographic contract drift association topology, specifically including:

[0056] S221. For the same cached content, construct a graph structure with each edge cache node as a vertex. First, enumerate the cached records of the content on all edge cache nodes, and abstract each edge cache node containing the content as a vertex in the graph. The vertex identifier uses the globally unique identifier of the edge cache node. For any two different vertices, establish an undirected edge between them. This undirected edge represents the possible cryptographic contract drift propagation relationship between the two edge cache nodes. Use the cryptographic contract constraint association strength calculated in S215 as the initial edge weight of this undirected edge. The edge weight value is a floating-point number in the range of 0 to 1. The larger the value, the stronger the association between the two nodes in the cryptographic security policy contract.

[0057] If the cryptographic contract constraint strength between two nodes fails to be calculated due to timestamp alignment failure, the initial edge weight of the undirected edge takes a default value, ranging from 0.001 to 0.01, with a preferred value of 0.005. Undirected edges are established using a fully connected approach, meaning there is an undirected edge between every two vertices. The total number of edges is n multiplied by n minus 1 divided by 2, where n is the total number of vertices. All vertices and undirected edges constitute the initial undirected graph data structure, stored in a graph database or adjacency matrix.

[0058] S222. Traverse each undirected edge in the initial undirected graph established in S221, and obtain the cache timestamps corresponding to the two vertices of each undirected edge. The cache timestamps are derived from the millisecond-level timestamps extracted from the response header in S111, or from the cache timestamps recorded in the constraint strength time sequence in S114. Compare the cache timestamps of the two vertices, and take the vertex with the smaller cache timestamp as the starting point of the directed edge and the vertex with the larger cache timestamp as the ending point of the directed edge. The direction of the directed edge is from the starting point to the ending point, that is, from the vertex with the earlier cache timestamp to the vertex with the later cache timestamp. If the cache timestamps of the two vertices are equal, compare the lexicographical order of the globally unique identifiers of the two vertices, and take the vertex with the smaller lexicographical order as the starting point and the vertex with the larger lexicographical order as the ending point to ensure that the direction of the directed edge is uniquely determined.

[0059] The start and end timestamps of the transformed directed edges are used together as edge attributes. These attributes are stored in a two-dimensional timestamp structure, containing both the start and end timestamp fields. After converting all undirected edges to directed edges, the initial undirected graph is transformed into a directed graph, which no longer contains undirected edges.

[0060] S223. For each directed edge obtained from the transformation in S222, obtain the absolute value of the comprehensive constraint strength deviation of the starting vertex and the absolute value of the comprehensive constraint strength deviation of the ending vertex. The aforementioned absolute value of the comprehensive constraint strength deviation originates from the cryptographic contract drift calibration sequence generated in S124, and is the absolute value of the comprehensive constraint strength deviation in S123. Calculate the difference between the absolute value of the comprehensive constraint strength deviation of the starting vertex and the absolute value of the comprehensive constraint strength deviation of the ending vertex, by subtracting the absolute value of the ending vertex from the starting vertex. Multiply this difference by a preset edge weight adjustment coefficient, which ranges from 0.1 to 1.0, with a preferred value of 0.5. Add the product to the initial edge weight determined in S221 to obtain the updated edge weight.

[0061] The formula for calculating the updated edge weight is: Updated Edge Weight = Initial Edge Weight + (Absolute Value of Deviation of Overall Constraint Strength at the Starting Point - Absolute Value of Deviation of Overall Constraint Strength at the Ending Point) × Preset Edge Weight Adjustment Coefficient. If the calculated updated edge weight is less than 0, it is set to 0; if the updated edge weight is greater than 1, it is set to 1, ensuring that the edge weight is always within a reasonable range of 0 to 1. The updated edge weight reflects the degree of association between nodes after the cryptographic contract constraint strength is corrected by the propagation direction.

[0062] S224. Summarize all vertices processed in S223, the directed edges between vertices, the updated edge weights of each directed edge, and the edge attributes of each directed edge to construct a complete cross-node cryptographic contract drift association topology. This topology is represented using a directed weighted graph data structure. The vertex set contains all edge cache nodes containing the cached content, the edge set contains all directed edges transformed in S222, the edge weight set contains all updated edge weights calculated in S223, and the edge attribute set contains the cache timestamps of the vertices at both ends of each edge. The topology data structure supports operations such as querying adjacent edges by vertex identifier, filtering edges by edge weight range, and querying subgraphs by timestamp range.

[0063] The cross-node cryptographic contract drift association topology is constructed independently on a per-cache-content basis. That is, the same cached content corresponds to an independent topology instance, and topology instances of different cached content are stored in isolation. After the topology is constructed, the topology instance is persistently stored in a graph database or distributed cache, with the storage key being the hash value of the cached content's Uniform Resource Locator (URL). This allows for quick retrieval during subsequent candidate anomaly edge filtering in S231 and drift propagation path tracing in S311.

[0064] S23. Extraction of candidate condensed matter substructures, specifically including:

[0065] S231. Set edge weight threshold and time difference threshold: The edge weight threshold is determined based on the statistical distribution of the updated edge weights of all directed edges in the cross-node cryptographic contract drift association topology. It is the sum of the arithmetic mean and standard deviation of all updated edge weights. If this sum is less than 0.3, then 0.3 is used; if it is greater than 0.8, then 0.8 is used. The edge weight threshold ranges from 0.3 to 0.8, with a preferred value of 0.5. The time difference threshold is determined based on the historical maximum transmission delay of the cached content from the origin server to the farthest edge cache node in the CDN network. It is 1.5 times this historical maximum transmission delay. If this value is less than 300s, then 300s is used; if it is greater than 1800s, then 1800s is used. The time difference threshold ranges from 300s to 1800s, with a preferred value of 600s.

[0066] Traverse all directed edges in the cross-node cryptographic contract drift association topology, and for each directed edge, read its updated edge weight and edge attributes. Calculate the difference between the cached timestamps of the endpoint and the originating vertex in the edge attributes, and take the absolute value of this difference as the cached timestamp difference between the two endpoints. Determine whether the updated edge weight of the directed edge is higher than the edge weight threshold and whether the cached timestamp difference between the two endpoints is less than the time difference threshold. If both conditions are met, mark the directed edge as a candidate anomalous edge; if neither condition is met, skip the edge. Collect all candidate anomalous edges into a candidate anomalous edge set and store it in an adjacency list or edge list data structure.

[0067] S232. Extract all vertices associated with directed edges in the candidate abnormal edge set to form a candidate vertex set. For each vertex in the candidate vertex set, extract all associated directed edges in the candidate abnormal edge set that serve as the starting or ending point of that vertex. Using a depth-first search or breadth-first search algorithm, arbitrarily select an unvisited vertex in the candidate vertex set as the search starting point, and perform a connected traversal along the directed edges in the candidate abnormal edge set. During the traversal, record all vertices and all directed edges visited, until no new unvisited vertex can be reached, forming a connected subgraph. Repeat the above search process until all vertices in the candidate vertex set have been visited. Finally, multiple non-overlapping connected subgraphs are obtained, and there are no shared vertices or shared edges between the connected subgraphs.

[0068] Each connected subgraph is treated as a candidate condensed substructure, which contains a subset of vertices and all candidate outlier edges between vertices within that subset. Each candidate condensed substructure is stored independently, recording the number of vertices, the number of edges, the minimum cache timestamp, and the maximum cache timestamp. The number of candidate condensed substructures ranges from 1 to the total number of vertices, with a preferred number of 3 to 5.

[0069] S24. Identification of temporally anomalous condensed matter substructures, specifically including:

[0070] S241. For each candidate condensed matter substructure, extract all its vertices and read the cached timestamps corresponding to each vertex. Map the cached timestamps to the corresponding monitoring period identifier according to the preset monitoring period duration. The monitoring period duration ranges from 300s to 3600s, with a preferred value of 3600s, i.e., 1 hour. The monitoring period identifier uses a combination of start and end timestamps, or a period sequence number.

[0071] A global source site policy version update event database is established and maintained by the source site-side policy change audit module. Whenever the source site modifies the cryptographic security policy contract set and generates a new source site policy version identifier, an update event record is automatically written. This database records cryptographic security policy contract set change events that occur at the source site within each monitoring period. Each event record includes a unique event identifier, a change-effective timestamp, the source site policy version identifier before the change, the source site policy version identifier after the change, and a summary of the change content. For each vertex in the candidate condensed state substructure corresponding to a monitoring period identifier, a query is initiated to the global source site policy version update event database to retrieve whether there is a global source site policy version update event trigger record with an effective status within that monitoring period. The query uses a time range matching method, i.e., it determines whether the event change effective timestamp falls within the time interval of that monitoring period. If at least one matching record exists, it is recorded that a global source site policy version update event trigger record exists in the monitoring period corresponding to that vertex.

[0072] S242. For each candidate condensed substructure, iterate through the monitoring period query results corresponding to all its vertices. If a global source station policy version update event trigger record exists within the monitoring period of any vertex in the candidate condensed substructure, then the cryptographic contract drift phenomenon within the candidate condensed substructure can be explained by a legitimate source station policy update, i.e., the multi-node constraint synchronization relaxation is caused by the source station actively issuing a new version policy. Mark the candidate condensed substructure as a non-abnormal condensed substructure, and set the marking field to a Boolean value of false or a status code of 0.

[0073] Candidate condensed matter substructures marked as non-anomaly are removed from the current candidate condensed matter substructure set and will not proceed to subsequent anomaly analysis. The removal operation is implemented using set difference operations or database deletion markers to ensure that removed substructures are no longer involved in the S243 determination. For each removed candidate condensed matter substructure, the reason for removal, the corresponding global source server policy version update event identifier, and the list of affected vertices are recorded to form a legitimate policy update exclusion log for subsequent auditing and tracing.

[0074] S243. For each candidate condensed substructure remaining after the elimination in S242, check the monitoring period query results for all its vertices. If there are no trigger records for global origin server policy version update events within the monitoring period of any vertex in the candidate condensed substructure, then the candidate condensed substructure is determined to have no legitimate origin server policy update that can be explained. In this case, the phenomenon of synchronous relaxation of multi-node cryptographic contract constraints within the substructure cannot be attributed to active change of origin server policy, which is consistent with the abnormal propagation characteristics caused by covert attacks. The candidate condensed substructure is identified as a temporally abnormal condensed substructure, and the flag field is set to a boolean value of true or status code 1.

[0075] The identified temporally anomalous condensed matter substructures are output to the anomaly analysis queue. The output includes the substructure identifier, the identifiers of all contained vertices, a list of directed edges between vertices, updated edge weights for each edge, the range of cached timestamps in the edge attributes, and the minimum and maximum cached timestamps for the substructure. The preferred number of temporally anomalous condensed matter substructures is 1 to 5. If the number is zero, an empty result is output and the anomaly identification process for the current monitoring cycle ends.

[0076] Example 4

[0077] Preferably, in Embodiment 1, step S3 is implemented through the following steps:

[0078] S31. Tracing the propagation path of cryptographic contract drift, specifically including:

[0079] S311. Obtain the in-degree of all vertices in the temporal anomaly condensed state substructure. The in-degree is defined as the number of directed edges pointing to that vertex. Simultaneously obtain the absolute value of the comprehensive constraint strength deviation for each vertex. This value originates from the absolute value of the comprehensive constraint strength deviation recorded in the cryptographic contract drift calibration sequence (S124). Traverse all vertices, filtering out vertices with an in-degree of zero. If multiple vertices have an in-degree of zero, compare the absolute values ​​of their comprehensive constraint strength deviations and determine the largest one as a candidate starting node. If no vertex has an in-degree of zero, determine the vertex with the smallest in-degree and the largest absolute value of its comprehensive constraint strength deviation as a candidate starting node; if multiple vertices still exist, select the one with the smallest lexicographical order of its globally unique identifier as a candidate starting node. The candidate starting node represents a possible source of cryptographic contract drift propagation in this substructure. The minimum in-degree value is an integer greater than or equal to 0, with 0 being the preferred value.

[0080] S312. Using the candidate starting node determined in S311 as the search starting point, perform a depth-first traversal along the existing directed edges in the temporally anomalous condensed state substructure. During the traversal, starting from the current vertex, visit adjacent vertices along all its outgoing directed edges, and record the sequence of traversed vertices and directed edges. When the current vertex has no unvisited outgoing directed edges, or the path length reaches the preset maximum path length, the traversal of the current branch is terminated. The preset maximum path length ranges from 3 to 10 edges, with a preferred value of 5 edges. Start an independent traversal for all outgoing directed edges of the candidate starting node, generating several candidate diffusion paths starting from that candidate starting node. Each candidate diffusion path is stored in the form of a combination of vertex sequence and edge sequence. The number of vertices in the path ranges from 2 to the preset maximum path length plus 1, with a preferred value of 2 to 6 vertices.

[0081] S313. For each candidate diffusion path generated in S312, traverse the adjacent vertices along the path starting from the candidate starting node, following the direction of the directed edges. Obtain the absolute value of the comprehensive constraint strength deviation for each vertex on the path, forming a sequence of absolute deviation values ​​along the path direction. Determine whether the sequence exhibits a monotonically decreasing trend along the path direction, i.e., the value of each subsequent element in the sequence is less than or equal to the value of its preceding element. If the path contains only two vertices, directly compare the absolute values ​​of the comprehensive constraint strength deviation between the starting and ending points. If the value of the ending point is less than or equal to the value of the starting point, it is determined to be monotonically decreasing. The determination of the monotonically decreasing trend uses a point-by-point comparison method, traversing each pair of adjacent elements in the sequence. If any pair of subsequent elements is greater than the preceding element, the path is determined not to satisfy a monotonically decreasing trend. The absolute value of the comprehensive constraint strength deviation comes from S124, which is the result of the absolute value operation of the comprehensive constraint strength deviation in S123.

[0082] S314. If S313 determines that the absolute value of the comprehensive constraint strength deviation on a candidate diffusion path shows a monotonically decreasing trend along the path direction, then the candidate diffusion path is confirmed as a cryptographic contract drift diffusion path. This path represents the trajectory of cryptographic contract constraints propagating from strong to weak along the directed edge direction, which conforms to the characteristics of covert attacks spreading from the infection source to neighboring nodes. The candidate starting node corresponding to this path is confirmed as the drift propagation starting node, that is, this node is the initial infection source of cryptographic contract drift in this temporal anomalous condensed state substructure. If there are multiple cryptographic contract drift diffusion paths, the drift propagation starting node corresponding to the longest path length is selected as the finally confirmed drift propagation starting node; if the path lengths are the same, the node corresponding to the largest absolute value of the comprehensive constraint strength deviation is selected. The drift propagation starting node and the cryptographic contract drift diffusion path are jointly output to S321 for subsequent transmission delay deviation verification.

[0083] S32. Transmission delay deviation verification and attack node origin re-verification specifically include:

[0084] S321. For each cryptographic contract drift propagation path, traverse every two adjacent nodes along the directed edge direction. Obtain the cache timestamp of the next node and the cache timestamp of the previous node, calculate the difference between them and take the absolute value as the actual transmission delay between the adjacent node pair, in seconds. This difference is obtained by subtracting the timestamps in milliseconds and then dividing by 1000. Select the time period within the most recent preset number of monitoring periods in which no cryptographic contract drift nodes have been identified as the historical attack-free runtime period. The preset number ranges from 3 to 12 monitoring periods, with a preferred value of 6 monitoring periods, and each monitoring period lasts for 3600 seconds. During the attack-free historical runtime, all historical transmission delay records of the cached content propagating from the previous node to the next node are extracted. If the number of records is not less than 10, the arithmetic mean of these records is calculated as the historical transmission delay baseline value, in seconds. If the number of records is less than 10 but not less than 3, the arithmetic mean of all available records is used as the historical transmission delay baseline value. If the number of records is less than 3, the theoretical minimum transmission delay value of the adjacent node pair in the network topology is used as the historical transmission delay baseline value. The theoretical minimum transmission delay value is estimated based on the physical distance between the two nodes and the light speed propagation model, and its value ranges from 0.01s to 0.5s, with a preferred value of 0.1s. The absolute value of the difference between the actual transmission delay and the historical transmission delay baseline value is calculated, and this absolute value is divided by the historical transmission delay baseline value to obtain the deviation. This deviation is a dimensionless ratio, and its value range is greater than or equal to 0.

[0085] S322. The preset deviation threshold is determined based on the sum of the statistical mean and three standard deviations of the deviation samples of all adjacent node pairs during the historical attack-free runtime period. If the calculated value is less than 0.1, it is set to 0.1; if it is greater than 0.5, it is set to 0.5. The preset deviation threshold ranges from 0.1 to 0.5, with a preferred value of 0.2. When the deviation exceeds the preset deviation threshold, the subsequent node is marked as an attacked node.

[0086] A forced origin pull control command is issued to the marked attacked node. This command is constructed using the HTTP PURGE method or a dedicated origin pull control message format, with the message header containing the target cached content's Uniform Resource Locator (URI), command type identifier, and timestamp signature. Upon receiving the control command, the attacked node re-initiates a content retrieval request to the origin server for the cached content that triggered the cryptographic contract drift. This content retrieval request uses the HTTP GET method, and the request message carries the URI of the cached content and the version identifier of the current local cache. Upon receiving the request, the origin server returns the original response header for the cached content and extracts the original cryptographic security policy contract set from this header. This set includes the original content security policy command set, the original sub-resource integrity verification attribute set, the original cross-domain resource sharing policy command set, and the original strict transport security policy parameters. The attacked node receives the original cryptographic security policy contract set returned by the origin server and temporarily stores it in a local comparison buffer, awaiting the next step of item-by-item comparison. If the source server returns a timeout or fails to respond, a retry mechanism will be initiated. The number of retries ranges from 1 to 3, with a preferred value of 2. The retry interval ranges from 5 to 30 seconds, with a preferred value of 10 seconds.

[0087] S323. Compare the original set of cryptographic security policy contracts with the set of cryptographic security policy contracts currently cached by the attacked node item by item. The comparison items include the instruction entries and parameters in the content security policy instruction set, the verification attribute identifiers in the sub-resource integrity verification attribute set, the Access-Control-Allow-Origin value type in the cross-domain resource sharing policy instruction set, and the max-age field value in the strict transport security policy parameters.

[0088] For each comparison, if the original contract item is inconsistent with the current cached contract item, the contract item in the current cache is replaced with the original contract item. The replacement operation uses an atomic write method to ensure that the cached content is not read by external requests during the comparison and replacement process. After each comparison is completed, the consistency between the cryptographic security policy contract set currently cached by the attacked node and the original cryptographic security policy contract set is verified. If all compared items are consistent, the initial resynchronization of the origin server policy version is determined to be complete, an initial resynchronization completion marker is generated, and the initial resynchronization timestamp is recorded. If there are contract items that cannot be replaced, an exception log is recorded and a second origin server request is triggered. The interval between the second origin server requests ranges from 30 seconds to 300 seconds, with a preferred value of 60 seconds.

[0089] S33. Attacked node cache immunity isolation and recovery, specifically including:

[0090] S331. Temporarily remove the marked attacked node from the normal service scheduling pool of the CDN network. The normal service scheduling pool maintains a list of serviceable edge cache nodes. Each node in the list records its globally unique identifier, current health status, real-time load rate, and the timestamp of the most recent policy synchronization. When a node is marked as an attacked node, the scheduling controller sends a status change instruction to the node, setting the node's health status field to the isolated state. The isolation state status code ranges from 0 to 3, where 0 represents normal, 1 represents isolated, 2 represents maintenance, and 3 represents offline, with 1 being the preferred value. The status change instruction is issued via TCP control channel or HTTP management interface, with a timeout range of 1 to 10 seconds, and 5 seconds being the preferred value.

[0091] After the state change is complete, the load balancer removes the attacked node from the set of active service nodes and stops allocating new user content requests to that node. The request allocation strategy uses round-robin or weighted least connection algorithm, and the removed node no longer participates in subsequent request scheduling calculations. The temporary removal operation is logged in an audit log, including the node identifier, removal timestamp, removal reason, and operation sequence number. The log retention period ranges from 7 to 90 days, with 30 days being the preferred value.

[0092] S332. Intercept all user requests currently being processed by the attacked node. The interception mechanism is implemented through a request proxy layer or edge gateway deployed in front of the attacked node. The proxy layer sends a connection interruption signal or a request suspension instruction to the node, causing the node to stop receiving new user request data packets. For user requests that have entered the node's processing queue but have not yet completed a response, extract their request Uniform Resource Locator (URL), request method, client session identifier, and original request timestamp to form a list of requests to be rerouted.

[0093] Iterate through each request in the list of requests to be rerouted, and reselect the target node according to the backup edge cache node selection strategy. The backup edge cache node selection strategy prioritizes edge cache nodes located in the same geographical area as the attacked node, with network latency below a preset latency threshold, and not marked as attacked nodes. The preset latency threshold ranges from 10ms to 100ms, with a preferred value of 50ms. If no available backup node is available in the same area, the selection is expanded to adjacent areas. The request to be rerouted is sent to the selected backup edge cache node through an internal forwarding channel. The forwarding channel uses HTTP 307 temporary redirection or internal proxy forwarding, with a forwarding timeout ranging from 1s to 5s, with a preferred value of 2s.

[0094] S333. Continuously monitor the consistency verification results between the currently cached set of cryptographic security policy contracts of the attacked node and the original set of cryptographic security policy contracts. The consistency verification adopts the item-by-item hash comparison method. The content security policy instruction set, sub-resource integrity verification attribute set, cross-domain resource sharing policy instruction set, and strict transmission security policy parameters are arranged in ascending alphabetical order by field name and concatenated into a standardized string. Then, the SHA-256 hash digest of the string is calculated, and the current hash digest of each item of the attacked node is compared with the original hash digest of each item byte by byte.

[0095] If all four hash digests are completely identical, the consistency check is considered successful. The monitoring period ranges from 5 to 60 seconds, with a preferred value of 10 seconds, meaning a consistency check is performed every 10 seconds. The number of consecutive monitoring attempts ranges from 1 to 5, with a preferred value of 3. Only if three consecutive monitoring attempts pass the consistency check can the attacked node be considered to have completed the mandatory cryptographic security policy back-to-origin re-verification and origin server policy version resynchronization operation. If the hash digests are inconsistent in any monitoring attempt, the consecutive pass counter is reset, and a second back-to-origin request is triggered. The total monitoring timeout ranges from 60 to 1800 seconds, with a preferred value of 300 seconds. If the consistency check is not completed within the total timeout period, the attacked node's status is upgraded to permanent isolation, and an alert is issued.

[0096] S334. Once it is determined that the attacked node has completed the mandatory origin re-verification of the cryptographic security policy and the resynchronization of the origin server's policy version, the attacked node is re-added to the normal service scheduling pool. Before re-adding, a pre-recovery health check is performed. The health check items include node network connectivity, cache service response time, policy contract consistency verification, and node load rate. The network connectivity check uses ICMP echo requests or TCP port probes, with a timeout value ranging from 1s to 5s, preferably 2s. The cache service response time check uses simulated request tests, with a response time threshold ranging from 50ms to 500ms, preferably 200ms. The node load rate check requires that the current CPU utilization is lower than the preset load limit, with the preset load limit ranging from 60% to 90%, preferably 80%.

[0097] After all health checks are passed, the scheduling controller sets the health status field of the attacked node from isolated to normal and reinstates it into the active service node set. The initial weight after recovery ranges from 10% to 50% of the node's baseline weight in the healthy state, with a preferred value of 20%. This means the node initially participates in request allocation with a lower weight, and after a preset observation period, it gradually recovers to the baseline weight. The baseline weight is the default weight allocation value for load balancing when the node was not marked as an attacked node. The preset observation period ranges from 60 seconds to 600 seconds, with a preferred value of 300 seconds. After recovery, the node resumes receiving and processing user content requests.

[0098] Example 5

[0099] like Figure 2 As shown, a CDN node covert attack identification system based on edge cache content drift correlation is used to implement a CDN node covert attack identification method based on edge cache content drift correlation, including:

[0100] The cryptographic contract acquisition module is used to send cache status query instructions to each CDN edge cache node, receive the returned cache content response header, extract the cryptographic security policy contract set, origin server policy version identifier and cache timestamp, quantify the constraint strength, and generate a constraint strength time series sequence.

[0101] The drift calibration module is used to compare the quantized values ​​of constraint strength in the constraint strength time series with the source station benchmark to generate a contract drift calibration sequence with timestamps.

[0102] The association topology construction module is used to calculate the contract constraint association strength of each node pair based on the contract drift calibration sequence, and construct a cross-node cryptographic contract drift association topology with cache timestamp as the edge attribute;

[0103] The condensed matter identification module is used to extract candidate condensed matter substructures from cross-node cryptographic contract drift association topology and identify temporally anomalous condensed matter substructures with synchronous relaxation of multi-node constraints under the condition of no global source station update.

[0104] The propagation tracing module is used to trace the drift propagation path based on the temporal orientation of edge weights and the in-degree distribution of vertices in the temporally anomalous condensed state substructure.

[0105] The verification and handling module is used to calculate the transmission delay deviation between nodes and verify the attacked node, and to execute the cryptographic security policy contract back-to-origin re-verification and cache immunity isolation.

[0106] The embodiments and / or implementation methods described above are merely preferred embodiments and / or implementation methods for implementing the technology of the present invention, and are not intended to limit the implementation methods of the technology of the present invention in any way. Any person skilled in the art can make some modifications or alterations to other equivalent embodiments without departing from the scope of the technical means disclosed in the content of the present invention, but they should still be regarded as the technology or embodiments that are substantially the same as the present invention.

[0107] This document uses specific examples to illustrate the principles and implementation methods of this application. The descriptions of the above embodiments are only for the purpose of helping to understand the methods and core ideas of this application. The above descriptions are only preferred embodiments of this application. It should be noted that due to the limitations of written expression, while there are objectively infinite specific structures, those skilled in the art can make several improvements, modifications, or changes without departing from the principles of this application, and can also combine the above technical features in an appropriate manner. These improvements, modifications, changes, or combinations, or the direct application of the inventive concept and technical solution to other situations without modification, should all be considered within the scope of protection of this application.

Claims

1. A method for identifying CDN node covert attacks based on edge cache content drift correlation, characterized in that, include: Periodically collect the cryptographic security policy contract from the cached content of each CDN edge node, extract the origin server policy version identifier and cache timestamp, and quantify the constraint strength; The quantified value of the constraint strength is compared with the source station benchmark to generate a contract drift calibration sequence with timestamps; Based on the contract drift calibration sequence, calculate the contract constraint association strength of each node pair, and construct a cross-node drift association topology with cache timestamp as the edge attribute; Extract candidate condensed matter substructures and identify temporally anomalous condensed matter substructures under the condition of synchronous relaxation of multi-node constraints without global source station update; The drift propagation path is traced based on the temporal orientation of the edge weights and the in-degree distribution of the vertices in the aforementioned temporal anomaly condensed state substructure. Calculate the transmission delay deviation between nodes and verify the attacked node, and execute the cryptographic security policy contract back-to-origin re-verification and cache immunity isolation.

2. The CDN node covert attack identification method based on edge cache content drift association according to claim 1, characterized in that, The periodic collection of cryptographic security policy contracts from the cached content of each CDN edge node, extraction of the origin server policy version identifier and cache timestamp, and quantification of constraint strength specifically include: Send cache status query instructions to each CDN edge cache node, receive the returned cache content response, extract the content security policy instruction set, cross-domain resource sharing policy instruction set, strict transmission security policy parameters, origin server policy version identifier and cache timestamp from the response header, and extract the sub-resource integrity verification attribute set from the response body. The cryptographic security policy contract set includes the above sets and parameters. The constraint severity level of each instruction in the content security policy instruction set is statistically analyzed and weighted averaged to obtain the quantitative value of the content security policy constraint strength; the ratio of the number of sub-resources with integrity verification attributes to the total number of sub-resources in the sub-resource integrity verification attribute set is calculated to obtain the quantitative value of the sub-resource integrity coverage. Based on the value type of the Access-Control-Allow-Origin instruction in the cross-domain resource sharing policy instruction set, the value type is mapped to the cross-domain resource sharing policy strictness quantification value according to the preset strictness mapping table; the max-age field value in the strict transmission security policy parameter is extracted as the strict transmission security policy lifespan quantification value. The constraint strength quantification values ​​of the content security policy, the sub-resource integrity coverage quantification value, the cross-domain resource sharing policy strict quantification value, the strict transmission security policy survival time quantification value, and the corresponding origin server policy version identifier are arranged in chronological order to form the constraint strength chronological sequence of the edge cache node.

3. The CDN node covert attack identification method based on edge cache content drift association according to claim 2, characterized in that, The step of comparing the quantified constraint strength value with the source station benchmark to generate a timestamped contract drift calibration sequence specifically includes: Based on the origin server policy version identifier, the corresponding origin server baseline constraint strength value is retrieved from the origin server policy version repository. The origin server baseline constraint strength value includes the origin server content security policy baseline constraint strength, the origin server sub-resource integrity baseline coverage, the origin server cross-domain resource sharing baseline strictness, and the origin server strict transmission security baseline survival time. The content security policy constraint strength quantification value, sub-resource integrity coverage quantification value, cross-domain resource sharing policy strict quantification value, and strict transmission security policy survival time quantification value of each edge cache node at each time are compared with the corresponding benchmark values ​​in the source station benchmark constraint strength value to obtain the constraint strength deviation of each contract item. The weighted sum of the constraint strength deviations of each contract item is used to obtain the comprehensive constraint strength deviation of the node at that moment. When the absolute value of the comprehensive constraint strength deviation exceeds the preset deviation threshold, the edge cache node is marked as a cryptographic contract drift node; the constraint strength deviation of each contract item, the comprehensive constraint strength deviation, the marking result and the original constraint strength quantization value are arranged in chronological order to generate a cryptographic contract drift marking sequence with timestamps.

4. The CDN node covert attack identification method based on edge cache content drift association according to claim 1, characterized in that, The contract constraint association strength of each node pair is calculated based on the contract drift calibration sequence, specifically including: Obtain the quantized value of the content security policy constraint strength of each pair of edge cache nodes at the same time, calculate the absolute value of the difference, and use the reciprocal of the absolute value of the difference plus 1 as the similarity of the content security policy constraint strength. Obtain the quantized values ​​of sub-resource integrity coverage of two nodes at the same time, calculate the ratio of the two quantized coverage values, and take the reciprocal of the absolute value of the difference between the ratio and 1 plus 1 as the consistency of sub-resource integrity coverage. Obtain the strictness metric of the cross-domain resource sharing strategy for two nodes at the same time, calculate the absolute value of the difference and divide it by the preset maximum strictness difference benchmark value for normalization, and use the reciprocal of the normalized value plus 1 as the strictness matching degree of the cross-domain resource sharing strategy. Obtain the quantized values ​​of the strict transmission security policy survival time of two nodes at the same time, calculate the ratio, and take the reciprocal of the absolute value of the difference between the ratio and 1 plus 1 as the strict transmission security policy survival time synchronization degree. The cryptographic contract constraint association strength between two edge cache nodes is obtained by weighted summing of the similarity of content security policy constraint strength, consistency of sub-resource integrity coverage, matching degree of cross-domain resource sharing policy strictness, and synchronization degree of strict transmission security policy lifespan.

5. The CDN node covert attack identification method based on edge cache content drift association according to claim 4, characterized in that, The construction of the cross-node drift association topology with cache timestamps as edge attributes specifically includes: For the same cached content, each edge cache node is used as a vertex, and an undirected edge is established between every two edge cache nodes, with the cryptographic contract constraint association strength as the initial edge weight of the undirected edge; Based on the cache timestamps corresponding to each vertex, undirected edges are converted into directed edges with the direction from the vertex with the earlier cache timestamp to the vertex with the later cache timestamp. If the cache timestamps of the two vertices are equal, they are directed from the smaller one to the larger one according to the lexicographical order of the globally unique vertex identifiers, and the cache timestamps of the two vertices are used as edge attributes. Obtain the absolute value of the comprehensive constraint strength deviation of the starting vertex and the absolute value of the comprehensive constraint strength deviation of the ending vertex of each directed edge, calculate the difference between the two, multiply the difference by the preset edge weight adjustment coefficient and add it to the initial edge weight to obtain the updated edge weight. By summarizing the directed edges between each vertex, the updated edge weights, and the edge attributes, a cross-node cryptographic contract drift association topology is constructed.

6. The CDN node covert attack identification method based on edge cache content drift association according to claim 5, characterized in that, The extraction of candidate condensed matter substructures specifically includes: Set an edge weight threshold and a time difference threshold, traverse all directed edges in the cross-node cryptographic contract drift association topology, and filter out directed edges whose edge weight is higher than the edge weight threshold and whose difference between the cache timestamps of the two vertices in the edge attribute is less than the time difference threshold, as candidate abnormal edges; Extract all vertices connected by the candidate abnormal edges and all directed edges between the vertices to form multiple connected subgraphs, and use each connected subgraph as a candidate condensed state substructure.

7. The CDN node covert attack identification method based on edge cache content drift association according to claim 6, characterized in that, The identification of temporally anomalous condensed-state substructures with synchronous relaxation of multi-node constraints under conditions of no global source station update specifically includes: Obtain the monitoring period corresponding to the cache timestamp of each vertex in each candidate condensed substructure, and query whether there is a trigger record of the global origin server policy version update event within each monitoring period; If any vertex in a candidate condensed substructure contains a record of a global source station policy version update event within its monitoring period, then the candidate condensed substructure is determined to be caused by a legitimate policy update and is removed. If there are no global source policy version update event trigger records for any of the vertices in the candidate condensed substructure within the monitoring period, then the candidate condensed substructure is determined to have no valid source policy update that can be explained, is identified as a time-series abnormal condensed substructure, and is output.

8. The CDN node covert attack identification method based on edge cache content drift association according to claim 1, characterized in that, Tracing the drift propagation path based on the temporal orientation of edge weights and the in-degree distribution of vertices in the aforementioned temporally anomalous condensed state substructure specifically includes: Obtain the in-degree and absolute value of the comprehensive constraint strength deviation of each vertex, and determine the vertex with zero in-degree and the largest absolute value of deviation as the candidate starting node; if there is no vertex with zero in-degree, then determine the vertex with the smallest in-degree and the largest absolute value of deviation as the candidate starting node. Starting from the candidate starting node, a depth-first traversal is performed along the direction of the directed edge in the temporal anomaly condensed state substructure. During the traversal, each vertex and directed edge is recorded, and several candidate diffusion paths starting from the candidate starting node are generated. For each candidate diffusion path, traverse adjacent vertices one by one according to the path direction, obtain the absolute value of the comprehensive constraint strength deviation of each vertex, and determine whether the absolute value of the comprehensive constraint strength deviation shows a monotonically decreasing trend along the path direction. If the absolute value of the comprehensive constraint strength deviation shows a monotonically decreasing trend along the path direction, then the candidate diffusion path is confirmed as the cryptographic contract drift diffusion path, and the candidate starting node corresponding to the path is confirmed as the drift propagation starting node.

9. The CDN node covert attack identification method based on edge cache content drift association according to claim 8, characterized in that, The calculation of the transmission delay deviation between nodes and the verification of the attacked node specifically includes: For each pair of adjacent nodes on each cryptographic contract drift diffusion path, the difference between the cache timestamps of the two nodes is used as the actual transmission delay, and the average historical transmission delay between the two nodes during a preset period without attacks is used as the historical transmission delay benchmark. The absolute value of the difference between the actual transmission delay and the benchmark is calculated as the ratio of the benchmark value to the actual transmission delay, and the deviation is obtained. When the deviation exceeds the preset deviation threshold, the next node is marked as an attacked node, and a forced return-to-origin instruction is issued to the attacked node, instructing it to re-initiate the content retrieval request to the origin server and obtain the original set of cryptographic security policy contracts returned by the origin server. The original set of cryptographic security policy contracts is compared item by item with the set of cryptographic security policy contracts currently cached by the attacked node. Inconsistent contract items are replaced with the original contract items from the source site, thus completing the resynchronization of the source site policy version.

10. The CDN node covert attack identification method based on edge cache content drift association according to claim 9, characterized in that, The implementation of the cryptographic security policy contract for origin re-verification and cache immunity isolation specifically includes: Temporarily remove the marked attacked node from the normal service scheduling pool of the CDN network and stop allocating new user content requests to the attacked node; Intercept all user requests currently being processed by the attacked node and reroute the intercepted user requests to backup edge cache nodes that have not been marked as attacked nodes; Continuously monitor the consistency verification results between the currently cached set of cryptographic security policy contracts of the attacked node and the original set of cryptographic security policy contracts. When the consistency verification passes, determine that the cryptographic security policy has been forcibly returned to the source for re-verification and the source site policy version has been resynchronized. Once it is determined that the attacked node has completed the mandatory origin re-verification of the cryptographic security policy and the resynchronization of the origin server policy version, the attacked node will be added back to the normal service scheduling pool, and the node will be able to receive and process user content requests again.

Images