Number resource exception anti-refreshing method, device and equipment, medium and product

Abstract

The embodiment of the invention provides a number resource exception anti-refreshing method and device, equipment, a medium and a product, and relates to the technical field of network security. The method comprises the following steps: receiving a query request sent by a request end; substituting the query request into a preset verification model to obtain a request verification result and request error reporting information; when the request verification result is that the request verification fails, sending request error reporting information to the request end and the management end; and when the request verification result is that the request verification succeeds, sending a query request to the number card resource end, so that the number card resource end queries the number according to the query request and sends the number to the request end. According to the method, an anti-refreshing verification end is additionally arranged between a request end and a number card resource end, a query request is verified through a verification model, and error reporting information is returned when an abnormal request is detected, so that the problem that number resources are occupied abnormally is solved, and illegal users are prevented from occupying high-quality number resources for a long time; and the query experience of the user and the resource management efficiency of the operator are improved.

Description

Technical Field

[0001] This application relates to the field of network security technology, and in particular, to a method, device, equipment, medium and product for preventing abnormal brushing of number resources. Background Art

[0002] Number resources are the collection of telephone numbers legally obtained and managed by telecommunications operators. These number resources are not only the unique identifier of users' communication services, but also the core carrier for operators to carry out business. High-quality numbers, such as lucky numbers or consecutive numbers, often have the ability of brand premium, which can improve user stickiness and market competitiveness, while ordinary numbers ensure the universality of basic communication services.

[0003] In the prior art, users mainly browse the number resource library through platforms such as the operator's online business hall or official application. The system will classify and display according to the number type, and provide filtering functions with conditions such as area code and digital combination. Users can use the filtering function to complete the query and selection of high-quality numbers.

[0004] However, there is a problem of abnormal occupation of number resources in the prior art. That is, some illegal users cause the long-term occupation of high-quality number resources provided by telecommunications operators through high-frequency query and occupation behaviors. This behavior not only affects the query experience of normal users, making it difficult for them to obtain their favorite numbers, but also has a negative impact on the resource management and service quality of operators. Summary of the Invention

[0005] Embodiments of this application provide a method, device, equipment, medium and product for preventing abnormal brushing of number resources, so as to solve the problem of abnormal occupation of number resources in the prior art.

[0006] In a first aspect, embodiments of this application provide a method for preventing abnormal brushing of number resources, which is applied to the anti-brushing verification end of a number resource anti-brushing system. The number resource anti-brushing system further includes a request end, a number card resource end and a management end. The method includes:

[0007] Receiving a query request sent by the request end;

[0008] Substituting the query request into a preset verification model to obtain a request verification result and a request error message; wherein, the request verification result includes request verification success and request verification failure, and the request error message is used to indicate the reason for the request verification failure;

[0009] When the request verification result is request verification failure, sending the request error message to the request end and the management end;

[0010] When the request verification result is that the request verification is successful, send the query request to the SIM card resource end, so that the SIM card resource end queries the number according to the query request and sends the number to the request end.

[0011] In a possible design, the query request includes a first request and a second request, the preset verification model includes a Hypertext Transfer Protocol request verification model and an interface request verification model, and substituting the query request into the preset verification model to obtain a request verification result and a request error message includes:

[0012] Substitute the first request into the Hypertext Transfer Protocol request verification model to obtain a first verification result and a first error message; wherein, the first request refers to a Hypertext Transfer Protocol request, and the first verification result includes successful protocol request verification and failed protocol request verification;

[0013] Substitute the second request into the interface request verification model to obtain a second verification result and a second error message; wherein, the second request refers to an interface request, and the second verification result includes successful interface request verification and failed interface request verification.

[0014] In a possible design, the first request includes multiple protocol request parameters, a request token, a protocol request address, and a protocol request access count. Substituting the first request into the Hypertext Transfer Protocol request verification model to obtain a first verification result and a first error message includes:

[0015] Match the first request with a preset attack pattern database to obtain a first matching result and a third error message; wherein, the first matching result includes first matching success and first matching failure, and the third error message is used to indicate that the first request is an abnormal network attack request;

[0016] When the first matching result is the first matching success, determine the failed protocol request verification as the first verification result and the third error message as the first error message;

[0017] When the first matching result is the first matching failure, verify the multiple protocol request parameters according to a preset parameter verification rule to obtain a protocol parameter verification result and a fourth error message; wherein, the protocol parameter verification result includes successful protocol parameter verification and failed protocol parameter verification, and the fourth error message is used to indicate that the multiple protocol request parameters are illegal;

[0018] When the protocol parameter verification result is the failed protocol parameter verification, determine the failed protocol request verification as the first verification result and the fourth error message as the first error message;

[0019] When the protocol parameter verification result is that the protocol parameter verification is successful, verify the request token according to a preset token verification rule to obtain a token verification result and a fifth error message; wherein, the token verification result includes successful token verification and failed token verification, and the fifth error message is used to indicate that the request token is illegal;

[0020] When the token verification result is that the token verification fails, determine that the protocol request verification fails as the first verification result, and determine the fifth error message as the first error message;

[0021] When the token verification result is that the token verification is successful, verify the protocol request address according to a preset address verification rule to obtain a protocol address verification result and a sixth error message; wherein, the protocol address verification result includes successful protocol address verification and failed protocol address verification, and the sixth error message is used to indicate that the protocol request address is illegal;

[0022] When the protocol address verification result is that the protocol address verification fails, determine that the protocol request verification fails as the first verification result, and determine the sixth error message as the first error message;

[0023] When the protocol address verification result is that the protocol address verification is successful and the protocol request access times do not exceed a preset protocol request access times threshold, determine that the protocol request verification is successful as the first verification result, and set the first error message to be empty.

[0024] In a possible design, the second request includes multiple interface request parameters, interface permissions, interface request addresses, interface signatures, request timestamps, multiple service information, and interface request access times. Substituting the second request into the interface request verification model to obtain a second verification result and a second error message includes:

[0025] Match the second request with a preset attack pattern database to obtain a second matching result and a seventh error message; wherein, the second matching result includes second matching success and second matching failure, and the seventh error message is used to indicate that the second request is an abnormal network attack request;

[0026] When the second matching result is that the second matching is successful, determine that the interface request verification fails as the second verification result, and determine the seventh error message as the second error message;

[0027] When the second matching result is the second matching failure, the multiple interface request parameters are verified according to a preset parameter verification rule to obtain an interface parameter verification result and an eighth error message; wherein, the interface parameter verification result includes successful interface parameter verification and failed interface parameter verification, and the eighth error message is used to indicate that the multiple interface request parameters are illegal;

[0028] When the interface parameter verification result is failed interface parameter verification, determine the interface request verification failure as the second verification result and the eighth error message as the second error message;

[0029] When the interface parameter verification result is successful interface parameter verification, the interface permission is verified according to a preset permission verification rule to obtain a permission verification result and a ninth error message; wherein, the permission verification result includes successful permission verification and failed permission verification, and the ninth error message is used to indicate that the interface permission is illegal;

[0030] When the permission verification result is failed permission verification, determine the interface request verification failure as the second verification result and the ninth error message as the second error message;

[0031] When the permission verification result is successful permission verification, the interface request address is verified according to a preset address verification rule to obtain an interface address verification result and a tenth error message; wherein, the interface address verification result includes successful interface address verification and failed interface address verification, and the tenth error message is used to indicate that the interface request address is illegal;

[0032] When the interface address verification result is failed interface address verification, determine the interface request verification failure as the second verification result and the tenth error message as the second error message;

[0033] When the interface address verification result is successful interface address verification, the interface signature is verified according to a preset signature verification rule to obtain a signature verification result and an eleventh error message; wherein, the signature verification result includes successful signature verification and failed signature verification, and the eleventh error message is used to indicate that the interface signature is illegal;

[0034] When the signature verification result is failed signature verification, determine the interface request verification failure as the second verification result and the eleventh error message as the second error message;

[0035] When the signature verification result is that the signature verification is successful, verify the request timestamp according to a preset timestamp verification rule to obtain a timestamp verification result and a twelfth error message; wherein, the timestamp verification result includes successful timestamp verification and failed timestamp verification, and the twelfth error message is used to indicate that the request timestamp is illegal;

[0036] When the timestamp verification result is that the timestamp verification fails, determine that the interface request verification fails as the second verification result, and determine the twelfth error message as the second error message;

[0037] When the timestamp verification result is that the timestamp verification is successful, verify the multiple service information according to a preset service verification rule to obtain a service verification result and a thirteenth error message; wherein, the service verification result includes successful service verification and failed service verification, and the thirteenth error message is used to indicate that the multiple service information is illegal;

[0038] When the service verification result is that the service verification fails, determine that the interface request verification fails as the second verification result, and determine the thirteenth error message as the second error message;

[0039] When the service verification result is that the service verification is successful and the number of interface request accesses does not exceed a preset interface request access number threshold, determine that the interface request verification is successful as the second verification result, and set the second error message to be empty.

[0040] In a possible design, the sending the request error message to the request end and the management end includes:

[0041] Send the request error message to the request end;

[0042] Generate an alarm message according to the query request and the request error message;

[0043] Send the alarm message to the management end.

[0044] In a possible design, after sending the query request to the SIM card resource end, further include:

[0045] Obtain a first query request volume and an order generation volume within a preset first time period in the past, and a second query request volume within a preset second time period in the past; wherein, the end time of the first time period is earlier than the start time of the second time period;

[0046] When the difference between the first query request volume and the second query request volume is greater than a preset difference threshold, a query volume warning message is generated, and the query volume warning message is sent to the management terminal;

[0047] When the ratio of the first query request volume to the order generation volume is less than a preset ratio threshold, an order volume warning message is generated, and the order volume warning message is sent to the management terminal.

[0048] In a second aspect, an embodiment of the present application provides a device for preventing abnormal brushing of number resources, which is applied to the anti-brushing verification end of a number resource abnormal anti-brushing system. The number resource abnormal anti-brushing system further includes a request end, a number card resource end, and a management end. The device includes:

[0049] A receiving module, configured to receive a query request sent by the request end;

[0050] An input module, configured to substitute the query request into a preset verification model to obtain a request verification result and a request error message; wherein, the request verification result includes successful request verification and failed request verification, and the request error message is used to indicate the reason for the failed request verification;

[0051] A first sending module, configured to send the request error message to the request end and the management end when the request verification result is failed request verification;

[0052] A second sending module, configured to send the query request to the number card resource end when the request verification result is successful request verification, so that the number card resource end queries a number according to the query request and sends the number to the request end.

