Interface access verification method and device, equipment and storage medium

Abstract

The present disclosure provides an interface access verification method, device and equipment and a storage medium. The method comprises: receiving an interface access request initiated by a client; in response to the interface access request, obtaining a request feature of the client, a historical performance compensation coefficient and an interface value coefficient of a target interface to be accessed; generating a calculation challenge based on the request feature, the historical performance compensation coefficient and the interface value coefficient, and sending the calculation challenge to the client; receiving a calculation-type access proof feedback submitted by the client after the client completes the calculation challenge; and verifying whether the client has access rights of the target interface based on the calculation-type access proof feedback. The method of the present disclosure can reduce the processing burden of invalid requests and the waste of computing resources on the server while ensuring the security of interface access.

Description

Technical Field

[0001] This disclosure relates to the field of access control technology, and in particular to an interface access verification method, apparatus, device, and storage medium. Background Technology

[0002] With the widespread deployment of open interfaces, mobile applications, API gateways, and AI service interfaces, the security challenges faced by server-side interfaces are shifting from traditional human attacks to automated and intelligent attacks. Currently, numerous risk control mechanisms targeting interface access have emerged in the industry. Existing technologies typically employ account authentication systems, device fingerprint recognition, CAPTCHA interaction, call frequency limits (rate limiting), blacklists and whitelists, risk level assessments, and access control matrices to verify the legitimacy of the interface caller's identity and operational behavior. These methods, to a certain extent, limit unauthorized and unauthorized access.

[0003] However, existing solutions focus primarily on determining "whether access is allowed" or "which interfaces are allowed," with their core logic relying on the server-side to perform real-time feature extraction, risk scoring, and permission matching for each request. Under this mechanism, the caller does not incur substantial computational costs for server-side verification before initiating access. This means that even if the server can identify some abnormal requests using existing rules, attackers can still continuously send massive access requests to the server by quickly changing IP addresses, resetting device fingerprints, switching login accounts, or tampering with request parameters, thus placing a significant burden on the server in handling invalid requests and wasting computational resources. Therefore, how to reduce the burden on the server in handling invalid requests and the waste of computational resources while ensuring interface access security has become a pressing technical problem for those skilled in the art. Summary of the Invention

[0004] In view of this, this disclosure proposes an interface access verification method, apparatus, device, and storage medium, which can reduce the burden of server-side invalid request processing and the waste of computing resources while ensuring interface access security.

[0005] According to a first aspect of this disclosure, an interface access verification method is provided, comprising: Receive an interface access request initiated by a client, respond to the interface access request, and obtain the client's request characteristics, historical performance compensation coefficient, and interface value coefficient of the target interface to be accessed. Based on the request characteristics, the historical performance compensation coefficient, and the interface value coefficient, a computational challenge is generated and sent to the client. Specifically, a risk bucket is calculated based on the request characteristics; a challenge difficulty parameter is calculated based on the risk bucket, the historical performance compensation coefficient, and the interface value coefficient; and a computational challenge is generated and sent to the client based on the challenge difficulty parameter. Receive feedback from the client after completing the computational challenge, including the computational access proof submitted by the client. Based on the computational access proof feedback, verify whether the client has access rights to the target interface; The historical performance compensation coefficient is determined based on the generation time of the client's historical computational access proof feedback.

[0006] In one possible implementation, the request characteristics include at least one of the following: request frequency anomaly, burst request anomaly, failure rate anomaly, device fingerprint fluctuation, network environment risk, and historical reputation risk.

[0007] In one possible implementation, obtaining the burst request anomaly level includes: The number of requests made by the client to the target interface within the current short time window, the number of requests made to the target interface within the long time window preceding the current short time window, and the number of requests made to the target interface within the previous short time window adjacent to the current short time window are obtained. Based on the number of requests made by the client to the target interface within the current short time window, the number of requests made to the target interface within the long time window preceding the current short time window, and the number of requests made to the target interface within the previous short time window adjacent to the current short time window, the current short-term request rate within the current short time window, the historical baseline request rate within the long time window, and the previous short-term request rate within the previous short time window are calculated respectively. Based on the current short-term request rate, the historical baseline request rate within the long-term window, and the previous short-term request rate within the previous short-term window, calculate the burst multiple and growth rate of the burst requests. Based on the burst multiple and the growth rate, the burst request anomaly degree of the client is calculated.

[0008] In one possible implementation, the historical performance compensation coefficient is determined based on the generation time of the client's historical computational access proof feedback.

[0009] In one possible implementation, the challenge difficulty parameters include at least one of the following: the number of iteration rounds, the memory access scale, and the number of bits for the target difficulty in the computational challenge.

[0010] In one possible implementation, generating the computational challenge based on the challenge difficulty parameter includes: Obtain the server's key, the server's random number, the client's device digest, the target interface identifier, and the time slice; Based on the server's key, the server's random number, the client's device digest, the target interface identifier, the time slice, and the challenge difficulty parameter, a challenge seed is generated; The computational challenge is generated based on the server's random number, the target interface identifier, the time slice, the challenge difficulty parameter, and the challenge seed.

[0011] In one possible implementation, when the client executes the computational challenge and generates the computational access proof feedback, it includes: Generate a request digest based on the interface access request; Based on the request digest, the random number selected by the client, and the challenge difficulty parameter and challenge seed recorded in the computational challenge, the computational access proof feedback is generated.

[0012] According to a second aspect of this disclosure, an interface access verification device is provided, comprising: The data acquisition module is used to receive interface access requests initiated by the client, respond to the interface access requests, and acquire the client's request characteristics, historical performance compensation coefficients, and the interface value coefficient of the target interface to be accessed. The computational challenge initiation module is used to generate a computational challenge based on the request characteristics, the historical performance compensation coefficient, and the interface value coefficient, and send it to the client. Specifically, it calculates a risk bucket based on the request characteristics; calculates a challenge difficulty parameter based on the risk bucket, the historical performance compensation coefficient, and the interface value coefficient; and generates the computational challenge based on the challenge difficulty parameter and sends it to the client. The computational access proof receiving module is used to receive the computational access proof feedback submitted by the client after completing the computational challenge; The access permission verification module is used to verify whether the client has access permission to the target interface based on the computational access proof feedback. The historical performance compensation coefficient is determined based on the generation time of the client's historical computational access proof feedback.

[0013] In one possible implementation, the request characteristics include at least one of the following: request frequency anomaly, burst request anomaly, failure rate anomaly, device fingerprint fluctuation, network environment risk, and historical reputation risk.

[0014] According to a third aspect of this disclosure, an interface access verification device is provided, comprising: a processor; a memory for storing processor-executable instructions; wherein the processor is configured to perform the method described in the first aspect of this disclosure.

[0015] According to a fourth aspect of this disclosure, a non-volatile computer-readable storage medium is provided that stores computer program instructions thereon, wherein the computer program instructions, when executed by a processor, implement the method described in the first aspect of this disclosure.

[0016] This disclosure provides an interface access verification method, apparatus, device, and storage medium. The method includes: receiving an interface access request initiated by a client; responding to the interface access request; obtaining the client's request characteristics, historical performance compensation coefficients, and the interface value coefficient of the target interface to be accessed; generating a computational challenge based on the request characteristics, historical performance compensation coefficients, and interface value coefficients, and sending it to the client; specifically, calculating a risk bucket based on the request characteristics; calculating a challenge difficulty parameter based on the risk buckets, historical performance compensation coefficients, and interface value coefficients; generating a computational challenge based on the challenge difficulty parameter and sending it to the client; receiving a computational access proof submitted by the client after completing the computational challenge; and verifying whether the client has access rights to the target interface based on the computational access proof feedback. This method can reduce the burden of handling invalid requests and the waste of computational resources on the server while ensuring interface access security.