[0053] In a possible design, the query request includes a first request and a second request, the preset verification model includes a Hypertext Transfer Protocol request verification model and an interface request verification model, and the input module includes:

[0054] A first input unit, configured to substitute the first request into the Hypertext Transfer Protocol request verification model to obtain a first verification result and a first error message; wherein, the first request refers to a Hypertext Transfer Protocol request, and the first verification result includes successful protocol request verification and failed protocol request verification;

[0055] A second input unit, configured to substitute the second request into the interface request verification model to obtain a second verification result and a second error message; wherein, the second request refers to an interface request, and the second verification result includes successful interface request verification and failed interface request verification.

[0056] In a possible design, the first request includes multiple protocol request parameters, a request token, a protocol request address, and the number of protocol request accesses. The first input unit includes:

[0057] A first matching component, configured to match the first request with a preset attack pattern database to obtain a first matching result and a third error message; wherein, the first matching result includes a first match success and a first match failure, and the third error message is used to indicate that the first request is an abnormal network attack request;

[0058] A first confirmation component, configured to, when the first matching result is the first match success, determine the protocol request verification failure as the first verification result, and determine the third error message as the first error message;

[0059] A protocol request parameter verification component, configured to, when the first matching result is the first match failure, verify the multiple protocol request parameters according to a preset parameter verification rule to obtain a protocol parameter verification result and a fourth error message; wherein, the protocol parameter verification result includes a protocol parameter verification success and a protocol parameter verification failure, and the fourth error message is used to indicate that the multiple protocol request parameters are illegal;

[0060] A second confirmation component, configured to, when the protocol parameter verification result is the protocol parameter verification failure, determine the protocol request verification failure as the first verification result, and determine the fourth error message as the first error message;

[0061] A request token verification component, configured to, when the protocol parameter verification result is the protocol parameter verification success, verify the request token according to a preset token verification rule to obtain a token verification result and a fifth error message; wherein, the token verification result includes a token verification success and a token verification failure, and the fifth error message is used to indicate that the request token is illegal;

[0062] A third confirmation component, configured to, when the token verification result is the token verification failure, determine the protocol request verification failure as the first verification result, and determine the fifth error message as the first error message;

[0063] A protocol request address verification component, configured to, when the token verification result is the token verification success, verify the protocol request address according to a preset address verification rule to obtain a protocol address verification result and a sixth error message; wherein, the protocol address verification result includes a protocol address verification success and a protocol address verification failure, and the sixth error message is used to indicate that the protocol request address is illegal;

[0064] A fourth confirmation component, configured to, when the protocol address verification result is that the protocol address verification fails, determine the protocol request verification failure as the first verification result and determine the sixth error message as the first error message;

[0065] A protocol request access count verification component, configured to, when the protocol address verification result is that the protocol address verification is successful and the protocol request access count does not exceed a preset protocol request access count threshold, determine the protocol request verification success as the first verification result and set the first error message to be empty.

[0066] In a possible design, the second request includes multiple interface request parameters, interface permissions, interface request addresses, interface signatures, request timestamps, multiple service information, and an interface request access count. The second input unit includes:

[0067] A second matching component, configured to match the second request with a preset attack pattern database to obtain a second matching result and a seventh error message; wherein the second matching result includes second matching success and second matching failure, and the seventh error message is used to indicate that the second request is an abnormal network attack request;

[0068] A fifth confirmation component, configured to, when the second matching result is second matching success, determine the interface request verification failure as the second verification result and determine the seventh error message as the second error message;

[0069] An interface request parameter verification component, configured to, when the second matching result is second matching failure, verify the multiple interface request parameters according to preset parameter verification rules to obtain an interface parameter verification result and an eighth error message; wherein the interface parameter verification result includes interface parameter verification success and interface parameter verification failure, and the eighth error message is used to indicate that the multiple interface request parameters are illegal;

[0070] A sixth confirmation component, configured to, when the interface parameter verification result is interface parameter verification failure, determine the interface request verification failure as the second verification result and determine the eighth error message as the second error message;

[0071] An interface permission verification component, configured to, when the interface parameter verification result is interface parameter verification success, verify the interface permissions according to preset permission verification rules to obtain a permission verification result and a ninth error message; wherein the permission verification result includes permission verification success and permission verification failure, and the ninth error message is used to indicate that the interface permissions are illegal;

[0072] The seventh confirmation component is used to, when the permission verification result is that the permission verification fails, determine that the interface request verification fails as the second verification result and determine the ninth error message as the second error message;

[0073] The interface request address verification component is used to, when the permission verification result is that the permission verification is successful, verify the interface request address according to a preset address verification rule to obtain an interface address verification result and a tenth error message; wherein, the interface address verification result includes that the interface address verification is successful and that the interface address verification fails, and the tenth error message is used to indicate that the interface request address is illegal;

[0074] The eighth confirmation component is used to, when the interface address verification result is that the interface address verification fails, determine that the interface request verification fails as the second verification result and determine the tenth error message as the second error message;

[0075] The interface signature verification component is used to, when the interface address verification result is that the interface address verification is successful, verify the interface signature according to a preset signature verification rule to obtain a signature verification result and an eleventh error message; wherein, the signature verification result includes that the signature verification is successful and that the signature verification fails, and the eleventh error message is used to indicate that the interface signature is illegal;

[0076] The ninth confirmation component is used to, when the signature verification result is that the signature verification fails, determine that the interface request verification fails as the second verification result and determine the eleventh error message as the second error message;

[0077] The request timestamp verification component is used to, when the signature verification result is that the signature verification is successful, verify the request timestamp according to a preset timestamp verification rule to obtain a timestamp verification result and a twelfth error message; wherein, the timestamp verification result includes that the timestamp verification is successful and that the timestamp verification fails, and the twelfth error message is used to indicate that the request timestamp is illegal;

[0078] The tenth confirmation component is used to, when the timestamp verification result is that the timestamp verification fails, determine that the interface request verification fails as the second verification result and determine the twelfth error message as the second error message;

[0079] The service information verification component is used to, when the timestamp verification result is that the timestamp verification is successful, verify the multiple service information according to a preset service verification rule to obtain a service verification result and a thirteenth error message; wherein, the service verification result includes that the service verification is successful and that the service verification fails, and the thirteenth error message is used to indicate that the multiple service information is illegal;

[0080] The eleventh confirmation component is used to, when the service verification result is that the service verification fails, determine that the interface request verification fails as the second verification result and determine the thirteenth error message as the second error message.

[0081] The request access times verification component is used to, when the service verification result is that the service verification is successful and the interface request access times do not exceed the preset interface request access times threshold, determine that the interface request verification is successful as the second verification result and set the second error message to be empty.

[0082] In a possible design, the first sending module includes:

[0083] The request error message sending component is used to send the request error message to the request end.

[0084] The alarm information generating component is used to generate alarm information according to the query request and the request error message.

[0085] The alarm information sending component is used to send the alarm information to the management end.

[0086] In a possible design, the number resource abnormal anti-brush device further includes:

[0087] The obtaining module is used to obtain the first query request volume and order generation volume within a preset first time period in the past, and the second query request volume within a preset second time period in the past; wherein, the end time of the first time period is earlier than the start time of the second time period.

[0088] The query volume warning information generating module is used to, when the difference between the first query request volume and the second query request volume is greater than the preset difference threshold, generate query volume warning information and send the query volume warning information to the management end.

[0089] The order volume warning information generating module is used to, when the ratio of the first query request volume to the order generation volume is less than the preset ratio threshold, generate order volume warning information and send the order volume warning information to the management end.

[0090] In a third aspect, the present application provides an electronic device, including: a processor and a memory communicatively connected to the processor;

[0091] The memory stores computer execution instructions;

[0092] When the processor executes the computer execution instructions stored in the memory, it is used to implement the number resource abnormal anti-brush method as described in any item of the first aspect.

[0093] Fourthly, the present application provides a computer-readable storage medium storing computer-executable instructions, which, when executed by a processor, are used to implement the method for preventing abnormal brushing of number resources according to any one of the first aspect.

[0094] Fifthly, the present application provides a computer program product including a computer program, which, when executed by a processor, is used to implement the method for preventing abnormal brushing of number resources according to any one of the first aspect.

[0095] A method, device, equipment, medium and product for preventing abnormal brushing of number resources provided by the present application, the method includes: receiving a query request sent by the requesting end; substituting the query request into a preset verification model to obtain a request verification result and a request error message; when the request verification result is that the request verification fails, sending the request error message to the requesting end and the management end; when the request verification result is that the request verification succeeds, sending the query request to the number card resource end, so that the number card resource end queries a number according to the query request and sends the number to the requesting end. The method for preventing abnormal brushing of number resources of the present application solves the problem of abnormal occupation of number resources by constructing an anti-brushing verification mechanism. This method adds an anti-brushing verification end between the requesting end and the number card resource end, and intercepts and verifies the query request through a preset verification model: when an abnormal request is detected, an error message containing specific failure reasons is immediately returned to the requesting end and the alarm management end is synchronized, blocking the abnormal occupation behavior; only legal requests that pass the verification are released to the number card resource end, thus ensuring the fairness of the number query service. This mechanism effectively prevents illegal users from occupying high-quality number resources for a long time, improving the query experience of normal users and the resource management efficiency of operators. Description of the Drawings

[0096] The drawings here are incorporated into the description and form a part of this description, showing embodiments consistent with the present application and used together with the description to explain the principles of the present application.

[0097] Figure 1 It is a schematic diagram of the application scenario of the method for preventing abnormal brushing of number resources provided by the embodiment of the present application;

[0098] Figure 2 It is a flowchart of the method for preventing abnormal brushing of number resources provided by the embodiment of the present application Figure 1 ;

[0099] Figure 3 It is a flowchart of the method for preventing abnormal brushing of number resources provided by the embodiment of the present application Figure 2 ;

[0100] Figure 4 This is a schematic structural diagram of the abnormal anti-brushing device for number resources provided by the embodiments of the present application;

[0101] Figure 5 This is a schematic hardware structure diagram of the electronic device provided by the embodiments of the present application.

[0102] Through the above-mentioned drawings, specific embodiments of the present application have been shown, and there will be more detailed descriptions hereinafter. These drawings and textual descriptions are not intended to limit the scope of the concept of the present application in any way, but to illustrate the concept of the present application to those skilled in the art by referring to specific embodiments. Specific Embodiments