[0017] Other features and aspects of this disclosure will become clear from the following detailed description of exemplary embodiments with reference to the accompanying drawings. Attached Figure Description

[0018] The accompanying drawings, which are included in and form part of this specification, illustrate exemplary embodiments, features, and aspects of this disclosure together with the specification and serve to explain the principles of this disclosure.

[0019] Figure 1 A flowchart illustrating an interface access verification method according to an embodiment of the present disclosure is shown. Figure 2 A schematic block diagram of an interface access verification device according to an embodiment of the present disclosure is shown; Figure 3 A schematic block diagram of an interface access verification device according to an embodiment of the present disclosure is shown. Detailed Implementation

[0020] Various exemplary embodiments, features, and aspects of this disclosure will now be described in detail with reference to the accompanying drawings. The same reference numerals in the drawings denote elements that have the same or similar functions. Although various aspects of the embodiments are shown in the drawings, they are not necessarily drawn to scale unless specifically indicated otherwise.

[0021] The term “exemplary” as used herein means “serving as an example, embodiment, or illustration.” Any embodiment illustrated herein as “exemplary” is not necessarily to be construed as superior to or better than other embodiments.

[0022] Furthermore, to better illustrate this disclosure, numerous specific details are set forth in the following detailed description. Those skilled in the art will understand that this disclosure can be practiced without certain specific details. In some instances, methods, means, components, and circuits well known to those skilled in the art have not been described in detail in order to highlight the main points of this disclosure.

[0023] <Method Implementation> Figure 1 A flowchart illustrating an interface access verification method according to an embodiment of this disclosure is shown. Figure 1 As shown, the method is executed by the server that provides the service interface, including steps S1100-S1400.

[0024] S1100 receives the interface access request initiated by the client, responds to the interface access request, and obtains the client's request characteristics, historical performance compensation coefficient P, and the interface value coefficient V of the target interface to be accessed.

[0025] First, it's important to understand that when a client needs to access a target interface on the server, it first needs to generate an interface access request for that target interface and send it to the server. The server can then receive the interface access request initiated by the client. This interface access request must include at least the target interface identifier, request method, interface path, request body content, request initiation timestamp, and relevant client identification information. The client identification information is used by the server to identify the client and associate it with its historical access records and device characteristics.

[0026] After receiving the interface access request, the server responds to the interface access request and performs operations to obtain the client's request characteristics, historical performance compensation coefficient P, and the interface value coefficient V of the target interface to be accessed.

[0027] In one possible implementation, the client's request characteristics may include at least one of the following: request frequency anomaly x1, burst request anomaly x2, failure rate anomaly x3, device fingerprint fluctuation x4, network environment risk x5, and historical reputation risk x6.

[0028] When obtaining the client's request frequency anomaly score x1, first obtain the number of requests q5 made by the client to the target interface within the most recent set time period (e.g., 5 minutes) and the maximum number of requests qmax allowed for the target interface within that time period. Then, based on q5 and qmax, calculate the client's request frequency anomaly score x1. The formula for calculating this request frequency anomaly score x1 is as follows: x1 = min(1, q5 / qmax) When obtaining the client's burst request anomaly level x2, the following steps may be included: First, obtain the number of requests (qs) made by the client to the target interface within the current short time window Ws (e.g., 10 seconds), the number of requests (ql) made to the target interface within the preceding long time window Wl (e.g., 5 minutes), and the number of requests (qp) made to the target interface within the previous short time window adjacent to the current short time window. Here, Ws < Wl, and the long time window Wl includes the preceding short time window adjacent to the current short time window; the preceding short time window adjacent to the current short time window is actually a sub-window at the end of the long time window Wl. For example, if the current short time window Ws = [t-10 seconds, t), then the long time window Wl before the current short time window Ws = [t-310 seconds, t-10 seconds), and the preceding short time window adjacent to the current short time window = [t-20 seconds, t-10 seconds), and ql includes qp.

[0029] Second, based on the number of client requests to the target interface within the current short-term window, the number of requests to the target interface within the preceding long-term window, and the number of requests to the target interface within the previous short-term window adjacent to the current short-term window, the current short-term request rate within the current short-term window, the historical baseline request rate within the long-term window, and the previous short-term request rate within the previous short-term window are calculated respectively. Specifically, the current short-term request rate within the current short-term window is rs = qs / Ws, the historical baseline request rate within the long-term window is rl = ql / Wl, and the previous short-term request rate within the previous short-term window is rp = qp / Ws. Here, rl is used to form a longer-term baseline, and rp is used alone to measure the growth rate of the nearest neighboring window; the two have different uses.

[0030] Third, based on the current short-term request rate, the historical baseline request rate, and the previous short-term request rate, calculate the burst multiple and growth rate of the burst requests. The formulas for calculating the burst multiple u and growth rate g are as follows: u = rs / max(rl, rmin) g = max(0, (rs - rp) / max(rp, rmin)) Where rs is the current short-term request rate, rl is the historical baseline request rate, rp is the previous short-term request rate, and rmin is the minimum reference rate used to prevent the denominator from being zero and to suppress low-radix amplification.

[0031] In one possible implementation, rmin = 1 / Ws, meaning it is calculated based on at least one request per short time window. Alternatively, the lower percentile (e.g., the 5th percentile) of the normal traffic sample request rate can be taken as the larger value of 1 / Ws, i.e., rmin = max(1 / Ws, r_low). When there is a new interface or insufficient samples, 1 / Ws can be used first, and then the normal traffic of that interface can be periodically updated thereafter.

[0032] Fourth, based on the burst multiple u and the growth rate g, calculate the client's burst request anomaly degree x2: b1 = min(1, max(0, (u - 1) / (u0 - 1))) b2 = min(1, g / g0) x2 = min(1, a×b1 + (1 - a)×b2) Where b1 represents the deviation of the current short-term request rate from the historical baseline request rate. b2 represents the growth rate of the current short-term window request rate relative to the previous short-term window. When u reaches u0, b1 reaches 1; when g reaches g0, b2 reaches 1; after exceeding the threshold, it is truncated by the min function. 'a' is a fusion weight with a value between 0 and 1, used only to fuse two risks, without changing the fact that all factors are within the 0-1 range. u0 is a preset burst multiple threshold greater than 1, and g0 is a preset growth rate threshold greater than 0.

[0033] In one possible implementation, u0 and g0 can be determined based on normal traffic samples of the target interface. It is recommended to take the high quantile values ​​(e.g., the 95th or 99th percentile) of the burst multiple u and growth rate g in the normal samples as the thresholds for achieving a perfect score for a single risk, ensuring u0 > 1 and g0 > 0. If samples are insufficient, u0 = 3 and g0 = 2 can be set as an example, representing that the current rate reaches 3 times the long-term baseline, or that the single risk reaches 1 when the rate increases by 200% relative to the previous window; subsequently, the values ​​can be periodically calibrated based on the false alarm rate and updated smoothly.