[0103] Exemplary embodiments will be described in detail herein, and examples thereof are shown in the drawings. When the following description refers to the drawings, unless otherwise indicated, the same numbers in different drawings represent the same or similar elements. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with the present application. On the contrary, they are merely examples of devices and methods consistent with some aspects of the present application as detailed in the appended claims.

[0104] In the embodiments of the present application, terms such as "first" and "second" are used to distinguish the same or similar items with basically the same functions and roles. Those skilled in the art can understand that terms such as "first" and "second" do not limit the quantity and execution order, and "first" and "second" do not necessarily mean different. It should be noted that in the embodiments of the present application, words such as "exemplary" or "for example" are used to represent examples, illustrations, or explanations. Any embodiment or design solution described as "exemplary" or "for example" in the present application should not be construed as being more preferred or having more advantages than other embodiments or design solutions. Exactly speaking, using words such as "exemplary" or "for example" is intended to present relevant concepts in a specific manner. In the embodiments of the present application, "at least one" means one or more, and "a plurality" means two or more.

[0105] It should be noted that the user information (including but not limited to user device information, user personal information, etc.) and data (including but not limited to data for analysis, stored data, displayed data, etc.) involved in the present application are all information and data that have been authorized by the user or fully authorized by all parties, and the collection, use, and processing of the relevant data need to comply with relevant laws, regulations, and standards, and corresponding operation entrances are provided for the user to select authorization or rejection.

[0106] It should be noted that in the embodiments of the present application, "when...", can refer to an instant when a certain situation occurs, or a period of time after a certain situation occurs. The embodiments of the present application do not make specific limitations on this. In addition, a method, device, equipment, medium, and product for preventing abnormal brushing of number resources provided by the embodiments of the present application are only examples, and a method, device, equipment, medium, and product for preventing abnormal brushing of number resources may also include more or less content.

[0107] To facilitate a clear description of the technical solutions of the embodiments of the present application, some of the terms and technologies involved in the embodiments of the present application are briefly introduced below:

[0108] Hypertext Transfer Protocol request: It refers to a request sent by a client, such as a browser or an application, to a server to obtain resources or perform operations. A Hypertext Transfer Protocol request usually includes a request method, a protocol version, and optional request headers and a request body. Hypertext Transfer Protocol requests are the basis of network communication and support data transmission between the client and the server.

[0109] Interface request: It refers to a request sent by an application to another software system through a programming interface to perform a specific function or obtain data. Interface requests usually use standard protocols and follow a specific format for data exchange. Through interface requests, an application can interact with other systems to achieve function expansion, data sharing, and service integration.

[0110] Token: It is a digital credential used for authentication and authorization. It is usually generated by the server and distributed to the client to verify the user's identity or access rights in subsequent requests. A token can contain user information, permission scope, and validity period, etc., and is usually stored in an encrypted form to ensure security.

[0111] Here, the exemplary embodiments will be described in detail, and the examples are shown in the drawings. When the following description refers to the drawings, unless otherwise indicated, the same numbers in different drawings represent the same or similar elements. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with the present invention. On the contrary, they are only examples of devices and methods consistent with some aspects of the present invention as detailed in the appended claims.

[0112] The technical solutions of the present invention will be described in detail below with specific embodiments. These specific embodiments can be combined with each other, and the same or similar concepts or processes may not be repeated in some embodiments. The embodiments of the present invention will be described below in conjunction with the drawings.

[0113] To clearly understand the technical solution of this application, the solutions of the prior art will be introduced in detail first. Number resources are the collection of telephone numbers legally obtained and managed by telecom operators. These number resources are not only the unique identifiers of user communication services, but also the core carriers for operators to carry out their businesses. High-quality numbers, such as lucky numbers or consecutive numbers, often have the ability to generate brand premiums, which can enhance user stickiness and market competitiveness, while ordinary numbers ensure the universality of basic communication services.

[0114] In the prior art, users mainly browse the number resource library through platforms such as the operator's online business hall or official application. The system will classify and display according to the number type and provide filtering functions with conditions such as area code and digital combination. Users can use the filtering function to complete the query and selection of high-quality numbers. However, in the prior art, some illegal users cause the long-term occupation of high-quality number resources provided by telecom operators through high-frequency query and occupation behaviors. This behavior not only affects the query experience of normal users, making it difficult for them to obtain their desired numbers, but also has an impact on the operator's resource management and service quality. Therefore, there is a problem of abnormal occupation of number resources in the prior art.

[0115] Therefore, in view of the problem of abnormal occupation of number resources in the prior art, it is found in the research that to solve this problem, an anti-abuse mechanism can be introduced to verify and restrict the user's query behavior, so as to prevent high-frequency illegal query and occupation behaviors: ① A hierarchical request verification system can be established to implement differentiated security policies for different types of access requests. The system can dynamically detect request characteristics and automatically intercept abnormal requests. ② Multi-factor authentication, such as device binding or dynamic tokens, can be used to ensure the credibility of the user's identity, and based on a credit evaluation system, such as historical behavior or consumption records, the access rights can be dynamically adjusted. High-credit users can enjoy more number query rights, while low-credit or anonymous users are restricted in access frequency or function scope. ③ The request characteristics can be analyzed in real time, enabling the system to adaptively adjust the verification intensity. For example, low-frequency normal requests are released, while high-frequency or abnormal requests trigger enhanced verification. While ensuring the user experience, automated tool and script attacks are intercepted.

[0116] Specifically:

[0117] An intelligent anti-brushing and dynamic control system can be constructed. First, through real-time request analysis, such as parameter verification, access frequency monitoring, and abnormal behavior detection, etc., suspicious queries are intercepted. Secondly, token verification and signature verification are used to ensure the legality of requests. Then, through the mechanism of batch release of numbers and reservation lock-up period, centralized preemption is prevented. At the same time, a credit evaluation system is established to restrict high-frequency and low-efficiency queries. Finally, through real-time monitoring and early warning on the management side, the protection strategy is dynamically adjusted. While ensuring the normal user experience, this system effectively identifies and blocks automated scripts and abnormal requests, realizing the fair and reasonable allocation of number resources.

[0118] A method, device, equipment, medium, and product for preventing abnormal brushing of number resources according to an embodiment of the present application adds an anti-brushing verification end between the request end and the number card resource end, and intercepts and verifies the query request through a preset verification model: when an abnormal request is detected, an error message containing specific failure reasons is immediately returned to the request end and the alarm management end is synchronized, blocking the abnormal occupation behavior; only the legitimate requests that pass the verification are released to the number card resource end, thereby ensuring the fairness of the number query service. This mechanism effectively prevents illegal users from occupying high-quality number resources for a long time, improves the query experience of normal users and the resource management efficiency of operators, and solves the problem of abnormal occupation of number resources in the prior art.

[0119] Based on the above creative findings, the technical solution of the present application is proposed.

[0120] The application scenario of the method for preventing abnormal brushing of number resources provided by the embodiment of the present invention is introduced below. Figure 1 It is a schematic diagram of the application scenario of the method for preventing abnormal brushing of number resources provided by an embodiment of the present application. As Figure 1 shown, this application scenario includes a request end 101 and a server 102. The server 102 includes an anti-brushing verification end 1021, a number card resource end 1022, and a management end 1023. The request end 101 sends a query request to the anti-brushing verification end 1021. The anti-brushing verification end 1021 substitutes the query request into a preset verification model to obtain a request verification result and a request error message. When the request verification result is that the request verification fails, the anti-brushing verification end 1021 sends the request error message to the request end 101 and the management end 1023. When the request verification result is that the request verification is successful, the anti-brushing verification end 1021 sends the query request to the number card resource end 1022. The number card resource end 1022 queries the number according to the query request and sends the number to the request end 101.

[0121] The embodiment of the present invention is introduced below in conjunction with the accompanying drawings of the specification.

[0122] Figure 2 It is a flow schematic Figure 1 of the method for preventing abnormal brushing of number resources provided by an embodiment of the present application. AsFigure 2 As shown in Figure 2 , in this embodiment, the execution subject of the embodiment of the present invention is an anti-brush verification end. Then the method for preventing abnormal brushing of number resources provided in this embodiment includes the following steps:

[0123] S201. Receive the query request sent by the request end.

[0124] Specifically, the query request sent by the request end can be received through the network communication service deployed by the operator server. The anti-brush verification end monitors the preset ports or interfaces in real time and receives the number query requests initiated from the user's online channels, such as mobile applications or web pages. Its role is to build a data transmission channel between the request end and the anti-brush system, providing the original request data for the subsequent verification process, so as to be verified through the verification model later, thereby judging the validity of the query request.

[0125] S202. Substitute the query request into the preset verification model to obtain the request verification result and the request error message; among them, the request verification result includes request verification success and request verification failure, and the request error message is used to indicate the reason for the request verification failure.

[0126] Specifically, machine learning algorithms or rule engines can be used to analyze and judge the validity of the query request. The verification model can be trained based on historical data and known abnormal request patterns, or a series of rules can be set to identify abnormal request behaviors. The purpose of this process is to quickly identify potential abnormal requests in an automated manner, prevent the abuse or abnormal brushing of number resources, thereby improving the security and resource utilization efficiency of the system. When the verification model detects that the request does not meet the preset standards, it will generate a request error message, indicating the specific reason for the failure, so that the request end and the management end can take corresponding measures for processing.

[0127] S203. When the request verification result is request verification failure, send the request error message to the request end and the management end.

[0128] Specifically, the error message can be transmitted through the communication module or message queue in the system. When the verification model determines that the request verification fails, the system will automatically generate an error message containing the reason for the error and send this message to the request end and the management end through the preset communication protocol or interface. The purpose of this is to timely notify the request end of the specific reason for the request failure so that it can make adjustments or corrections, and at the same time notify the management end to monitor and handle potential security threats, thereby maintaining the overall security and stability of the system.

[0129] S204. When the request verification result is request verification success, send the query request to the number card resource end, so that the number card resource end queries the number according to the query request and sends the number to the request end.

[0130] Specifically, the query request can be sent through the internal communication interface or application interface call of the system. After the verification model confirms that the request is valid, the system will automatically forward the original query request to the SIM card resource side. After receiving the request, the SIM card resource side retrieves the corresponding number resources according to the query conditions and returns the results to the request side. The purpose of doing this is to ensure that only verified and legitimate requests can access the number resources, thereby effectively preventing the resources from being abnormally swiped, and at the same time ensuring that the request side can obtain the required number information in a timely manner.

[0131] A method for preventing abnormal swiping of number resources provided in this embodiment includes: receiving a query request sent by a request side; substituting the query request into a preset verification model to obtain a request verification result and a request error message; when the request verification result is that the request verification fails, sending the request error message to the request side and the management side; when the request verification result is that the request verification succeeds, sending the query request to the SIM card resource side, so that the SIM card resource side queries numbers according to the query request and sends the numbers to the request side. A method for preventing abnormal swiping of number resources achieves the following technical effects: An anti-swiping verification end is added between the request side and the SIM card resource side in this method, and the query request is intercepted and verified through a preset verification model: when an abnormal request is detected, an error message containing the specific failure reason is immediately returned to the request side and the warning management side is synchronized, blocking the abnormal occupation behavior; only legitimate requests that pass the verification are released to the SIM card resource side, thereby ensuring the fairness of the number query service. This mechanism effectively prevents illegal users from occupying high-quality number resources for a long time, improves the query experience of normal users and the resource management efficiency of operators, and solves the problem of abnormal occupation of number resources by constructing an anti-swiping verification mechanism.

[0132] In a possible design, the query request includes a first request and a second request, and the preset verification model includes a Hypertext Transfer Protocol request verification model and an interface request verification model. S202. Substituting the query request into the preset verification model to obtain a request verification result and a request error message includes:

[0133] S2021. Substituting the first request into the Hypertext Transfer Protocol request verification model to obtain a first verification result and a first error message; wherein, the first request refers to a Hypertext Transfer Protocol request, and the first verification result includes successful protocol request verification and failed protocol request verification.

[0134] Specifically, the validity of the request can be determined by parsing the various components of the Hypertext Transfer Protocol (HTTP) request, such as the request method, locator, header information, and parameters. The verification model can be based on preset rules or trained through machine learning algorithms to identify abnormal request patterns. In this way, the system can quickly identify and filter out potential abnormal HTTP requests, generating a first verification result and a first error message to ensure that only HTTP requests that meet the security standards can be further processed.

[0135] S2022. Substitute the second request into the interface request verification model to obtain a second verification result and a second error message, where the second request refers to the interface request, and the second verification result includes successful interface request verification and failed interface request verification.

[0136] Specifically, the validity of the interface request can be judged by analyzing features such as the specific parameters of the interface request, call frequency, authentication information, and request source. The interface request verification model can be trained based on a series of preset rules or through machine learning techniques to identify abnormal interface call behaviors. Through this verification, the system can generate a second verification result and a second error message, clearly indicating whether the request is valid or what problems exist. The purpose of this process is to ensure the security of the interface request, prevent abnormal requests from abusing or attacking system resources, and thus ensure the normal operation of the system and the effective utilization of resources.

[0137] The technical effect of this solution in this embodiment is that by distinguishing between two types of requests, namely HTTP requests and interface requests, and respectively using targeted verification models for processing, accurate identification and differential protection of different access methods are achieved. This solution can effectively identify and intercept abnormal query requests initiated through different channels, prevent attackers from bypassing the protection using protocol characteristics, and at the same time ensure the normal passage of valid requests. Through the dual-channel parallel verification mechanism, both the system processing efficiency is improved and the comprehensiveness of the defense is enhanced, building a tight protection system for the number resource query service.

[0138] In a possible design, the first request includes multiple protocol request parameters, a request token, a protocol request address, and the number of protocol request accesses. S2021. Substitute the first request into the HTTP request verification model to obtain a first verification result and a first error message, including:

[0139] S20211. Match the first request with a preset attack pattern database to obtain a first matching result and a third error message, where the first matching result includes first matching success and first matching failure, and the third error message is used to indicate that the first request is an abnormal network attack request.

[0140] Specifically, a database containing known attack pattern features can be constructed, and a pattern matching algorithm can be used to compare the features of the first request with the attack patterns in the database. This process can include analyzing the source, frequency, and parameter features of the request to identify whether there is behavior that matches the known attack pattern. Once the match is successful, the system will generate a first matching result and a third error message, clearly indicating that the request may be an abnormal network attack. The purpose of this process is to quickly identify and intercept potential abnormal requests, protect the system from attacks, and ensure the security and stability of the system.

[0141] For example, a general interception mechanism of an application firewall can be deployed. A preset attack pattern database is set in the application firewall. The application firewall performs all-round monitoring, defense and recording of the data flow sent and received from the public network to the number selection service cluster. Once the application firewall detects abnormal behavior, it will immediately block the number selection operation and record the relevant event information in detail. At the same time, it will return a 403 forbidden access error message to the client to resist external illegal attacks. At the same time, real-time alarm functions can also be introduced, such as pushing alarms to system administrators through SMS, email, etc., to respond to and handle large-scale attacks or new attack methods in a timely manner.

[0142] S20212. When the first matching result is a first successful match, determine the protocol request verification failure as the first verification result, and determine the third error information as the first error information.

[0143] Specifically, the system can automatically update the verification results and error information through logical judgment. When the matching algorithm detects that the first request matches a pattern in the attack pattern database, that is, the first match is successful, the system will immediately mark the request as a verification failure and return the corresponding third error information as the first error information. The purpose of this process is to quickly block further operations when potential abnormal requests are detected, and provide clear error feedback so that the request end and the management end can take appropriate protective measures in a timely manner.

[0144] S20213. When the first matching result is a first matching failure, multiple protocol request parameters are verified according to preset parameter verification rules to obtain protocol parameter verification results and fourth error information; wherein the protocol parameter verification results include protocol parameter verification success and protocol parameter verification failure, and the fourth error information is used to indicate that multiple protocol request parameters are in violation.

[0145] Specifically, a parameter verification module with preset parameter verification rules can be set. When the first matching result is a first matching failure, the system will start the parameter verification module to perform a detailed check on each parameter in the request. The preset parameter verification rules may include parameter format, value range, data type, and logical relationship between parameters. By verifying these rules one by one, the system can identify any parameters that do not meet the standards. If a violation is found, the system will generate a result of protocol parameter verification failure and provide a fourth error message, detailing which parameters are non-compliant and why. The purpose of this process is to further filter out potential abnormal requests and ensure the validity of the request parameters, thereby maintaining the security and stability of the system.

[0146] For example, parameter verification can be performed on the query request parameters that call the number selection service, including mandatory field verification to ensure that the request information is complete; data format verification to ensure that the data complies with established specifications; digital range verification to limit the value to a reasonable range; string length verification to prevent attacks with overlong strings; data legitimacy verification to identify the authenticity and compliance of the data. If the verification fails, the number selection will be immediately blocked, and corresponding error messages such as M40 and M17 will be returned.

[0147] S20214. When the protocol parameter verification result is a protocol parameter verification failure, determine the protocol request verification failure as the first verification result, and determine the fourth error information as the first error information.

[0148] Specifically, when the result of the protocol parameter verification is that the protocol parameter verification fails, the system can update the verification status through a logical judgment mechanism. When the parameter verification module detects that one or more parameters in the request do not meet the preset verification rules, that is, the verification fails, the system will immediately mark the entire protocol request as a verification failure. At the same time, the fourth error message will be set as the first error message and returned to the request end and the management end. The purpose of this process is to prevent further processing of the request in a timely manner when the request parameters are not compliant, and to provide clear error feedback so that the request end can make necessary adjustments and let the management end understand potential request problems.

[0149] S20215. When the protocol parameter verification result is that the protocol parameter verification is successful, the request token is verified according to the preset token verification rules to obtain the token verification result and the fifth error message; wherein, the token verification result includes token verification success and token verification failure, and the fifth error message is used to indicate that the request token is in violation of the rules.

[0150] Specifically, after confirming that the request parameters are compliant, the system will continue to verify the token in the request. The token verification rules may include checking the validity, signature, expiration time of the token, and its match with the user identity, etc. Through these rules, the system can verify whether the token is a valid authorization credential. If the token verification fails, the system will generate the corresponding fifth error message, indicating the problems with the token. The purpose of this process is to ensure the authenticity of the request and the effectiveness of authorization, prevent unauthorized access and potential security threats, and thus protect the security of system resources.

[0151] For example, it is required that the query call request for the number selection service must carry a legal token, and the number selection service will strictly verify the legality and timeliness of the token. Once the verification fails, the number selection will be immediately blocked, and error messages such as M12 and M13 will be returned to the client to ensure the security and reliability of the authentication process.

[0152] S20216. When the token verification result is that the token verification fails, determine that the protocol request verification fails as the first verification result, and determine the fifth error message as the first error message.

[0153] Specifically, when the token verification result is that the token verification fails, the system can update the verification status through a logical judgment mechanism. When the token verification module detects that the token in the request does not conform to the preset verification rules, that is, the verification fails, the system will immediately mark the entire protocol request as verification failed. At the same time, the fifth error message will be set as the first error message and returned to the request side and the management side. The purpose of this process is to immediately prevent further processing of the request when the token is illegal or invalid, and provide clear error feedback so that the request side can make necessary adjustments, and at the same time let the management side understand potential security issues and prevent unauthorized access.

[0154] S20217. When the token verification result is that the token verification is successful, verify the protocol request address according to the preset address verification rules to obtain the protocol address verification result and the sixth error message; among them, the protocol address verification result includes successful protocol address verification and failed protocol address verification, and the sixth error message is used to indicate that the protocol request address is illegal.

[0155] Specifically, after confirming that the token is valid, the system will continue to verify the address in the request. The address verification rules may include checking the format of the request address, the legality of the domain name, and whether it matches the known list of abnormal addresses, etc. Through these rules, the system can determine the legality and security of the request address. If the address verification fails, the system will generate the corresponding sixth error message, indicating the problems with the address. The purpose of this process is to ensure the credibility of the request source, prevent requests from abnormal or untrusted sources, and thus enhance the security and reliability of the system.

[0156] For example, black and white lists can be configured for the number selection service. For callers with addresses in the white list, the address restriction policy will not be implemented, and they can directly perform the number selection operation. For callers with addresses in the preset block list, their number selection permissions will be directly restricted, and an M2 error message will be returned, thus achieving differential and precise access control. A hierarchical policy is adopted for callers within the white list, and different levels are given different access permissions and resource quotas to meet diverse business needs.

[0157] S20218: When the protocol address verification result is that the protocol address verification fails, determine that the protocol request verification fails as the first verification result, and determine the sixth error message as the first error message.

[0158] Specifically, when the protocol address verification result is that the protocol address verification fails, the system can update the verification status through a logical judgment mechanism. When the address verification module detects that the address in the request does not conform to the preset verification rules, that is, the verification fails, the system will immediately mark the entire protocol request as verification failed. At the same time, the sixth error message will be set as the first error message and returned to the request side and the management side. The purpose of this process is to promptly prevent further processing of the request when the request address is illegal or untrustworthy and provide clear error feedback so that the request side can make necessary adjustments and the management side can understand potential security issues.