[0034] The above calculation measures both the deviation of the current short-term request rate from the historical baseline request rate and the growth of the request rate between adjacent short-term windows. This ensures that continuous and stable high-frequency access is mainly reflected by the request frequency anomaly degree x1, while access that suddenly accelerates in a short period of time is mainly reflected by the burst request anomaly degree x2, thereby reducing the duplication of measurement of the same anomaly by both.

[0035] When obtaining the client's failure rate anomaly score x3, first obtain the client's request failure rate fr for the target interface within the most recent set time (e.g., 5 minutes), and obtain the preset failure rate threshold fthreshold. Then, based on fr and fthreshold, calculate the client's failure rate anomaly score x3. The formula for calculating this failure rate anomaly score x3 is as follows: x3 = min(1, fr / fthreshold) When obtaining the client's device fingerprint volatility x4, the client's device feature set is first obtained and compared with the device feature set of the client's last trusted request. The number of changed device features (cchanged) is counted, and the total number of device features participating in the comparison (ctotal) is also obtained. Then, based on cchanged and ctotal, the client's device fingerprint volatility is calculated. The formula for calculating the device fingerprint volatility x4 is as follows: x4 = cchanged / ctotal When obtaining the client's network environment risk level x5, the following steps are included: First, the server extracts the source network type and proxy network or anonymous network marker (to determine subsequent y1), historical abnormal records of the source IP or ASN (to determine subsequent y2), the number of changes in the source IP network segment, ASN or region within a preset time window (to determine subsequent y3), the number of devices or accounts associated with the same source IP or ASN, and the number of source networks traversed by the same device (to determine subsequent y4) from the connection information of the interface access request and the local network reputation record. Second, the above information is converted into source network infrastructure risk y1, network historical reputation risk y2, network affiliation change risk y3, and identity aggregation risk y4, respectively, within the range of 0 to 1.

[0036] In one possible implementation, when determining the source network infrastructure risk y1 based on the source network type and the proxy network or anonymous network label, the process includes: first, mapping the source network type to a base score z_type∈[0,1], where the base score is lower for residential or mobile networks, higher for data centers or cloud hosts, and highest for anonymous networks; then, obtaining the identification confidence score z_anon∈[0,1] for the proxy network or anonymous network based on the proxy network or anonymous network label; finally, calculating the source network infrastructure risk y1 based on the base score z_type and the identification confidence score z_anon for the proxy network or anonymous network, where the calculation formula for y1 is as follows: y1=min(1,α×z_type+(1-α)×z_anon) Where α is a preset weighting coefficient between 0 and 1.

[0037] In one possible implementation, when determining the network historical reputation risk y2 based on historical anomaly records of the source IP or ASN, the process includes: first, performing statistical analysis on the historical anomaly records of the source IP or ASN, and calculating the historical anomaly quantities h_ip and h_asn associated with the source IP and ASN within a preset window, weighted according to event severity and time decay; then, normalizing and fusing them according to thresholds to obtain the network historical reputation risk y2, where the calculation formula for y2 is as follows: y2=min(1,γ×min(1,h_ip / H_ip)+(1-γ)×min(1,h_asn / H_asn)) Where γ is a preset weight coefficient between 0 and 1, and H_ip and H_asn are the corresponding historical outlier thresholds.

[0038] In one possible implementation, the network affiliation change risk y3 can be determined based on the ratio of the number of changes in the source IP network segment, ASN, or region within a preset time window to the corresponding change threshold. Specifically, the number of changes in the IP network segment, ASN, and region within the preset time window is first obtained and denoted as c_ip, c_asn, and c_region, respectively. Then, the network affiliation change risk y3 is calculated based on the number of changes in the IP network segment c_ip, the number of changes in the ASN c_asn, and the number of changes in the region c_region within the preset time window. The calculation formula for the network affiliation change risk y3 is as follows: y3=min(1,max(c_ip / c_ip0,c_asn / c_asn0,c_region / c_region0)) Wherein, c_ip0, c_asn0, and c_region0 are the threshold values ​​for the number of changes set for IP network segments, ASNs, and regions within a preset time window, respectively.

[0039] When using only one change indicator, the formula for calculating the network affiliation change risk y3 can be simplified to y3=min(1,c_change / c_threshold).

[0040] In one possible implementation, the identity aggregation risk y4 can be determined based on the greater of the number of devices associated with the same source IP or ASN and the number of source networks traversed by the same device within a preset time window. Specifically, first, the number of different devices or accounts associated with the same source IP or ASN within the preset time window, n_id, is counted. Then, the number of different source IP network segments or ASNs traversed by the same device within the preset time window, n_net, is counted. Next, n_id and n_net are normalized to y4a=min(1, n_id / N_id) and y4b=min(1, n_net / N_net), respectively. Here, N_id represents a reference threshold for the number of different devices or accounts associated with the same source IP or ASN within the preset time window, used to measure the degree of abnormality of "multiple identities sharing the same source network"; when n_id reaches N_id, the corresponding normalized risk y4a=min(1, n_id / N_id) reaches 1, and is truncated by the min function after exceeding this threshold. N_net represents a reference threshold for the number of different source IP network segments or ASNs traversed by the same device within a preset time window. It is used to measure the anomaly degree of "a single device frequently traversing different source networks". When n_net reaches N_net, the corresponding normalized risk y4b=min(1, n_net / N_net) reaches 1. After exceeding this threshold, it is also truncated by the min function. Both N_id and N_net should be set to positive numbers greater than 0. They can be determined based on the statistical distribution of normal business traffic samples, such as the high quantile value of normal samples, combined with business security policies. Different thresholds can be used in different business scenarios.

[0041] Finally, the identity aggregation risk y4 is determined based on y4a and y4b, where y4 = max(y4a, y4b). In this way, any obvious "multiple identities sharing the network" or "single device frequently crossing networks" in either direction can be considered a high risk of identity aggregation.

[0042] Third, based on the source network infrastructure risk y1, network historical reputation risk y2, network affiliation change risk y3, and identity aggregation risk y4, the network environment risk level x5 is calculated. The formula for calculating the network environment risk level x5 is as follows: y5 = max(y1×y3, y2×y4) x5 = min(1, w51×y1 + w52×y2 + w53×y3 + w54×y4 + w55×y5) Among them, y5 represents the risk of abnormal network interactions, while w51, w52, w53, w54, and w55 all have non-negative weights, and their sum is 1. The interaction risk y5 is used to amplify the risk when multiple network anomalies occur simultaneously: for example, when anonymous networks and frequent network attribution changes occur simultaneously, or when historical malicious networks and multiple device aggregations occur simultaneously, even if each individual risk has not yet reached a high-risk threshold, the overall network environment risk level can be increased. This avoids the vulnerability of attackers who can circumvent attacks by switching proxy nodes or network exits by relying solely on a single IP blacklist.

[0043] When obtaining the client's historical reputation risk score x6, first retrieve the N most recent historical access events associated with the client, account identifier, or device summary. The server presets an event risk value si between 0 and 1 for different types of historical access events. For example, a normal access that passes verification on the first attempt is set to 0, a challenge timeout or ordinary request failure is set to a lower risk value, an invalid computational access proof is set to a higher risk value, and a challenge number reuse, proof replay, or challenge parameter forgery is set to 1. For the i-th historical access event, the time decay weight di is calculated based on the time interval ti from the current time: di = exp(-ti / tau) Here, tau is the preset decay period, with more recent historical events corresponding to greater time decay weights. Then, the basic historical risk rh is calculated based on the event risk value and time decay weight of each historical access event: rh = (d1×s1 + d2×s2 + ... + dN×sN) / (d1 + d2 + ... + dN) Further, obtain the number L of recent consecutive abnormal events for this client, and calculate the consecutive abnormality amplification factor c = min(1, L / Lmax), where Lmax is a preset threshold for the number of consecutive abnormal events. The historical reputation risk score x6 can be determined according to the following formula: x6 = min(1, rh ×(1 + eta×c)) Here, eta is a parameter for amplifying continuous anomalies that is greater than 0. Time decay gradually reduces the impact of earlier, sporadic anomalies, while continuous anomaly amplification rapidly elevates the risk level of actions such as submitting invalid proofs or replaying within a short period. When a client lacks sufficient historical samples, an initial historical reputation risk level can be set based on information such as whether it is logged in and whether it has trusted device records, and this level can be updated as described above after accumulating valid historical samples.

[0044] In a possible implementation, the historical performance compensation coefficient P of a client can be determined according to the generation time fed back by its historical computation-based access proof. Specifically, the average completion time tavg for the client to complete the generation of computation-based access proof feedback in the last N times is obtained first, and the reference completion time tref preset by the server is obtained, then the historical performance compensation coefficient of the client is calculated based on tavg and tref. Wherein, the calculation formula of the historical performance compensation coefficient P is as follows: P = min(2, max(0.5, tref / tavg)) When the client's historical completion speed is relatively fast, P increases; when the client's historical completion speed is relatively slow, P decreases.

[0045] It can be known from the above formula that when tavg=tref, P=1, which indicates that the client's historical speed for completing the computation challenge is equivalent to the reference speed; when tavg<tref, tref / tavg is greater than 1, and P increases as the client's historical completion speed increases; when tavg>tref, tref / tavg is less than 1, and P decreases as the client's historical completion speed decreases. Further, when tavg is not greater than 0.5×tref, P is limited to an upper limit of 2; when tavg is not less than 2×tref, P is limited to a lower limit of 0.5; when tavg is between 0.5×tref and 2×tref, P changes continuously according to tref / tavg.

[0046] Since the historical performance compensation coefficient P participates in the multiplication calculation of the number of iterations I, clients with strong computing power and faster historical completion speed will be assigned more iterations, while clients with weak computing power and slower historical completion speed will be assigned fewer iterations, so that the actual time required for devices with different performances to complete the challenge tends to be similar. Limiting P between 0.5 and 2 ensures on the one hand that the challenge difficulty of low-performance clients will not be reduced indefinitely, and retains the minimum computing cost and lower security limit; on the other hand, it avoids excessive access delay caused by unlimited increase in challenge difficulty for high-performance clients. The upper and lower limits can also reduce the benefit of clients continuously lowering the subsequent challenge difficulty by deliberately delaying historical proofs.

[0047] To mitigate the impact of random fluctuations and varying historical challenge difficulties on the challenge difficulty (tavg), the server can select only historical samples that passed verification within the valid time window. Based on the iteration rounds (I), memory access scale (M), and target difficulty level (Z) corresponding to each historical sample, the actual completion time is converted to the equivalent completion time under the reference challenge difficulty. The tavg is then determined using the median or the average value after removing the maximum and minimum values. If the number of historical samples is insufficient, P=1 can be set. When updating P, a moving average or limiting the magnitude of single changes can be used to avoid significant fluctuations in challenge difficulty caused by network jitter, occasional background tasks, or single abnormal samples.

[0048] It should be further explained that, on the server side, a corresponding interface value coefficient V is pre-assigned to different service interfaces based on the potential business losses or resource consumption caused by abnormal calls. The value coefficient directly reflects the severity of the business loss or the level of resource consumption when the corresponding service interface is subjected to an abnormal call; a higher value coefficient indicates greater business losses or higher server-side resource consumption after the abnormal call. The value coefficient ranges from 0 to 1. As a specific implementation, a common query interface can be set to 0.2, a login or registration interface to 0.5, an SMS sending interface, coupon redemption interface, and pre-payment interface to 0.8, and a high-cost AI inference interface to 1.0. In practical applications, this interface value coefficient can be manually configured, based on historical loss statistics, interface resource consumption statistics, or dynamically generated by business rules. After setting the interface value coefficient for each service interface, the server stores the different service interfaces and their corresponding interface value coefficients in a mapping relationship, thus establishing a local correspondence between each service interface and its interface value coefficient on the server. Based on this, when the client sends an access request to the target interface to the server, the request carries the target interface identifier. After receiving the request, the server parses the target interface identifier from it and queries the mapping relationship stored locally according to the target interface identifier to obtain the interface value coefficient corresponding to the target interface, which can be used to generate calculation challenges in the future.

[0049] In one possible implementation, calculating the interface value coefficient V for each service interface may include the following steps: First, the server determines a business loss score (vL), a resource cost score (vC), an operational sensitivity score (vS), and an abuse amplification score (vA) for each service interface. Specifically, the business loss score (vL) is determined based on the potential direct financial loss, virtual rights loss, or subsequent handling costs caused by a single abnormal call; the resource cost score (vC) is determined based on at least one of the following: CPU time, GPU time, memory usage, number of downstream service calls, and external billing costs consumed by a single interface call; the operational sensitivity score (vS) is determined based on whether the interface involves business rules such as identity authentication, data writing, asset changes, privacy data reading, or irreversible operations; and the abuse amplification score (vA) is determined based on whether a single call will trigger SMS messages, coupons, external payment capabilities, or other business results that can be stacked in batches.

[0050] Second, the business loss score vL, resource cost score vC, operational sensitivity score vS, and abuse amplification score vA are preprocessed to obtain the preprocessed scores.

[0051] Specifically, for the business loss score and resource cost score, log normalization can be used to reduce the dominance of extreme large values ​​on the results. The normalization calculation formula is as follows: vL = min(1, log(1 + L) / log(1 + Lref)); vC = min(1, log(1 + C) / log(1 + Cref)) In the formula, L is the expected business loss of a single abnormal call calculated within the statistical window for this interface, C is the comprehensive resource cost of a single call for this interface, and Lref and Cref are the preset reference values ​​for business loss and resource cost, respectively.

[0052] Operational sensitivity score (vS) and abuse amplification score (vA) can be mapped to a range of 0 to 1 by preset business rules.

[0053] Third, based on the preprocessed business loss score vL, resource cost score vC, operational sensitivity score vS, and abuse amplification score vA, calculate the original value Vraw of the interface value coefficient for each service interface: Vraw = wL×vL + wC×vC + wS×vS + wA×vA In the formula, wL, wC, wS and wA are all non-negative weights and the sum of their weights is 1.

[0054] It should be noted that the manual configuration mentioned above can be used to set the initial scores, reference values ​​and weights of various interfaces; historical loss statistics are used to update L; interface resource consumption statistics are used to update C; and business rules are used to determine vS and vA.

[0055] Fourth, the original value Vraw of the interface value coefficient is smoothly updated to obtain the latest interface value coefficient. This smoothing update operation avoids frequent jumps in the interface value coefficient caused by short-term statistical fluctuations. The calculation formula for smoothing is as follows: Vt = min(1, max(0, (1 - beta)×V(t-1) + beta×Vraw)) Where beta is the update coefficient ranging from 0 to 1, V(t-1) represents the interface value coefficient saved after the previous update cycle or the most recent effective update, and Vt represents the interface value coefficient effective after this smooth update; t represents the update sequence number, which does not need to be equivalent to a specific natural time. For the initial calculation, the manually configured initial value V0 can be used as V(t-1); if there are no historical values, Vt can be directly set to Vraw. The interface value coefficient can be updated over a longer statistical period, with limitations on the magnitude of each update, so that it mainly reflects the inherent business value and resource cost of the interface itself; the short-term anomaly of a single client request is still reflected by the request characteristics and risk bucket B, thus avoiding the duplicate inclusion of the same risk in V and B.