[0159] S20219: When the protocol address verification result is that the protocol address verification is successful and the number of protocol request accesses does not exceed the preset protocol request access count threshold, determine that the protocol request verification is successful as the first verification result, and set the first error message to be empty.

[0160] Specifically, after confirming that the request address is legal and trustworthy, the system will check whether the access count of this request is within the allowed range. By maintaining an access counter, the system can monitor the access frequency of each request and compare it with the preset threshold. If the access count does not exceed the threshold, the system will mark the entire protocol request as verification successful and clear the first error message to indicate that there is no error. The purpose of this process is to ensure that the request not only comes from a legal source but also conforms to a reasonable access frequency, preventing abuse or excessive requests.

[0161] For example, a distributed cache counter can be used to count the number of accesses on the same day. Each time a user accesses, the value of the counter is incremented by 1, and the expiration time is set to 1 day. When the counter for recommended number selection at the same address, the same mobile phone number, or the same ID card exceeds a certain number of times, a new observer blacklist counter is added and incremented by 1 through a command. At the same time, the expiration time is set to one day, and an error message M8 is reported, and the user enters the observer block list. If the counter in the observer block list also exceeds a certain number of times, the user is set to enter the final block list and no expiration time is set, and an error message M9 is reported.

[0162] In this embodiment, the technical effect of this solution is as follows: By constructing a multi-level verification process, progressive security verification is performed on Hypertext Transfer Protocol requests, effectively intercepting various abnormal query behaviors. This method first identifies network attacks through matching with an attack feature library, then sequentially verifies the compliance of request parameters, the validity of tokens, and the legality of access addresses, and finally implements access frequency control, forming a complete protection chain from basic security to business logic. This phased processing mechanism can not only accurately identify different types of illegal requests and return specific error reasons, but also avoid over-interception from affecting normal users, achieving a balance between security and availability and enhancing the anti-brushing ability of the number resource query system.

[0163] In a possible design, the second request includes multiple interface request parameters, interface permissions, interface request addresses, interface signatures, request timestamps, multiple service information, and the number of interface request accesses. In S2022, the second request is substituted into the interface request verification model to obtain a second verification result and a second error message, including:

[0164] In S20221, the second request is matched with a preset attack pattern database to obtain a second matching result and a seventh error message; where the second matching result includes a second match success and a second match failure, and the seventh error message is used to indicate that the second request is an abnormal network attack request.

[0165] Specifically, the system will compare the characteristic parameters of the second request, such as parameters like request source, frequency, content, and pattern, with the known attack characteristics in the attack pattern database. Through this matching process, the system can identify whether the request conforms to the known attack pattern. If the match is successful, the second matching result is generated as successful, and a seventh error message is generated, indicating that the request is a potential abnormal network attack request. This process is used to quickly identify and block abnormal requests and protect system resources from attacks.

[0166] For example, an application firewall can be deployed to intercept common attack types and block abnormal access in real time. Combined with a dynamic rule engine, the protection strategy of the firewall can be adjusted according to the business scenario.

[0167] S20222. When the second matching result is a second match success, determine that the interface request verification fails as the second verification result, and determine the seventh error message as the second error message.

[0168] Specifically, a flag bit or status code can be set. When the second matching result is successful, the system immediately marks the interface request as verification failed. At the same time, take the seventh error message as the second error message, record it and return it to the request side and the management side. This mechanism is used to quickly respond to and process requests identified as abnormal. By immediately terminating the processing of these requests, it prevents further consumption and potential threats to system resources, and at the same time provides detailed error information for managers for subsequent security analysis and countermeasures.

[0169] S20223. When the second matching result is a second match failure, verify multiple interface request parameters according to the preset parameter verification rules to obtain the interface parameter verification result and the eighth error message; among them, the interface parameter verification result includes interface parameter verification success and interface parameter verification failure, and the eighth error message is used to indicate that multiple interface request parameters are illegal.

[0170] Specifically, when the second matching result is a failure, it indicates that the request does not match a known attack pattern. At this time, the system will verify each interface parameter in the request one by one according to the preset parameter verification rules. This can be achieved through a series of verification functions or rule engines to check the format, value range, integrity, etc. of the parameters. According to the verification result, the system generates the interface parameter verification result, marked as success or failure. If the verification fails, the eighth error message is generated to detail the specific reasons for the parameter violation, prevent system misuse or potential security risks caused by parameter anomalies, and at the same time provide clear error feedback for the request side to correct.

[0171] S20224. When the interface parameter verification result is interface parameter verification failure, determine that the interface request verification fails as the second verification result, and determine the eighth error message as the second error message.

[0172] Specifically, when the interface parameter verification result is a failure, the system immediately marks the entire interface request as verification failed, which can be achieved by updating the status of the request or returning a specific error code. At the same time, take the eighth error message as the second error message, record it and feedback it to the request side and the management side. This mechanism is used to quickly terminate the processing of requests that do not conform to the parameter specifications, prevent them from affecting the system, and at the same time provide specific error information for the request side so that it can adjust the parameters and retry the request.

[0173] S20225. When the interface parameter verification result is successful, verify the interface permissions according to the preset permission verification rules to obtain the permission verification result and the ninth error message; where the permission verification result includes successful permission verification and failed permission verification, and the ninth error message is used to indicate interface permission violations.

[0174] Specifically, when the interface parameter verification result is successful, the system will continue with the permission verification and verify the requested interface permissions through the preset permission verification rules. This can be achieved by checking the requester's permission level, access control list, role permission configuration, etc. Based on the verification result, the system generates a permission verification result, marked as successful or failed. If the verification fails, a ninth error message is generated, indicating the specific reason for the permission violation. This process is used to ensure that the requester has the necessary permissions to perform specific operations, thereby protecting the security and integrity of system resources. At the same time, it provides clear permission error feedback to the request side for permission adjustment or request escalation.

[0175] S20226. When the permission verification result is failed permission verification, determine that the interface request verification fails as the second verification result and determine the ninth error message as the second error message.

[0176] Specifically, when the permission verification result is failed, the system immediately marks the entire interface request as verification failed, which can be achieved by updating the request status or returning a specific error code. At the same time, the ninth error message is used as the second error message, recorded and fed back to the request side and the management side. This mechanism is used to quickly prevent unauthorized request operations, prevent unauthorized access or potential abuse of system resources, and at the same time provide detailed permission error information to the request side for permission application or adjustment to ensure that subsequent requests comply with the system's security policy.

[0177] S20227. When the permission verification result is successful permission verification, verify the interface request address according to the preset address verification rules to obtain the interface address verification result and the tenth error message; where the interface address verification result includes successful interface address verification and failed interface address verification, and the tenth error message is used to indicate interface request address violations.

[0178] Specifically, when the permission verification result is successful, the system will continue to verify the interface request address to validate the legitimacy of the request source through preset address verification rules. This can be achieved by checking whether the request address is within the permitted range, complies with geographical location restrictions, and matches the known list of abnormal addresses. Based on the verification result, the system generates an interface address verification result, marked as successful or failed. If the verification fails, the tenth error message is generated, indicating the specific reason for the address violation. This process is used to ensure the credibility and legitimacy of the request source, prevent access from suspicious or abnormal sources, thereby enhancing the security and protection capabilities of the system, and at the same time providing clear address error feedback to the request side for request source adjustment or verification.

[0179] S20228. When the interface address verification result is that the interface address verification fails, determine that the interface request verification fails as the second verification result, and determine the tenth error message as the second error message.

[0180] Specifically, when the interface address verification result is failed, the system will immediately mark the entire interface request as verification failed, which can be achieved by setting the request status to failed or returning a specific error code. At the same time, the tenth error message is used as the second error message, recorded and fed back to the request side and the management side. This mechanism is used to quickly reject requests from untrusted or illegal addresses, prevent potential security threats and system abuse, and at the same time provide detailed address error information to the request side for request source adjustment or further verification.

[0181] S20229. When the interface address verification result is that the interface address verification is successful, verify the interface signature according to the preset signature verification rules to obtain the signature verification result and the eleventh error message; among them, the signature verification result includes signature verification successful and signature verification failed, and the eleventh error message is used to indicate interface signature violation.

[0182] Specifically, when the interface address verification result is successful, the system will continue to verify the interface signature, using the preset signature verification rules to verify the integrity and authenticity of the request. This can be achieved by performing a hash operation on the signature in the request, comparing the expected signature value, and verifying the digital certificate. Based on the verification result, the system generates a signature verification result, marked as successful or failed. If the verification fails, the eleventh error message is generated, indicating the specific reason for the signature violation. This process is used to ensure that the request data has not been tampered with and confirm the legitimate source of the request, thereby protecting the integrity of the data and the security of the communication, and at the same time providing clear signature error feedback to the request side for signature correction or regeneration.

[0183] S20230. When the signature verification result is a signature verification failure, determine that the interface request verification fails as the second verification result, and determine the eleventh error message as the second error message.

[0184] Specifically, when the signature verification result is a failure, the system immediately marks the entire interface request as verification failed, which can be achieved by updating the request status to failed or returning a specific error code. At the same time, the eleventh error message is used as the second error message, recorded and fed back to the request side and the management side. This mechanism is used to quickly reject requests that may have been tampered with, ensure the integrity of data and the credibility of the source, prevent potential security threats and data leaks, and at the same time provide detailed signature error information to the request side so that it can correct the signature or regenerate it, ensuring that subsequent requests meet the security standards of the system.

[0185] S20231. When the signature verification result is a signature verification success, verify the request timestamp according to the preset timestamp verification rule, and obtain the timestamp verification result and the twelfth error message; among them, the timestamp verification result includes timestamp verification success and timestamp verification failure, and the twelfth error message is used to indicate that the request timestamp is illegal.

[0186] Specifically, when the signature verification result is a success, the system will continue to verify the timestamp of the request, using the preset timestamp verification rule to verify the timeliness of the request. This can be achieved by checking whether the difference between the request timestamp and the current server time is within the allowed time window to prevent replay attacks. According to the verification result, the system generates a timestamp verification result, marked as success or failure. If the verification fails, the twelfth error message is generated, indicating the specific reason for the timestamp violation. This process is used to ensure that requests are processed within a reasonable time range, prevent expired or replayed requests from threatening the security of the system, and at the same time provide clear timestamp error feedback to the request side so that it can perform time synchronization or resend the request to ensure that subsequent requests meet the time requirements of the system.