[0056] After obtaining the client's request characteristics, historical performance compensation coefficient P, and the interface value coefficient V of the target interface to be accessed, S1200 can be executed to generate a calculation challenge C based on the client's request characteristics, historical performance compensation coefficient P, and the interface value coefficient V of the target interface to be accessed, and send it to the client.

[0057] In one possible implementation, generating the computational challenge C based on the client's request characteristics, historical performance compensation coefficient P, and the interface value coefficient V of the target interface to be accessed may include the following steps: First, based on the client's request characteristics, calculate risk bucket B. Specifically, first, normalize the request frequency anomaly, sudden request anomaly, failure rate anomaly, device fingerprint fluctuation, network environment risk, and historical reputation risk among the request characteristics to the range of 0 to 1, obtaining the normalized feature value for each request characteristic. The closer the normalized feature value is to 1, the higher the degree of anomaly of that request characteristic. Then, based on the normalized feature values ​​of the above request characteristics, calculate the comprehensive risk score R of the current interface access request. The formula for calculating the comprehensive risk score R is as follows: R = round(100 ×(x1 + x2 + x3 + x4 + x5 + x6) / 6). Finally, based on the comprehensive risk score R, calculate risk bucket B. The formula for calculating risk bucket B is as follows: B = min(4, floor(R / 20)) Here, B ranges from 0 to 4. The larger B is, the higher the risk of the current interface access request, and the higher the difficulty of the subsequent computational challenge. floor represents the floor function, used to return the largest integer not greater than the input value, for example, floor(2.8)=2.

[0058] Second, based on the risk bucket B, the historical performance compensation coefficient P, and the interface value coefficient V, the challenge difficulty parameters are calculated. These parameters include at least one of the following: the number of iteration rounds I, the memory access scale M, and the target difficulty bit depth Z. The specific calculation steps are as follows: First, calculate the number of iteration rounds I in the computational challenge. Specifically, obtain the preset base number of iteration rounds I0, which represents the basic number of computation rounds required under the lowest risk state and the lowest interface value. Then, calculate the number of iteration rounds I based on the base number of iteration rounds I0, the risk bucket B, the historical performance compensation coefficient P, and the interface value coefficient V. The formula for calculating the number of iteration rounds I is as follows: I = floor(I0 × (1 + B) × (1 + V) × P) That is, the higher the risk bucket B and the higher the interface value coefficient V, the more rounds of calculation the client needs to perform.

[0059] Secondly, the memory access scale M in the computational challenge is calculated. Specifically, the preset number of basic memory blocks M0 is obtained; then, the memory access scale M is calculated based on the number of basic memory blocks M0 and the risk bucket B. The formula for calculating the memory access scale M is as follows: M = floor(M0 × (1 + B)) That is, the higher the risk bucket B, the more local memory blocks the client needs to access when performing computational challenges.

[0060] Next, calculate the target difficulty digit Z in the challenge. Specifically, obtain the preset base difficulty digit Z0; then, calculate the target difficulty digit Z based on the base difficulty digit Z0 and risk bucket B. The formula for calculating the target difficulty digit Z is as follows: Z = Z0 + B That is, the higher the risk bucket B, the higher the difficulty requirement that the final computational access proof must meet, meaning that the more leading bits of zero need to be in the computational access proof data.

[0061] At this point, the server has obtained the challenge difficulty parameters, including the number of iteration rounds I, the memory access scale M, and the target difficulty bit depth Z, for use in generating subsequent computational challenges.

[0062] The iteration round number I, memory access scale M, and target difficulty bit depth Z mentioned above correspond to the serial computation volume, working memory usage, and expected number of random number search attempts, respectively. They are not repeated adjustments to the same cost dimension. This implementation adopts a layered design of "risk-driven, interface value and device performance only adjusting the computational dimension that can be continuously and smoothly": the risk bucket B acts on I, M, and Z simultaneously, so that high-risk requests increase costs in the three dimensions of computation, memory, and probabilistic search; the interface value coefficient V and the historical performance compensation coefficient P act only on the iteration round number I, and are used to continuously and smoothly adjust the overall computation time without significantly changing the client's instantaneous memory usage and probabilistic search fluctuations.

[0063] The iteration round number I uses a multiplicative combination of (1+B), (1+V) and P to generate a superimposed amplification effect on requests with high risk and high target interface value, rather than simply adding the factors together and having them cancel each other out. At the same time, B, V and P all have a clear range of values, making the changes in I predictable and configurable.

[0064] The memory access scale M changes only with the risk bucket B because the impact of memory usage on low-performance devices and mobile devices is usually higher than that of an equal amount of hash iteration. If V or P is added, it is easy to generate excessive instantaneous memory demand due to high-value interfaces or high-performance devices. Binding M to B can mainly increase memory costs for high-risk batch concurrency and parallel computing behaviors.

[0065] The number of bits in the target difficulty Z also changes discretely with the risk bucket B because the probability of a single hit when the first Z bits of Proof are 0 is about 2 to the power of -Z. For every 1 bit increase in Z, the client's expected number of random number attempts roughly doubles. If V or P is directly applied to Z, it is easy to produce exponential amplification and drastic fluctuations in completion time.

[0066] Thus, V and P achieve fine-grained adjustment through I, while B achieves tiered reinforcement of high-risk requests through M and Z, forming mutual constraints between security, predictability, and fairness among different devices.

[0067] Third, based on the calculated challenge difficulty parameters, a computational challenge C is generated. The specific calculation steps for computational challenge C are as follows: First, obtain the server's key Ks, the server's random number Ns, the client's device digest D, the target interface identifier E, and the time slice T.

[0068] First, it's important to clarify that the client's device digest D is a relatively stable subset of features selected from the current device feature set. These features include, for example, application instance identifier, operating system type and version range, hardware capability level, and browser or client type. After field normalization, sorting, concatenation, and hashing with the server-side salt value, a fixed-length digest is obtained. Frequently changing fields in the current device feature set, such as network addresses and timestamps, are not included in the generation of device digest D, or are first discretized through segmentation and rounding before being used to avoid challenge binding failure due to normal environmental fluctuations. In other words, the device digest here is used to bind the computational challenge to a specific client device. The device fingerprint volatility x4 mentioned above measures the degree of change between the current device feature set and the device feature set corresponding to the last trusted request. It is mainly used to assess the risk of device changes. Although both originate from the device feature set, their purposes are completely different.

[0069] The time slice T is used to confine the challenge seed and its corresponding computational access proof within a predetermined time window. This allows the same device to obtain different challenge seeds for the same target interface in different time slices, and enables the server to determine whether the challenge has crossed the valid time window during the verification phase. This reduces the possibility of attackers pre-compiling proofs in batches or replaying historical proofs across time windows. The time slice T is determined by the server based on its current time and the preset time slice length. The client directly uses the T issued by the server without relying on its local clock. The formula for calculating the time slice T is as follows: T = floor(timestamp / Delta) Here, timestamp is the current time on the server, and Delta is the preset time slice length, such as 30 seconds or 60 seconds.

[0070] The time slice length Delta can be configured or periodically updated based on the target interface type, the current challenge difficulty, and the client's historical performance. As a specific approach, the server first estimates the time t_est required for the client to complete the challenge based on the number of iterations I, memory access scale M, target difficulty digit Z, and historical performance compensation coefficient P. Then, it obtains the preset quantile value t_net of the recent network round-trip latency for this type of client and determines the time slice length according to the following formula: Delta = min(Delta_max, max(Delta_min, ceil(k × (t_est + t_net)))) Delta_min and Delta_max represent the minimum and maximum allowed time slice lengths, respectively; k is a safety margin coefficient greater than 1; and ceil represents the floor function. For high-risk buckets or high-value interfaces, a smaller Delta_max can be set to shorten the time window for proving exploitability; for mobile clients with weak historical performance but good reputation, Delta can be appropriately increased without exceeding the safety limit. A default time slice length, such as 60 seconds, is used when historical samples are lacking. The server associates the selected Delta with the challenge number cid for storage, ensuring the same time window rules are applied during the verification phase.

[0071] Secondly, based on the server-side key Ks, server-side random number Ns, client-side device digest D, target interface identifier E, and time slice T, combined with the challenge difficulty parameter, a challenge seed S is generated. The formula for calculating the challenge seed S is as follows: S = HMAC(Ks, D || E || T || Ns || I || M || Z) In the formula, HMAC is a data authentication code generated based on a key and a hash function, used to prevent the challenge parameters from being forged or tampered with. HMAC can also be replaced by server signature or a key digest algorithm.

[0072] Next, based on the server-side random number Ns, the target interface identifier E, the time slice T, the challenge difficulty parameter, and the challenge seed S, a computational challenge C is generated. The computational challenge C can be represented as: C = {cid, Ns, E, T, I, M, Z, S} Wherein, cid is the challenge number generated by calculating challenge C. This challenge number has short-term validity, and the same challenge number can only be used once, or can only be used a limited number of times within a specified time window.

[0073] After generating the computational challenge C, the server sends it to the client. Upon receiving the computational challenge C from the server, the client executes the corresponding computational task locally, generates a computational access certificate, and sends it back to the server.

[0074] In one possible implementation, when the client performs the computational challenge C and generates the corresponding computational access proof feedback, it may include the following steps: First, generate a request digest Q based on the interface access request.

[0075] Specifically, the client obtains the request method (method), interface path (URI), request body digest (bodyDigest), and request initiation timestamp from the current interface access request, and performs a hash operation on the above parameters using a preset hash function H to obtain the request digest (Q). Q = H(method || uri || bodyDigest || timestamp) Here, H is a hash function used to map input data to a fixed-length digest, which can be SHA-256, SHA-3, SM3, or other fixed-length digest algorithms. The request body digest, bodyDigest, is the digest value obtained by the client after hashing the request body content in the interface access request. Incorporating the request digest Q into subsequent calculations binds the final computational access proof feedback to the specific interface access request, thus preventing the reuse of the same computational access proof feedback across different interface requests.

[0076] Second, based on the request digest Q, the random number n selected by the client, and the challenge difficulty parameters and challenge seed S recorded in the computation challenge, a computational access proof feedback Request is generated.

[0077] Specifically, the client first generates a random number n, and performs a hash operation on the challenge seed S, the request digest Q, and the random number n to generate the initial calculated value v0 for chained computation: v0 = H(S || Q || n) At the same time, the client initializes the local memory array A based on the memory access scale M and challenge seed S recorded in the computation challenge C: A[k] = H(S || k), 0 ≤ k <M Where A[k] is the initial value stored in memory block k in memory array A during the initialization phase. This initial value is obtained by hashing the challenge seed S and the memory block number k together, so that different challenges and different memory blocks in the same challenge have mutually distinguishable pseudo-random content. k is a general index from 0 to M-1 when initializing the array.

[0078] Then, the client performs I rounds of chained computation and memory access hybrid computation based on the iteration round number I recorded in computation challenge C. During the j-th round of computation: 1) Determine the memory block index idxj that needs to be accessed in this round: idxj = H(v(j-1) || j) mod M In the formula, v(j-1) is the intermediate calculated value output in the (j-1)th round, M is the memory access scale M recorded in the calculation challenge C, idxj is the memory block index accessed in the jth round, and A[idxj] is the current value of the memory block corresponding to this index.

[0079] 2) Generate the current round's calculated value vj: vj = H(v(j-1) || A[idxj] || j) In the formula, A[idxj] is the current value stored before the update of the memory block selected according to the memory block number idxj in the j-th round of calculation. This value is not only involved in the generation of the value vj in this round of calculation, but is also updated according to vj after the end of this round, so that the memory access results of subsequent rounds depend on the previous calculation path.

[0080] 3) Update memory block A[idxj]: A[idxj] = H(A[idxj]|| vj) Where j ranges from 1 to 1, mod represents the modulo operation, idxj is the memory block number accessed in the j-th round, and vj is the intermediate calculated value output in the j-th round.

[0081] In other words, in each round of calculation, the client accesses a position in the memory array A, uses the value stored at that position to participate in the hash operation, and then updates the value at that position with a new hash value.

[0082] After completing round I of computation, the client generates a computational access proof, Proof, based on the challenge seed S, request digest Q, random number n, and the final round's computation value vI. Proof = H(S || Q || n || vI) The computational access proof Proof refers to the proof data generated by the client after completing local computation based on the computational challenge issued by the server, which is used to indicate that the client has paid a certain computational cost for this interface request.

[0083] Based on this, the client needs to verify whether the generated Proof meets the difficulty requirement corresponding to the target difficulty bit Z recorded in the computation challenge C, that is, the first Z bits of the Proof are all 0. If the difficulty requirement is met, the current computational access proof Proof is accepted; if not, the client changes the random number n and re-executes the above steps of initial calculation value generation, memory array initialization, I-round chained computation, and Proof generation based on the new random number until a Proof that satisfies the requirement of the first Z bits being 0 is generated.

[0084] Finally, the client assembles the original API access request (originalRequest), challenge number (cid), client-selected random number (n), last-round calculated value (vI), and computational access proof (Proof) into a computational access proof feedback request, and submits it to the server. This computational access proof feedback request can be represented as: Request = {originalRequest, cid, n, vI, Proof} By submitting the original interface access request along with the computational access proof feedback, the server can recalculate the request digest based on the original interface access request for use in the subsequent proof verification process.

[0085] After the client submits a computational access proof feedback request, the server will execute step S1300, receiving the computational access proof feedback submitted by the client after completing the computation challenge. In step S1400, based on the computational access proof feedback, the server verifies whether the client has access rights to the target interface.

[0086] In one possible implementation, when the server verifies whether the client has access rights to the target interface based on computational access proof feedback, it may include the following steps: First, the server verifies whether the challenge ID (cid) carried in the computational access proof feedback exists, has expired, and has already been used. Specifically, the server maintains a local list of used challenge IDs and their generation times. After parsing the challenge ID (cid) from the computational access proof feedback, the server first checks if the challenge ID exists in the local record. If it does not exist, the verification fails. If it exists, the server further obtains the generation time of the challenge ID and determines whether the current time has exceeded the valid time window of the challenge ID. If it has, the verification fails. Simultaneously, the server checks whether the challenge ID has already been used. If it has been used, the verification fails. In other words, each challenge ID is only allowed to be used once and is only valid within its corresponding short-term valid time window to prevent replay attacks.