[0187] S20232. When the timestamp verification result is a timestamp verification failure, determine that the interface request verification fails as the second verification result, and determine the twelfth error message as the second error message.

[0188] Specifically, when the timestamp verification result is a failure, the system immediately marks the entire interface request as verification failed, which can be achieved by updating the request status to failed or returning a specific error code. At the same time, the twelfth error message is used as the second error message, recorded and fed back to the request side and the management side. This mechanism is used to quickly reject expired or potentially replayed requests, ensure the timeliness of requests and the security of the system, prevent security threats such as replay attacks, and at the same time provide detailed timestamp error information to the request side so that it can perform time synchronization or resend the request to ensure that subsequent requests meet the time requirements of the system.

[0189] S20233. When the timestamp verification result is that the timestamp verification is successful, multiple business information are verified according to the preset business verification rules to obtain the business verification result and the thirteenth error message; wherein the business verification result includes the business verification success and the business verification failure, and the thirteenth error message is used to indicate that multiple business information is in violation of regulations.

[0190] Specifically, when the timestamp verification result is successful, the system will continue to verify the multiple business information in the request, and use the preset business verification rules to verify its validity and consistency. This can be achieved by checking business logic rules, data formats, dependencies, and interaction results with databases or other systems. Based on the verification results, the system generates a business verification result, marked as success or failure. If the verification fails, a thirteenth error message is generated, indicating the specific reason for the violation of the business information. This process is used to ensure that the business data in the request complies with the business logic and operating specifications of the system, prevent business process interruptions caused by data inconsistencies or errors, and provide clear business error feedback to the request end so that it can correct the data or resubmit the request.

[0191] S20234. When the service verification result is a service verification failure, determine the interface request verification failure as the second verification result, and determine the thirteenth error message as the second error message.

[0192] Specifically, when the business verification result is a failure, the system will immediately mark the entire interface request as a verification failure, which can be achieved by updating the request status to failure or returning a specific error code. At the same time, the thirteenth error message is recorded and fed back to the request end and the management end as the second error message. This mechanism is used to quickly reject requests that do not conform to business logic or operating specifications, ensuring that the system's business processes and data integrity are not affected, and providing detailed business error information to the request end so that it can correct the data and ensure that subsequent requests meet the system's business requirements.

[0193] S20235. When the service verification result is that the service verification is successful, and the number of interface request access times does not exceed the preset interface request access times threshold, the interface request verification success is determined as the second verification result, and the second error information is set to empty.

[0194] Specifically, when the business verification result is successful and the access count of the interface request does not exceed the preset threshold, the system will mark the entire interface request as verified successfully. This can be achieved by updating the request status to successful or returning a successful response code. At the same time, the second error message is set to empty to indicate that no error has occurred. This mechanism is used to confirm that the request not only complies with business logic and operation specifications but also is within a reasonable access frequency range, thus ensuring the effective utilization of system resources and the stability of services. In this way, the system can effectively manage request traffic, prevent abuse, and at the same time provide clear success feedback to the request side to confirm that the request has been successfully processed.

[0195] In this embodiment, the technical effect of this solution is that by establishing a multi-level interface request verification mechanism, multi-dimensional interception of abnormal number selection behaviors is achieved. This method first identifies network attack characteristics, and then sequentially verifies the legality of interface parameters, the validity of access addresses, the authenticity of digital signatures, the timeliness of requests, and business relevance. Finally, access frequency control is implemented to form a tight defense system. This layered verification design can accurately identify various abnormal requests and at the same time provide detailed feedback on the reasons for violations, ensuring both the smooth passage of legitimate business requests and effectively blocking abnormal number occupancy behaviors initiated through the interface, improving the security and fairness of number resource management.

[0196] In a possible design, S203, sending the request error message to the request side and the management side, includes:

[0197] S2032, sending the request error message to the request side.

[0198] Specifically, the system can directly return the generated request error message to the request side through the network communication protocol. The purpose of this process is to timely notify the request side of the specific error reason when the request verification fails, enabling it to make corresponding adjustments or corrections, thereby improving the success rate of requests and the overall efficiency of the system.

[0199] S2032, generating an alarm message according to the query request and the request error message.

[0200] Specifically, the system can collect the detailed information of the query request and the corresponding request error message, and integrate them into an alarm message. This process may involve extracting key data such as the request timestamp, request source, specific error type and description, etc., and formatting this information into an easily understandable alarm message. The generated alarm message can be sent to the management side through the log record system or the real-time monitoring system. The purpose of this process is to timely notify the management personnel when detecting abnormalities or potential security threats, enabling them to quickly respond and handle problems.

[0201] S2033, sending the alarm message to the management side.

[0202] Specifically, the system can pass the generated alarm information to the management end through preset communication channels, such as message queues, emails, instant messaging services or dedicated monitoring interfaces. The purpose of this process is to quickly notify managers when the system detects abnormal activities or potential threats so that they can take timely measures to investigate and respond, thereby maintaining the normal operation of the system.

[0203] The technical effect of the scheme in this embodiment is that while returning error information to the requesting end, the method automatically generates an alarm message containing detailed diagnostic data and pushes it to the management end, so that the operation and maintenance personnel can quickly locate the source and type of the attack. This real-time two-way notification mechanism not only ensures that users can know the operation results in a timely manner, but also provides the system administrator with a basis for handling exceptions, improves the response speed and processing efficiency of security incidents, and forms a complete protection chain from abnormal detection to handling feedback.

[0204] Figure 3 Schematic diagram of the process of the method for preventing abnormal number resource brushing provided in the embodiment of the present application Figure 2 In this embodiment, Figure 2 Based on the provided embodiment, the method for preventing abnormal number resource swiping is further explained. The method for preventing abnormal number resource swiping includes:

[0205] S301: Receive a query request sent by a requesting end.

[0206] S302. Substitute the query request into a preset verification model to obtain a request verification result and a request error message; wherein the request verification result includes a request verification success and a request verification failure, and the request error message is used to indicate the reason for the request verification failure.

[0207] S303: When the request verification result is that the request verification fails, a request error message is sent to the request end and the management end.

[0208] S304. When the request verification result is successful, send a query request to the number card resource end, so that the number card resource end queries the number according to the query request and sends the number to the request end.

[0209] S301 - S304 are similar to S201 - S204 and will not be described in detail in this embodiment.

[0210] S305. Obtain the first query request volume and order generation volume in a past preset first time period, and the second query request volume in a past preset second time period; wherein the end time of the first time period is earlier than the start time of the second time period.

[0211] Specifically, the system can obtain the required data by accessing log records and database queries. Each time the system receives a query request or generates an order, it will record relevant information in the database, including data such as timestamps, request types, and order generation. Then, through the database query function, the system can calculate the number of query requests and the number of order generations within a specified time period. The purpose of this process is to monitor and analyze the system's usage, identify abnormal query or order generation patterns, so that when potential abnormal activities or resource abuse are detected, warning messages can be generated in a timely manner and notified to the management end, thereby improving the system's security and resource management efficiency.

[0212] S306. When the difference between the first query request volume and the second query request volume is greater than a preset difference threshold, generate a query volume warning message and send the query volume warning message to the management end.

[0213] Specifically, the system will regularly or in real-time calculate the query request volumes in two different time periods and compare their differences. If the difference exceeds the preset threshold, the system will generate a query volume warning message indicating that there may be abnormal query activities. This warning message can be sent to the management end through message queues, emails, or other communication means so that managers can timely understand and handle potential abnormal situations. The purpose of this process is to monitor the system's query activities, identify possible abuse or attack behaviors, and thus maintain the normal operation of the system and the reasonable use of resources.

[0214] S307. When the ratio of the first query request volume to the order generation volume is less than a preset ratio threshold, generate an order volume warning message and send the order volume warning message to the management end.

[0215] Specifically, the system can calculate the ratio of the query request volume to the order generation volume within a preset first time period. If this ratio is lower than the set threshold, the system will generate an order volume warning message indicating that there may be an abnormal situation where there are too many queries but insufficient order generation. This warning message can be sent to the management end through emails, instant messages, or other communication means so that managers can timely investigate and handle possible business anomalies or system problems. The purpose of this process is to monitor the system's business efficiency, ensure a reasonable ratio between query requests and order generation, and thus optimize resource utilization.

[0216] In this embodiment, the technical effect of this solution is as follows: By dynamically monitoring the correlation between the query request volume and the order generation volume, intelligent early warning of abnormal number selection behavior is achieved. By comparing the query volume fluctuations and the query order conversion rate in different time periods, this method can effectively identify abnormal behavior patterns such as abnormal number occupancy and false order brushing, and send early warning signals to the management end in a timely manner. This risk control mechanism based on business data correlation analysis can not only detect hidden attacks that are difficult to identify by traditional interception means, but also provide data support for the operator to optimize the allocation of number resources, improving the refined level of number resource management and the security protection ability.

[0217] The embodiment of this application also provides a system for preventing abnormal brushing of number resources, which includes: an anti-brushing verification end, a request end, a number card resource end, and a management end.

[0218] In response to the user input, the request end generates a query request according to the user input and sends the query request to the anti-brushing verification end.

[0219] The anti-brushing verification end verifies the query request according to a preset verification model; when the verification result is verification failure, the anti-brushing verification end sends an error message to the request end and the management end; when the verification result is verification success, the anti-brushing verification end sends the query request to the number card resource end.

[0220] The number card resource end queries numbers according to the query request and sends the numbers to the request end.

[0221] The management end analyzes the error message to quickly locate the reason for the request failure, enabling the management personnel to take appropriate measures, such as adjusting security policies and optimizing business rules, etc.

[0222] Figure 4 It is a schematic structural diagram of the device for preventing abnormal brushing of number resources provided by the embodiment of this application. As Figure 4 shown, the device for preventing abnormal brushing of number resources includes:

[0223] A receiving module 401, configured to receive the query request sent by the request end.

[0224] An input module 402, configured to substitute the query request into a preset verification model to obtain a request verification result and a request error message; wherein, the request verification result includes request verification success and request verification failure, and the request error message is used to indicate the reason for the request verification failure.

[0225] A first sending module 403, configured to send the request error message to the request end and the management end when the request verification result is request verification failure.

[0226] The second sending module 404 is used to send a query request to the number card resource end when the request verification result is that the request verification is successful, so that the number card resource end queries the number according to the query request and sends the number to the request end.

[0227] In a possible design, the query request includes a first request and a second request, the preset verification model includes a hypertext transfer protocol request verification model and an interface request verification model, and the input module 402 includes:

[0228] The first input unit is used to substitute the first request into the hypertext transfer protocol request verification model to obtain a first verification result and a first error message; wherein the first request refers to a hypertext transfer protocol request, and the first verification result includes a successful protocol request verification and a failed protocol request verification.

[0229] The second input unit is used to substitute the second request into the interface request verification model to obtain a second verification result and a second error message; wherein the second request refers to an interface request, and the second verification result includes a successful interface request verification and a failed interface request verification.

[0230] In a possible design, the first request includes multiple protocol request parameters, a request token, a protocol request address, and a protocol request access count, and the first input unit includes:

[0231] The first matching component is used to match the first request with a preset attack pattern database to obtain a first matching result and a third error message; wherein the first matching result includes a first matching success and a first matching failure, and the third error message is used to indicate that the first request is an abnormal network attack request.

[0232] The first confirmation component is used to determine the protocol request verification failure as the first verification result and the third error information as the first error information when the first matching result is a first matching success.

[0233] A protocol request parameter verification component is used to verify multiple protocol request parameters according to preset parameter verification rules when the first matching result is a first matching failure, and obtain a protocol parameter verification result and a fourth error message; wherein the protocol parameter verification result includes a successful protocol parameter verification and a failed protocol parameter verification, and the fourth error message is used to indicate that multiple protocol request parameters are in violation.

[0234] The second confirmation component is used to determine the protocol request verification failure as the first verification result and the fourth error information as the first error information when the protocol parameter verification result is a protocol parameter verification failure.

[0235] A request token verification component, which is used to verify the request token according to a preset token verification rule when the protocol parameter verification result is successful in protocol parameter verification, so as to obtain a token verification result and a fifth error message; wherein, the token verification result includes successful token verification and failed token verification, and the fifth error message is used to indicate that the request token is illegal.

[0236] A third confirmation component, which is used to determine that the protocol request verification fails as the first verification result and determine the fifth error message as the first error message when the token verification result is failed token verification.

[0237] A protocol request address verification component, which is used to verify the protocol request address according to a preset address verification rule when the token verification result is successful token verification, so as to obtain a protocol address verification result and a sixth error message; wherein, the protocol address verification result includes successful protocol address verification and failed protocol address verification, and the sixth error message is used to indicate that the protocol request address is illegal.

[0238] A fourth confirmation component, which is used to determine that the protocol request verification fails as the first verification result and determine the sixth error message as the first error message when the protocol address verification result is failed protocol address verification.

[0239] A protocol request access times verification component, which is used to determine that the protocol request verification is successful as the first verification result and set the first error message to be empty when the protocol address verification result is successful protocol address verification and the protocol request access times does not exceed a preset protocol request access times threshold.

[0240] In a possible design, the second request includes multiple interface request parameters, interface permissions, interface request addresses, interface signatures, request timestamps, multiple service information, and interface request access times. The second input unit includes:

[0241] A second matching component, which is used to match the second request with a preset attack pattern database to obtain a second matching result and a seventh error message; wherein, the second matching result includes second matching success and second matching failure, and the seventh error message is used to indicate that the second request is an abnormal network attack request.

[0242] A fifth confirmation component, which is used to determine that the interface request verification fails as the second verification result and determine the seventh error message as the second error message when the second matching result is second matching success.

[0243] The interface request parameter verification component is used to verify multiple interface request parameters according to the preset parameter verification rules when the second matching result is a second matching failure, and obtain the interface parameter verification result and the eighth error message; wherein, the interface parameter verification result includes successful interface parameter verification and failed interface parameter verification, and the eighth error message is used to indicate that multiple interface request parameters are illegal.

[0244] The sixth confirmation component is used to determine the interface request verification failure as the second verification result and the eighth error message as the second error message when the interface parameter verification result is a failed interface parameter verification.

[0245] The interface permission verification component is used to verify the interface permission according to the preset permission verification rules when the interface parameter verification result is a successful interface parameter verification, and obtain the permission verification result and the ninth error message; wherein, the permission verification result includes successful permission verification and failed permission verification, and the ninth error message is used to indicate that the interface permission is illegal.

[0246] The seventh confirmation component is used to determine the interface request verification failure as the second verification result and the ninth error message as the second error message when the permission verification result is a failed permission verification.

[0247] The interface request address verification component is used to verify the interface request address according to the preset address verification rules when the permission verification result is a successful permission verification, and obtain the interface address verification result and the tenth error message; wherein, the interface address verification result includes successful interface address verification and failed interface address verification, and the tenth error message is used to indicate that the interface request address is illegal.

[0248] The eighth confirmation component is used to determine the interface request verification failure as the second verification result and the tenth error message as the second error message when the interface address verification result is a failed interface address verification.

[0249] The interface signature verification component is used to verify the interface signature according to the preset signature verification rules when the interface address verification result is a successful interface address verification, and obtain the signature verification result and the eleventh error message; wherein, the signature verification result includes successful signature verification and failed signature verification, and the eleventh error message is used to indicate that the interface signature is illegal.

[0250] The ninth confirmation component is used to determine the interface request verification failure as the second verification result and the eleventh error message as the second error message when the signature verification result is a failed signature verification.

[0251] A request timestamp verification component is used to verify the request timestamp according to a preset timestamp verification rule when the signature verification result is successful in signature verification, obtaining a timestamp verification result and a twelfth error message; wherein, the timestamp verification result includes successful timestamp verification and failed timestamp verification, and the twelfth error message is used to indicate that the request timestamp is illegal.

[0252] A tenth confirmation component is used to determine that the interface request verification fails as the second verification result and determine the twelfth error message as the second error message when the timestamp verification result is failed timestamp verification.

[0253] A business information verification component is used to verify multiple business information according to a preset business verification rule when the timestamp verification result is successful timestamp verification, obtaining a business verification result and a thirteenth error message; wherein, the business verification result includes successful business verification and failed business verification, and the thirteenth error message is used to indicate that the multiple business information is illegal.

[0254] An eleventh confirmation component is used to determine that the interface request verification fails as the second verification result and determine the thirteenth error message as the second error message when the business verification result is failed business verification.

[0255] A request access times verification component is used to determine that the interface request verification is successful as the second verification result and set the second error message to be empty when the business verification result is successful business verification and the interface request access times does not exceed a preset interface request access times threshold.

[0256] In a possible design, the first sending module 403 includes:

[0257] A request error message sending component is used to send a request error message to the request side.

[0258] An alarm information generating component is used to generate alarm information according to a query request and a request error message.

[0259] An alarm information sending component is used to send alarm information to the management side.

[0260] In a possible design, the number resource abnormal anti-brush device further includes:

[0261] An obtaining module is used to obtain a first query request volume and an order generation volume within a preset first time period in the past, and a second query request volume within a preset second time period in the past; wherein, the end time of the first time period is earlier than the start time of the second time period.

[0262] A query volume warning information generation module, which is used to generate query volume warning information and send the query volume warning information to the management end when the difference between the first query request volume and the second query request volume is greater than a preset difference threshold.

[0263] An order volume warning information generation module, which is used to generate order volume warning information and send the order volume warning information to the management end when the ratio of the first query request volume to the order generation volume is less than a preset ratio threshold.

[0264] The abnormal anti-brush device for number resources provided in this embodiment can execute Figure 2 the technical solution of an embodiment of a method for preventing abnormal brushing of number resources shown in Figure 2 An embodiment of a method for preventing abnormal brushing of number resources shown is similar, and will not be elaborated here one by one.

[0265] Figure 5 This is a schematic diagram of the hardware structure of the electronic device provided in the embodiment of the present application. As Figure 5 shown, the electronic device includes: at least one processor 510 and a memory 520. The electronic device also includes a communication component 530. Among them, the processor 510, the memory 520, and the communication component 530 are connected through a bus 540.

[0266] In a specific implementation process, at least one processor 510 executes the computer execution instructions stored in the memory 520, so that at least one processor 510 is used to implement a method for preventing abnormal brushing of number resources in the above embodiment.

[0267] The specific implementation process of the processor 510 can refer to the above method embodiment, and its implementation principle and technical effect are similar, which will not be elaborated here in this embodiment.

[0268] In the above embodiment, it should be understood that the processor 510 may be a central processing unit (CPU), and may also be other general-purpose processors, digital signal processors (DSPs), application specific integrated circuits (ASICs), etc. The general-purpose processor may be a microprocessor or the processor may also be any conventional processor, etc. The steps of the method disclosed in combination with the invention can be directly embodied as being executed and completed by a hardware processor, or can be executed and completed by a combination of hardware and software modules in the processor.

[0269] The memory 520 may include a high-speed RAM memory, and may also include a non-volatile storage NVM, such as at least one disk memory.

[0270] The bus 540 can be an Industry Standard Architecture (ISA) bus, a Peripheral Component Interconnect (PCI) bus, an Extended Industry Standard Architecture (EISA) bus, or the like. The bus 540 can be divided into an address bus, a data bus, a control bus, etc. For the sake of convenience in representation, the bus 540 in the accompanying drawings of this application is not limited to only one bus or one type of bus.

[0271] The functions implemented for the electronic device and the master control device are introduced for the solution provided by the embodiments of the present invention. It can be understood that in order for the electronic device or the master control device to implement the above functions, it includes the corresponding hardware structures and / or software modules for executing each function. Combining the units and algorithm steps of each example described in the embodiments disclosed in the embodiments of the present invention, the embodiments of the present invention can be implemented in the form of hardware or a combination of hardware and computer software. Whether a certain function is executed in the manner of hardware or computer software driving hardware depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered to exceed the scope of the technical solution of the embodiments of the present invention.

[0272] The embodiments of the present application further provide a computer-readable storage medium. Computer-executable instructions are stored in the computer-readable storage medium. When the computer-executable instructions are executed by a processor, they are used to implement a method for preventing abnormal brushing of number resources in the above embodiments. Among them, in the specific implementation of the above method for preventing abnormal brushing of number resources, each module can be implemented as a processor.

[0273] The above-readable storage medium can be implemented by any type of volatile or non-volatile storage device or a combination thereof, such as static random access memory (SRAM), electrically erasable programmable read-only memory (EEPROM), erasable programmable read-only memory (EPROM), programmable read-only memory (PROM), read-only memory (ROM), magnetic memory, flash memory, a magnetic disk, or an optical disc. The readable storage medium can be any available medium that can be accessed by a general-purpose or special-purpose computer.

[0274] An exemplary readable storage medium is coupled to a processor, enabling the processor to read information from the readable storage medium and write information to the readable storage medium. Of course, the readable storage medium can also be a component of the processor. The processor and the readable storage medium can be located in an Application Specific Integrated Circuits (ASIC). Of course, the processor and the readable storage medium can also exist as discrete components in an electronic device or a master device.

[0275] An embodiment of the present application also provides a computer program product, including a computer program, which, when executed by a processor, is used to implement a method for preventing abnormal brushing of number resources in the above embodiment.

[0276] The computer program is stored in a readable storage medium. At least one processor can read the computer program from the readable storage medium, and at least one processor executes the computer program to execute the solution provided in any of the above embodiments.

[0277] Those of ordinary skill in the art can understand that all or part of the steps for implementing the above method embodiments can be completed by hardware related to program instructions. The foregoing program can be stored in a computer-readable storage medium. When the program is executed, it executes the steps including the above method embodiments; and the foregoing storage medium includes: various media such as ROM, RAM, magnetic disks, or optical discs that can store program codes.

[0278] So far, the technical solutions of the present application have been described in conjunction with the preferred embodiments shown in the accompanying drawings. However, it is easy for those skilled in the art to understand that the protection scope of the present application is obviously not limited to these specific embodiments. The above embodiments are only used to illustrate the technical solutions of the present application, rather than to limit them; although the present application has been described in detail with reference to the foregoing embodiments, those of ordinary skill in the art should understand that they can still modify the technical solutions recorded in the foregoing embodiments, or perform equivalent replacements on some or all of the technical features; and these modifications or replacements do not cause the essence of the corresponding technical solutions to deviate from the scope of the technical solutions of the embodiments of the present application.

Claims

1. A method for preventing abnormal brushing of number resources, characterized in that, The anti-swiping verification end applied to the number resource abnormal anti-swiping system, the number resource abnormal anti-swiping system also includes a request end, a number card resource end and a management end, and the method includes: Receiving a query request sent by the requesting end; Substituting the query request into a preset verification model to obtain a request verification result and a request error message; wherein the request verification result includes a request verification success and a request verification failure, and the request error message is used to indicate the reason for the request verification failure; When the request verification result is that the request verification fails, sending the request error information to the request end and the management end; When the request verification result is that the request verification is successful, the query request is sent to the number card resource end, so that the number card resource end queries the number according to the query request and sends the number to the request end.

2. The abnormal anti-brushing method for number resources according to claim 1, wherein The query request includes a first request and a second request, the preset verification model includes a hypertext transfer protocol request verification model and an interface request verification model, and the query request is substituted into the preset verification model to obtain a request verification result and request error information, including: Substituting the first request into the hypertext transfer protocol request verification model to obtain a first verification result and a first error message; wherein the first request refers to a hypertext transfer protocol request, and the first verification result includes a protocol request verification success and a protocol request verification failure; Substitute the second request into the interface request verification model to obtain a second verification result and a second error message; wherein the second request refers to an interface request, and the second verification result includes an interface request verification success and an interface request verification failure.

3. The abnormal anti-brushing method for number resources according to claim 2, wherein The first request includes a plurality of protocol request parameters, a request token, a protocol request address, and a protocol request access count, and the first request is substituted into the hypertext transfer protocol request verification model to obtain a first verification result and a first error message, including: Matching the first request with a preset attack pattern database to obtain a first matching result and a third error message; wherein the first matching result includes a first matching success and a first matching failure, and the third error message is used to indicate that the first request is an abnormal network attack request; When the first matching result is that the first matching is successful, determining the protocol request verification failure as the first verification result, and determining the third error information as the first error information; When the first matching result is that the first matching fails, the multiple protocol request parameters are checked according to a preset parameter verification rule to obtain a protocol parameter verification result and a fourth error message; wherein the protocol parameter verification result includes a protocol parameter verification success and a protocol parameter verification failure, and the fourth error message is used to indicate that the multiple protocol request parameters are in violation of regulations; When the protocol parameter verification result is that the protocol parameter verification fails, determining the protocol request verification failure as the first verification result, and determining the fourth error information as the first error information; When the protocol parameter verification result is that the protocol parameter verification is successful, the request token is verified according to the preset token verification rule to obtain the token verification result and the fifth error message; wherein the token verification result includes the token verification success and the token verification failure, and the fifth error message is used to indicate that the request token is in violation of the rules; When the token verification result is that the token verification fails, determining the protocol request verification failure as the first verification result, and determining the fifth error information as the first error information; When the token verification result is that the token verification is successful, the protocol request address is verified according to the preset address verification rule to obtain the protocol address verification result and the sixth error message; wherein the protocol address verification result includes the protocol address verification success and the protocol address verification failure, and the sixth error message is used to indicate that the protocol request address is in violation of the rules; When the protocol address verification result is that the protocol address verification fails, determining the protocol request verification failure as the first verification result, and determining the sixth error information as the first error information; When the protocol address verification result is that the protocol address verification is successful, and the protocol request access times do not exceed the preset protocol request access times threshold, the protocol request verification success is determined as the first verification result, and the first error information is set to empty.

4. The method for preventing abnormal brushing of number resources according to claim 2, wherein The second request includes multiple interface request parameters, interface permissions, interface request addresses, interface signatures, request timestamps, multiple business information, and interface request access times. Substituting the second request into the interface request verification model to obtain a second verification result and a second error message includes: Matching the second request with a preset attack pattern database to obtain a second matching result and a seventh error message; wherein the second matching result includes a second matching success and a second matching failure, and the seventh error message is used to indicate that the second request is an abnormal network attack request; When the second matching result is that the second matching is successful, determining the interface request verification failure as the second verification result, and determining the seventh error information as the second error information; When the second matching result is that the second matching fails, the multiple interface request parameters are checked according to a preset parameter verification rule to obtain an interface parameter verification result and an eighth error message; wherein the interface parameter verification result includes an interface parameter verification success and an interface parameter verification failure, and the eighth error message is used to indicate that the multiple interface request parameters are in violation of regulations; When the interface parameter verification result is that the interface parameter verification fails, determining the interface request verification failure as the second verification result, and determining the eighth error information as the second error information; When the interface parameter verification result indicates that the interface parameter verification is successful, verify the interface permission according to the preset permission verification rules to obtain a permission verification result and a ninth error message; wherein, the permission verification result includes successful permission verification and failed permission verification, and the ninth error message is used to indicate that the interface permission is violated; When the permission verification result indicates that the permission verification fails, determine that the interface request verification fails as the second verification result, and determine the ninth error message as the second error message; When the permission verification result indicates that the permission verification is successful, verify the interface request address according to the preset address verification rules to obtain an interface address verification result and a tenth error message; wherein, the interface address verification result includes successful interface address verification and failed interface address verification, and the tenth error message is used to indicate that the interface request address is violated; When the interface address verification result indicates that the interface address verification fails, determine that the interface request verification fails as the second verification result, and determine the tenth error message as the second error message; When the interface address verification result indicates that the interface address verification is successful, verify the interface signature according to the preset signature verification rules to obtain a signature verification result and an eleventh error message; wherein, the signature verification result includes successful signature verification and failed signature verification, and the eleventh error message is used to indicate that the interface signature is violated; When the signature verification result indicates that the signature verification fails, determine that the interface request verification fails as the second verification result, and determine the eleventh error message as the second error message; When the signature verification result indicates that the signature verification is successful, verify the request timestamp according to the preset timestamp verification rules to obtain a timestamp verification result and a twelfth error message; wherein, the timestamp verification result includes successful timestamp verification and failed timestamp verification, and the twelfth error message is used to indicate that the request timestamp is violated; When the timestamp verification result indicates that the timestamp verification fails, determine that the interface request verification fails as the second verification result, and determine the twelfth error message as the second error message; When the timestamp verification result indicates that the timestamp verification is successful, verify the multiple service information according to the preset service verification rules to obtain a service verification result and a thirteenth error message; wherein, the service verification result includes successful service verification and failed service verification, and the thirteenth error message is used to indicate that the multiple service information is violated; When the service verification result indicates that the service verification fails, determine that the interface request verification fails as the second verification result, and determine the thirteenth error message as the second error message; When the service verification result indicates that the service verification is successful and the number of interface request accesses does not exceed the preset interface request access times threshold, determine that the interface request verification is successful as the second verification result, and set the second error message to be empty.

5. The abnormal anti-brushing method for number resources according to claim 1, wherein Sending the request error message to the request end and the management end includes: Sending the request error message to the request end; Generating an alarm message according to the query request and the request error message; Sending the alarm message to the management end.

6. The abnormal anti-brushing method for number resources according to claim 1, wherein After sending the query request to the SIM card resource end, it further includes: Obtaining the first query request volume and order generation volume within a preset first time period in the past, and the second query request volume within a preset second time period in the past; wherein, the end time of the first time period is earlier than the start time of the second time period; When the difference between the first query request volume and the second query request volume is greater than a preset difference threshold, generating a query volume warning message and sending the query volume warning message to the management end; When the ratio of the first query request volume to the order generation volume is less than a preset ratio threshold, generating an order volume warning message and sending the order volume warning message to the management end.

7. An anti-brushing device for abnormal number resources, characterized in that, Applied to the anti - brushing verification end of the SIM card resource abnormal anti - brushing system, the SIM card resource abnormal anti - brushing system further includes a request end, a SIM card resource end and a management end, and the device includes: A receiving module, configured to receive the query request sent by the request end; An input module, configured to substitute the query request into a preset verification model to obtain a request verification result and a request error message; wherein, the request verification result includes request verification success and request verification failure, and the request error message is used to indicate the reason for the request verification failure; A first sending module, configured to send the request error message to the request end and the management end when the request verification result is request verification failure; A second sending module, configured to send the query request to the SIM card resource end when the request verification result is request verification success, so that the SIM card resource end queries the phone number according to the query request and sends the phone number to the request end.

8. An electronic device, characterized in that, It includes: A processor, and a memory communicatively connected to the processor; The memory stores computer - executable instructions; When the processor executes the computer - executable instructions stored in the memory, it is used to implement the SIM card resource abnormal anti - brushing method according to any one of claims 1 to 6.

9. A computer-readable storage medium, characterized in that, The computer - readable storage medium stores computer - executable instructions, and when the computer - executable instructions are executed by a processor, it is used to implement the SIM card resource abnormal anti - brushing method according to any one of claims 1 to 6.

10. A computer program product, including a computer program, and when the computer program is executed by a processor, it is used to implement the SIM card resource abnormal anti - brushing method according to any one of claims 1 to 6.

Images