[0087] Second, if the above verification passes, the challenge seed S is recalculated based on the target interface identifier E, the client device digest D stored on the server, the server-side random number Ns, the time slice T, the number of iteration rounds I, the memory access scale M, the target difficulty bit depth Z, and the server-side key Ks. Specifically, when the server generates the computational challenge C in step S1200, it has already stored the challenge number cid corresponding to this challenge in the server's local cache or memory in the form of a mapping relationship with the server-side key Ks, client device digest D, target interface identifier E and time slice T, challenge difficulty parameter, and server-side random number Ns used to generate the challenge. Therefore, during the verification phase, the server can retrieve the server-side key Ks, client device digest D, target interface identifier E and time slice T, server-side random number Ns, and challenge difficulty parameter used to generate the challenge from the local cache based on the challenge number cid parsed from the computational access proof feedback, and recalculate the challenge seed S using the same method.

[0088] Third, based on the original interface access request `originalRequest` carried in the computational access proof feedback, a new request digest `Q` is generated. See above for details, which will not be repeated here.

[0089] Fourth, based on the recalculated request digest Q, the client random number n carried in the computational access proof feedback, the recalculated challenge seed S, and the challenge difficulty parameters recorded in the computational challenge, I rounds of chained computation and memory access hybrid computation are re-executed to obtain the verification value vI' of the last round of computation.

[0090] Fifth, based on the challenge seed S, request digest Q, client random number n, and the verification value vI' of the last round of calculation, a new computational access proof verification value Proof' is generated: Proof' = H(S|| Q|| n || vI') Sixth, compare the newly generated computational access proof verification value Proof' with the Proof submitted by the client in the computational access proof feedback. If they do not match, the verification fails; if they match, proceed to the next step.

[0091] Seventh, check if the first Z bits of Proof' are all 0. If any of the first Z bits of Proof' are not 0, the check fails; if the first Z bits are all 0, proceed to the next step.

[0092] Eighth, verify whether the time slice T is still within the valid time window.

[0093] If all checks from step one to step eight above pass, the server determines that the client has access to the target interface and allows the access request, permitting the client to enter the business processing flow of the target interface. If any of the above checks fails, the server determines that the client does not have access to the target interface and rejects the access request.

[0094] In one possible implementation, after the server verifies whether the client has access to the target interface based on computational access proof feedback, it updates the state variables and policy configurations for the next interface access request based on the verification result and the client's subsequent access behavior, without directly rewriting the iteration round number I, memory access scale M, or target difficulty bit Z in the already generated computational challenge. The state variables may include rolling statistics for calculating request features x1 to x6, valid historical samples for calculating the historical performance compensation coefficient P, and basic parameter configurations I0, M0, Z0, and the upper limit of the challenge validity period selected according to the client type or server load. When the next request arrives, the server recalculates the comprehensive risk score R, risk bucket B, historical performance compensation coefficient P, and interface value coefficient V according to the aforementioned steps, and then generates I, M, and Z based on the corresponding formulas. Therefore, the following statement about increasing or decreasing the difficulty of subsequent challenges refers to triggering the next adaptive calculation after updating the above state variables or selecting the corresponding basic parameter configuration, rather than skipping the aforementioned calculation process and directly assigning values ​​to I, M, or Z.

[0095] First, when the server detects that the same client initiates multiple consecutive API access requests to the same high-value target API within a preset time window, it records this access behavior in the rolling statistics corresponding to request frequency, sudden request anomaly, and historical reputation. This increases the abnormality of the request frequency (x1), the abnormality of sudden requests (x2), and / or the risk level of historical reputation (x6) for the next request, thereby increasing the risk bucket (B) through a comprehensive risk score (R). The API value coefficient (V) is still determined by the business loss, resource cost, and business rule evaluation results of the API, and is not directly modified due to the short-term behavior of a single client, so as to avoid double-counting request risk with the inherent value of the API.

[0096] Second, when the server detects that the same client submits multiple invalid computational access proofs consecutively, it records invalid proofs, expired challenges, repeated use of challenge numbers, or proof replay as high-risk historical access events, increasing the historical reputation risk level x6 and the overall risk score R of the next request. Simultaneously, a smaller challenge validity period can be selected for that client. The subsequent iteration round number I, memory access scale M, and target difficulty bit depth Z are still recalculated based on the updated B, P, V, and basic parameters.

[0097] Third, when the server detects that the client can stably complete the computational challenge without abnormal access behavior in a preset number of consecutive interface accesses, it writes the above successful events into the historical reputation record. This allows earlier abnormal events to reduce their impact according to the time decay mechanism, thereby naturally decreasing the historical reputation risk level x6 and risk bucket B of the next request. The historical performance compensation coefficient P is still determined only based on the performance sample of the client completing the challenge, and is not directly reduced due to good reputation, thus avoiding conflating device performance and behavioral reputation as the same adjustment factor.

[0098] Fourth, when the server load exceeds a preset load threshold, the server can select load protection basic parameter configurations for anonymous requests or requests with a comprehensive risk score R greater than the preset risk threshold. Specifically, the load protection basic iteration round number I0_load must be no less than the default basic iteration round number I0, the load protection basic memory block number M0_load must be no less than the default basic memory block number M0, and / or the load protection basic difficulty bit width Z0_load must be no less than the default basic difficulty bit width Z0. Subsequently, the server recalculates I, M, and Z by substituting the selected basic parameters into the aforementioned formula; once the server load recovers, the default basic parameter configuration is restored.

[0099] Fifth, upon obtaining the client's device performance information or remaining battery power information, and determining that the client is a mobile client with a reputation score higher than the preset reputation threshold, the server can select a low memory base parameter configuration for it, making the number of base memory blocks M0_mobile less than the default number of base memory blocks M0, while keeping the base difficulty bit Z0 unchanged. If necessary, the base iteration round number I0 can be appropriately increased within the expected completion time not exceeding the challenge validity period to partially compensate for the reduced computational cost caused by the reduced memory access scale. Subsequently, I, M, and Z of this challenge are still calculated according to the updated base parameters, B, P, and V.

[0100] This disclosure provides an interface access verification method, including: receiving an interface access request initiated by a client; responding to the interface access request; obtaining the client's request characteristics, historical performance compensation coefficient, and the interface value coefficient of the target interface to be accessed; generating a computational challenge based on the request characteristics, historical performance compensation coefficient, and interface value coefficient, and sending it to the client; receiving a computational access proof submitted by the client after completing the computational challenge; and verifying whether the client has access rights to the target interface based on the computational access proof feedback. This disclosure transforms interface access verification from a one-way risk assessment by the server to a two-way verification mechanism where the client bears verifiable computational costs, by requiring the client to complete the computational challenge issued by the server and submit verifiable computational access proof before obtaining access rights to the target interface. This prevents attackers from bypassing verification at low cost by batch changing IPs, device identifiers, or request parameters. Furthermore, by dynamically generating the computational challenge based on request characteristics, historical performance compensation coefficient, and interface value coefficient, the computational costs borne by the client can be adaptively adjusted according to the request risk and the value of the target interface. By increasing the computational cost of the client initiating invalid requests, the amount of data from a large number of invalid requests can be suppressed, thereby avoiding the burden of a large number of invalid requests on the server's invalid request processing and the waste of computational resources.

[0101] Furthermore, by binding the computational access proof to the request digest, target interface identifier, client device digest, and time slice of the interface access request, the generated computational access proof cannot be reused for other interface requests or other clients, reducing the risk of proof pre-computation or reuse attacks. Simultaneously, by setting challenge numbers with short-term validity and one-time use restrictions, attackers cannot bypass the verification by intercepting and replaying historical computational access proofs, further enhancing the security of interface access verification. Moreover, compared to traditional CAPTCHA schemes that require manual user interaction and are easily bypassed by automated recognition technologies, this solution's computational challenge is automatically calculated by the client in the background, without affecting the normal user's workflow or causing interruptions, maintaining a good user experience while ensuring security.

[0102] <Device Embodiment> Figure 2 A schematic block diagram of an interface access verification apparatus according to an embodiment of the present disclosure is shown. Figure 2 As shown, the device 100 includes: The data acquisition module 110 is used to receive interface access requests initiated by the client, respond to interface access requests, and acquire the client's request characteristics, historical performance compensation coefficients, and the interface value coefficient of the target interface to be accessed. The computational challenge initiation module 120 is used to generate computational challenges based on request characteristics, historical performance compensation coefficients, and interface value coefficients, and send them to the client. The computational access proof receiving module 130 is used to receive feedback on the computational access proof submitted by the client after completing the computational challenge; The access permission verification module 140 is used to verify whether the client has access permission to the target interface based on computational access proof feedback.

[0103] <Equipment Example> Figure 3 A schematic block diagram of an interface access verification device according to an embodiment of the present disclosure is shown. Figure 3 As shown, the interface access verification device 200 includes a processor 210 and a memory 220 for storing executable instructions of the processor 210. The processor 210 is configured to implement any of the interface access verification methods described above when executing the executable instructions.

[0104] It should be noted here that the number of processors 210 can be one or more. Furthermore, the interface access verification device 200 in this embodiment may also include an input device 230 and an output device 240. The processors 210, memory 220, input device 230, and output device 240 can be connected via a bus or other means, without specific limitations here.

[0105] The memory 220, as a computer-readable storage medium, can be used to store software programs, computer-executable programs, and various modules, such as the program or module corresponding to the interface access verification method of this disclosure embodiment. The processor 210 executes various functional applications and data processing of the interface access verification device 200 by running the software program or module stored in the memory 220.

[0106] Input device 230 can be used to receive input digital numbers or signals. These signals may include key signals related to user settings and function control of the device / terminal / server. Output device 240 may include a display device such as a screen.

[0107] <Storage Medium Examples> According to a fourth aspect of this disclosure, a non-volatile computer-readable storage medium is also provided, on which computer program instructions are stored, which, when executed by processor 210, implement any of the interface access verification methods described above.

[0108] The various embodiments of this disclosure have been described above. These descriptions are exemplary and not exhaustive, and are not limited to the disclosed embodiments. Many modifications and variations will be apparent to those skilled in the art without departing from the scope and spirit of the described embodiments. The terminology used herein is chosen to best explain the principles, practical applications, or technical improvements to the technology in the market, or to enable others skilled in the art to understand the embodiments disclosed herein.

Claims

1. An interface access verification method, characterized in that, include: Receive an interface access request initiated by a client, respond to the interface access request, and obtain the client's request characteristics, historical performance compensation coefficient, and interface value coefficient of the target interface to be accessed. Based on the request characteristics, the historical performance compensation coefficient, and the interface value coefficient, a calculation challenge is generated and sent to the client. Specifically, a risk bucket is calculated based on the request characteristics. Based on the risk bucket, the historical performance compensation coefficient, and the interface value coefficient, calculate the challenge difficulty parameter; Based on the challenge difficulty parameters, the calculation challenge is generated and sent to the client; Receive feedback from the client after completing the computational challenge, including the computational access proof submitted by the client. Based on the computational access proof feedback, verify whether the client has access rights to the target interface; The historical performance compensation coefficient is determined based on the generation time of the client's historical computational access proof feedback.

2. The method according to claim 1, characterized in that, The request characteristics include at least one of the following: request frequency anomaly, sudden request anomaly, failure rate anomaly, device fingerprint fluctuation, network environment risk, and historical reputation risk.

3. The method according to claim 2, characterized in that, When obtaining the abnormality level of the sudden request, the following is included: The number of requests made by the client to the target interface within the current short time window, the number of requests made to the target interface within the long time window preceding the current short time window, and the number of requests made to the target interface within the previous short time window adjacent to the current short time window are obtained. Based on the number of requests made by the client to the target interface within the current short time window, the number of requests made to the target interface within the long time window preceding the current short time window, and the number of requests made to the target interface within the previous short time window adjacent to the current short time window, the current short-term request rate within the current short time window, the historical baseline request rate within the long time window, and the previous short-term request rate within the previous short time window are calculated respectively. Based on the current short-term request rate, the historical baseline request rate within the long-term window, and the previous short-term request rate within the previous short-term window, calculate the burst multiple and growth rate of the burst requests. Based on the burst multiple and the growth rate, the burst request anomaly degree of the client is calculated.

4. The method according to claim 1, characterized in that, The challenge difficulty parameters include at least one of the following: the number of iteration rounds, the memory access scale, and the number of bits for the target difficulty in the computational challenge.

5. The method according to claim 1, characterized in that, When generating the computational challenge based on the challenge difficulty parameters, the process includes: Obtain the server's key, the server's random number, the client's device digest, the target interface identifier, and the time slice; A challenge seed is generated based on the server's key, the server's random number, the client's device digest, the target interface identifier, the time slice, and the challenge difficulty parameter. The computational challenge is generated based on the server's random number, the target interface identifier, the time slice, the challenge difficulty parameter, and the challenge seed.

6. The method according to claim 5, characterized in that, When the client executes the computational challenge and generates the computational access proof feedback, it includes: Generate a request digest based on the interface access request; Based on the request digest, the random number selected by the client, and the challenge difficulty parameter and challenge seed recorded in the computational challenge, the computational access proof feedback is generated.

7. An interface access verification device, characterized in that, include: The data acquisition module is used to receive interface access requests initiated by the client, respond to the interface access requests, and acquire the client's request characteristics, historical performance compensation coefficients, and the interface value coefficient of the target interface to be accessed. The computational challenge initiation module is used to generate a computational challenge based on the request characteristics, the historical performance compensation coefficient, and the interface value coefficient, and send it to the client. Specifically, it calculates the risk bucket based on the request characteristics. Based on the risk bucket, the historical performance compensation coefficient, and the interface value coefficient, calculate the challenge difficulty parameter; Based on the challenge difficulty parameters, the calculation challenge is generated and sent to the client; The computational access proof receiving module is used to receive the computational access proof feedback submitted by the client after completing the computational challenge; The access permission verification module is used to verify whether the client has access permission to the target interface based on the computational access proof feedback. The historical performance compensation coefficient is determined based on the generation time of the client's historical computational access proof feedback.

8. The apparatus according to claim 7, characterized in that, The request characteristics include at least one of the following: request frequency anomaly, sudden request anomaly, failure rate anomaly, device fingerprint fluctuation, network environment risk, and historical reputation risk.

9. An interface access verification device, characterized in that, include: processor; Memory used to store processor-executable instructions; The processor is configured to implement the method of any one of claims 1 to 6 when executing the executable instructions.

10. A non-volatile computer-readable storage medium storing computer program instructions thereon, characterized in that, When the computer program instructions are executed by the processor, they implement the method described in any one of claims 1 to 6.

Images