Business request processing method and device, electronic equipment and readable storage medium

Abstract

The application provides a service request processing method and device, electronic equipment and a readable storage medium, which are applied to a server. The method comprises the following steps: in response to a target service request sent by a client, obtaining service request information of the target service request; obtaining, according to a service identifier in the service request information, a request number of service requests for accessing the target service sent based on a source Internet Protocol address within a preset time period; then, according to the request number and a preset request number threshold value, and a data packet size and a preset data packet size threshold value, judging whether the target service request is an abnormal request; and according to a judgment result, determining an access right of the client to the target service. The method of the embodiment can prevent data leakage and improve the security of service access.

Description

Technical Field

[0001] This application belongs to the field of computer technology, and specifically relates to a business request processing method, apparatus, electronic device, and readable storage medium. Background Technology

[0002] Users can send business requests to server devices such as servers through the client. The server performs business access according to the business request, obtains the business access result, and returns the business access result to the client.

[0003] In related technologies, when the server receives a business request, it directly performs business access based on the business request and returns the obtained business access result to the client.

[0004] According to relevant technical methods, the server may still execute when it receives abnormal business requests and return access results based on the business requests, which may lead to unauthorized users obtaining access results and causing data leakage. Summary of the Invention

[0005] This application aims to provide a business request processing method, apparatus, electronic device, and readable storage medium, which at least solves the problem that prior art business request processing methods are prone to data leakage.

[0006] In a first aspect, embodiments of this application disclose a business request processing method applied to a server, the method comprising:

[0007] In response to a target service request sent by a client, the service request information of the target service request is obtained; the service request information includes: the target service identifier of the target service accessed by the target service request, the source Internet Protocol address when the client sent the target service request, and the data packet size corresponding to the target service request;

[0008] Based on the service identifier, obtain the number of service requests sent within a preset time period to access the target service based on the source Internet Protocol address;

[0009] Based on the number of requests and the preset request number threshold, as well as the data packet size and the preset data packet size threshold, a judgment result is obtained as to whether the target business request is an abnormal request;

[0010] Based on the judgment result, the client's access permissions to the target service are determined.

[0011] Secondly, embodiments of this application disclose a business request processing apparatus, applied to a server, the apparatus comprising:

[0012] The first acquisition module is used to acquire service request information in response to a service request sent by the client; the service request information includes: the target service identifier of the target service accessed by the service request, the source Internet Protocol address when the client sent the service request, and the data packet size corresponding to the service request;

[0013] The second acquisition module is used to acquire, based on the service identifier, the number of times a service request for accessing the target service is sent within a preset time period based on the source Internet Protocol address;

[0014] The third acquisition module is used to determine whether the business request is an abnormal request based on the number of requests and a preset request number threshold, as well as the data packet size and a preset data packet size threshold.

[0015] The first determining module is used to determine the client's access permissions to the target service based on the determination result.

[0016] Thirdly, embodiments of this application also disclose an electronic device, including a processor and a memory, wherein the memory stores a program or instructions that can run on the processor, and the program or instructions, when executed by the processor, implement the steps of the method described in the first aspect.

[0017] Fourthly, embodiments of this application also disclose a readable storage medium storing a program or instructions that, when executed by a processor, implement the steps of the method described in the first aspect.

[0018] In summary, when acquiring a target service request, based on the service identifier of the target service to be accessed by the client, the number of service requests sent within a preset time period using the source Internet Protocol address to access the target service is obtained. Based on the number of requests and a preset request count threshold, as well as the data packet size and a preset data packet size threshold, it is possible to accurately determine whether the target service request is an abnormal request. Based on the determination result, the client's access permissions to the target service are determined. This method, based on this embodiment, avoids abnormal target service requests with abnormal request counts or abnormal data packet sizes from accessing the target service, prevents the server from executing abnormal target service requests, and avoids the problem of data leakage to unauthorized clients performing abnormal service access. This embodiment improves the security of service request processing. Attached Figure Description

[0019] In the attached diagram:

[0020] Figure 1 This is a flowchart illustrating the steps of a business request processing method provided in an embodiment of this application;

[0021] Figure 2 This is a flowchart of another business request processing method provided in an embodiment of this application;

[0022] Figure 3 This is a flowchart of another business request processing method provided in the embodiments of this application;

[0023] Figure 4 This is a block diagram of a service request processing device provided in an embodiment of this application;

[0024] Figure 5 This is a block diagram of an electronic device provided in one embodiment of this application;

[0025] Figure 6 This is a block diagram of an electronic device according to another embodiment of the present application. Detailed Implementation

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

[0027] The terms "first," "second," etc., used in the specification and claims of this application are used to distinguish similar objects and not to describe a specific order or sequence. It should be understood that such use of data can be interchanged where appropriate so that embodiments of this application can be implemented in orders other than those illustrated or described herein, and the objects distinguished by "first," "second," etc., are generally of the same class and the number of objects is not limited; for example, a first object can be one or more. Furthermore, in the specification and claims, "and / or" indicates at least one of the connected objects, and the character " / " generally indicates that the preceding and following objects are in an "or" relationship.

[0028] Figure 1 This embodiment provides a business request processing method applied to the server side. (See also...) Figure 1 The method may include the following steps:

[0029] Step 101: In response to the target business request sent by the client, obtain the business request information of the target business request.

[0030] The service request information includes: the target service identifier of the target service accessed by the target service request, the source Internet Protocol address, and the size of the data packet corresponding to the target service request.

[0031] A service request is used to access a target service. The target service identifier can be the name, number, or other identifier of the target service. The target service can be a service that transmits and stores data from the client to the server, a service that retrieves data from the server, or other services. There is no limitation on the type of target service here.

[0032] For example, by parsing the target service request, the service request information within the target service request is obtained. The source Internet Protocol (IP) address is the IP address used by the client when sending the target service request. The data packet corresponding to the target service request can be a data packet carrying the service request information, a data packet that needs to be transmitted to the server for storage, or a data packet including the return result corresponding to the target service.

[0033] The client can be a terminal device, and the server can be an electronic device such as a server. For example, the server assigns a unique business ID (business identity document, business ID) to each preset business function, where the target business is one of the preset businesses and also has its own business identifier.

[0034] The server can also assign a unique user ID (UserId) to each user account. For example, based on the business ID and user ID, when the client sends a target business request to the server, the server can identify and track the executed target business through the business ID and user ID during the execution of the corresponding target business according to the target business request, so as to prevent information from being maliciously tampered with or obtained in the business process.

[0035] Step 102: Based on the service identifier, obtain the number of service requests sent within a preset time period to access the target service, based on the source Internet Protocol address.

[0036] For example, the server stores the service identifiers of the services accessed by various service requests sent from the source IP address within a preset time period.

[0037] Upon receiving a target service request from a client, the server retrieves the number of service identifiers that match the target service identifier from the service identifiers stored on the server within a preset time period. The number of service identifiers that match the target service identifier is determined as the number of requests sent within the preset time period to access the target service based on the source Internet Protocol address.

[0038] Step 103: Based on the number of requests and the preset request number threshold, as well as the data packet size and the preset data packet size threshold, obtain the judgment result of whether the target business request is an abnormal request.

[0039] Specifically, the judgment results include: whether the target business request is a normal request or an abnormal request.

[0040] The preset request count threshold and preset data packet size threshold can be set according to user needs. For example, if data security requirements are high, the preset data packet size can be set smaller; conversely, if data security requirements are low, the preset data packet size can be set larger.

[0041] For example, if the number of requests is greater than or equal to the request count threshold, or the data packet size is greater than or equal to the preset data packet size threshold, the target business request is determined to be an abnormal request; if the number of requests is less than the request count threshold, or the data packet size is less than the preset data packet size threshold, the target business request is determined to be a normal request.

[0042] Furthermore, the sending time of the client's business request can be obtained, and based on the number of requests and the preset request number threshold, the data packet size and the preset data packet size threshold, as well as the sending time and the preset time period, it can be determined whether the target business request is an abnormal request.

[0043] Specifically, if the number of requests is greater than or equal to the request count threshold, or the data packet size is greater than or equal to the preset data packet size threshold, or the sending time is outside the preset time period, the target service request is determined to be an abnormal request. If the number of requests is less than the request count threshold, the data packet size is less than the preset data packet size threshold, and the sending time is within the preset time period, the target service request is determined to be either an abnormal request or a normal request.

[0044] Step 104: Based on the judgment result, determine the client's access permissions to the target service.

[0045] The judgment result includes: the target business request is a normal request, or the target business request is an abnormal request. If the judgment result is that the target business request is a normal request, it is determined that the client has access rights to the target business; if the judgment result is that the target business request is an abnormal request, it is determined that the client does not have access rights to the target business.

[0046] In one embodiment, the business request information also includes the client's authentication information, such as the username and password information of the logged-in client used to send the target business request. The server authenticates the client based on the client's authentication information and obtains the authentication result.

[0047] Furthermore, in response to the target service request sent by the client, the server obtains the authentication information from the service request information, as well as the target service identifier, source IP address, and data packet size corresponding to the target service request. Based on the authentication information, the server obtains the authentication result. Based on the target service identifier, source IP address, and data packet size, the server determines whether the target service request is an abnormal request. Based on the authentication result and the abnormal request determination, the server determines the client's access permissions to the target service.

[0048] For example, if the authentication result is successful and the target business request is determined to be a normal request, the client is determined to have access to the target business; if the authentication result is unsuccessful or the target business request is determined to be an abnormal request, the client is determined to not have access to the target business.

[0049] By combining the identity authentication result and the judgment result of whether the target business request is an abnormal request, the target business request is double-judged. This can prevent the illegal user from stealing the account password information of the legitimate user, logging into the client with the account password information, and sending the target business request from the client, which would cause the server to directly execute the target business request and thus leak the target business data, thereby improving the security of business access.

[0050] For example, if the number of requests is greater than or equal to a preset request count threshold, and / or the data packet size is greater than or equal to a preset data packet size threshold, then the target service request is determined to be an abnormal request, and the client is determined to have access permission to access the target service. If the number of requests is less than the preset request count threshold, and the data packet size is less than the preset data packet size threshold, then the target service request is determined to be a normal request, and the client is determined not to have access permission to access the target service. Based on this embodiment, it is possible to prevent legitimate users from sending abnormal requests through the client, and access to the target service based on abnormal requests can avoid the leakage of target service data, thereby improving the security of service access.

[0051] For example, the server stores data accessible only to registered, authorized users. This data could include product development data, copyrighted books and periodicals, etc. If an unauthorized user obtains the identity information of an authorized user and frequently sends targeted business requests to the server to retrieve this data, the server can determine the client's access permissions based on the number of requests made within a preset time period and the size of the data packet requested. If the number of requests is too high or the data packet size is too large, the client will not be granted permission to retrieve the data, thus preventing data leakage and improving the security of business access in this application scenario.

[0052] In this embodiment, when acquiring a target service request, the number of service requests sent within a preset time period based on the service identifier of the target service to be accessed in the client's target service request is obtained. Based on the number of requests and a preset request count threshold, as well as the data packet size and a preset data packet size threshold, it can be accurately determined whether the target service request is an abnormal request. Based on the determination result, the client's access rights to the target service are determined. This method avoids abnormal target service requests with abnormal request counts or abnormal data packet sizes from accessing the target service, prevents the server from executing abnormal target service requests, and avoids the problem of data leakage to unauthorized clients performing abnormal service access. This embodiment improves the security of service request processing.

[0053] In one embodiment, refer to Figure 2 The method may include the following steps:

[0054] Step 201: In response to the target service request sent by the client, obtain the service request information of the target service request.

[0055] The service request information includes: the target service identifier of the target service accessed by the target service request, the source Internet Protocol address, and the size of the data packet corresponding to the target service request.

[0056] Step 202: Based on the service identifier, obtain the number of service requests sent within a preset time period to access the target service using the source Internet Protocol address.

[0057] The method for this step has been explained in step 102 above, and will not be repeated here.

[0058] Step 203: Determine whether the target business request is an abnormal request based on the number of requests and the preset request number threshold, as well as the data packet size and the preset data packet size threshold.

[0059] For example, step 203 may include the following sub-steps:

[0060] Step 2031: If the number of requests is greater than or equal to a preset request number threshold, and / or the data packet size is greater than or equal to a preset data packet size threshold, then the target business request is determined to be an abnormal request.

[0061] If the number of requests is greater than or equal to the preset request threshold, it indicates that the requests from the source IP to access the target service are too frequent, and the target service requests are abnormal requests.

[0062] If the data packet size is greater than or equal to the preset data packet size threshold, it indicates that the data packet corresponding to the target business request is too large, and the target business request is an abnormal request.

[0063] For example, it can also obtain the sending time of the client's target business request and determine whether the sending time is outside the preset time period.

[0064] If the target service request meets any of the following conditions, the target service request is determined to be an abnormal request: the number of requests is greater than or equal to the preset request number threshold, the data packet size is greater than or equal to the preset data packet size threshold, or the sending time is outside the preset time period.

[0065] If a target service request meets all of the following conditions simultaneously, it is determined to be a normal request: the number of requests is less than the preset request number threshold, the data packet size is less than the preset data packet size threshold, and the sending time is within the preset time period.

[0066] The preset time period can be a user-defined time period. For example, if the preset time period is during working hours on weekdays, such as from 9:00 AM to 6:00 PM Monday to Friday, then target business requests sent outside of this time period will be considered abnormal requests.

[0067] Step 2032: If the number of requests is less than the preset request number threshold and the data packet size is less than the preset data packet size threshold, then the target business request is determined to be a normal request.

[0068] If the number of requests is less than a preset request count threshold, and the data packet size is less than a preset data packet size threshold, it indicates that the target service requests originating from the source IP are infrequent, and the data packet size corresponding to the target service request is not abnormal. In this case, the target service request is determined to be a normal request.

[0069] The service request information also includes: the permission level corresponding to the source Internet Protocol address when the client sends the target service request based on the source Internet Protocol address.

[0070] For example, an initial permission level is assigned to the source IP address based on the user's level of trust in it. When a business request is first sent to the server based on the source IP address, the permission level corresponding to the source IP address is the initial permission level. In subsequent business requests sent based on the source IP address, the permission level of the source IP address is gradually adjusted according to the methods in steps 204 to 205 to obtain a new permission level, and the business request is processed according to the new permission level.

[0071] Step 204: Obtain the number of abnormal service requests sent from the source Internet Protocol address within a preset time period.

[0072] For example, each time the server receives a business request sent from the source IP address, it determines whether the business request is an abnormal request. If it is, it records the abnormal request and accumulates the number of abnormal requests.

[0073] The method for determining abnormal business requests can be found in the description of step 2031, and will not be repeated here.

[0074] Step 205: If the number of anomalies is greater than or equal to the first preset threshold for the number of anomalies, then the permission level is reduced to obtain a new permission level.

[0075] If the number of anomalies is greater than or equal to a first preset threshold, it indicates that too many abnormal requests are originating from the source IP address, suggesting low trustworthiness of that source IP address. Its privilege level is then lowered to allow access control confirmation for the target service at the reduced privilege level. This prevents the server from executing requests from untrusted source IP addresses, thus avoiding data leakage.

[0076] Step 206: If the target service request is an abnormal request, and / or the new permission level is lower than the permission level threshold set for the target service, then it is determined that the client does not have the permission to access the target service.

[0077] If the new permission level is lower than the permission level threshold set for the target business, it means that the new permission level does not meet the permission level requirements of the target business. Therefore, it is determined that the client does not have the permission to access the target business, in order to prevent the target business with a lower permission level from requesting the target business with a higher permission level, which could lead to the data leakage of the target business with a higher permission level.

[0078] Step 207: If the target business request is an abnormal request, then determine the user privacy information in the business request information based on preset keywords.

[0079] The keyword is a field used to locate user privacy information. For example, in one embodiment, the WiFi account password when the client connects to the internet is user privacy information, so the field used to locate the WiFi account password in the target service request can be determined as the keyword in this step.

[0080] For example, the client is a client terminal device with an application (APP) installed for controlling home appliances. During the communication process between the client and the home appliances through the APP, the communication data is forwarded through the server. The server receives the business request sent by the client and captures the data in the business request through the instrumentation method.

[0081] In practical applications, due to the limitations of request code, it is difficult to generate separate code for filtering user privacy information for each business request in every application scenario. For example, in some application scenarios, user privacy information is the WiFi username and password when the client connects to the internet, while in others, it is the user's username and password when logging in through the client.

[0082] For example, in a smart home business system, in an application scenario testing the communication status between the client and server, the client sends data packets, and the server receives and tests these packets. In this scenario, the server is unaware whether the data packets sent by the client contain WiFi username and password information. When the client sends a business request, the WiFi username and password data carried will be merged with the data packets and reported to the server without the server's knowledge. However, in this scenario, the WiFi username and password are data that the server does not need to analyze. If the WiFi username and password data is not filtered, the server will store and use it, potentially leading to the leakage of user privacy information. To avoid this problem, data reported during the business process between the client and server can be collected using event tracking technology, and data designated as user privacy information can be filtered.

[0083] Step 208: Filter the user privacy information in the business request information to obtain the filtered business request information.

[0084] For example, the extended Berkeley Packet Filter (eBPF) technology can be used to detect and protect user privacy information. Specifically, eBPF technology can be used at the operating system kernel level to perform real-time detection of the execution process of business requests and communication using the User Datagram Protocol (UDP).

[0085] Based on eBPF technology, real-time detection code can be inserted into the kernel layer to acquire and analyze network packets and system calls. By setting predefined parameters, data packets reported by the device can be sampled. These parameters include keywords used to determine user privacy information. For example, user privacy information can be detected and filtered for each data packet, or received data packets can be sampled according to a set detection ratio. For instance, a sample could be taken every one hundred received packets.

[0086] For example, you can also set keywords or key fields for the information the server needs to store. Based on these keywords, the server can filter out and store target information from business requests. For instance, data packets uploaded by devices can be in JSON format. When analyzing and filtering these packets, regular expressions can be used to match them with keywords or key fields that the server database would normally store to obtain the target information to be stored. Keywords could include things like "name" or "phone".

[0087] For example, keywords can be set based on input parameter anchors to scan the reported text or data packets from the device and capture keywords. For instance, based on the input parameter anchor type, output parameter anchors can be inserted, and the output results after the business access is completed can be obtained. Based on the output results, it can be checked whether the entire business flow involves user privacy information.

[0088] Step 209: Store the filtered business request information and generate an abnormal business request log based on the filtered business request information.

[0089] In modern information systems, protecting user privacy information such as phone numbers and ID card numbers is crucial. For example, in system testing scenarios, how to conduct effective business function testing without disclosing user privacy information is a pressing issue. However, system testing methods using relevant technologies carry the risk of information leakage and tampering when processing user privacy information. In this embodiment, eBPF technology can be used for system testing to filter out user privacy information, thereby ensuring effective protection of user privacy during testing and preventing information leakage and tampering.

[0090] In one embodiment, by inserting anchor points into various business function calls and combining them with eBPF technology, real-time detection and protection of user privacy information can be achieved, ensuring that no user privacy information is leaked throughout the entire business implementation process. Simultaneously, an ID identifier can be set for each business call, and a UID identifier can be set for each user, preventing malicious tampering or acquisition of user privacy information during business access. This improves information security during system testing and other business access processes, ensuring the security of user privacy information and resolving the issue of protecting user privacy information during system testing.

[0091] Furthermore, during system testing, anchor points are set to detect user privacy information such as phone numbers and ID card details. Anchor points are inserted into various business function calls, including input and output parameter anchor points, which are inserted before and after the execution of the business request, respectively. This ensures that no information leakage occurs throughout the entire business request execution process. eBPF technology is used for real-time detection to protect business information during UDP communication, ensuring that the entire business information is not intercepted or tampered with during transmission.

[0092] The input parameter anchor is used to obtain the input parameters of the business request, while the output parameter anchor is used to obtain the output results after the business execution. By setting anchors, user privacy information can be detected and protected at key points in the execution of the business request. The inserted anchors can be custom fields to be tested, such as the user's name, mobile phone number, ID card number, and other sensitive user information, to prevent the leakage of sensitive user information.

[0093] For example, sensitive user information can be detected and protected in real time by combining business logic or code with eBPF technology. Specifically, eBPF technology can be used to monitor the execution of business functions and UDP communication in real time at the operating system kernel level. eBPF technology can insert detection code at the kernel level to acquire and analyze network packets and system calls, ensuring that user privacy information is not intercepted or tampered with during transmission.

[0094] For example, you can insert output parameter anchors based on the input parameter anchor type, obtain the output results after the business execution is completed, and check whether the entire business flow involves user privacy information based on the output results.

[0095] Furthermore, before executing a business request, input parameters can be obtained and security checks performed using an eBPF program; after executing the business request, the output results can be obtained and security checks performed using an eBPF program. During UDP communication, network packets can be inspected in real time using an eBPF program to ensure packet integrity and confidentiality.

[0096] Furthermore, business processes can be monitored in real time, and if malicious attacks occur, timely reports and alerts can be issued to effectively ensure user information security.

[0097] Step 210: If the determination result is that the target business request is a normal request, and the new permission level is higher than or equal to the permission level threshold set for the target business, then it is determined that the client has the permission to access the target business.

[0098] If the target business request is a normal request and the new permission level is higher than or equal to the permission level threshold set for the target business, it means that the permission level of the target business request is high enough and the target business request is a normal request. This confirms that the client has the right to access the target business, which ensures that access to the target business is secure. It can prevent abnormal or low-permission business requests from accessing high-permission target businesses, prevent data leakage of the target business, and improve the data security of the target business.

[0099] Step 211: Access the target service according to the business request and obtain the access result of the target service.

[0100] For example, if the target business to be accessed in a business request is the test business of the client system, then the system test information in the business request is obtained, the client system is tested based on the system test information, and the test results are returned to the client as the business access result.

[0101] Step 212: Obtain the target data transmission speed for transmitting access results to the client.

[0102] For example, the target data transmission speed can be a fixed value set for the source IP address used when the client sends a business request, or it can be obtained by adjusting the set data transmission speed based on historical abnormal data of business requests sent from the source IP.

[0103] For example, step 212 may include the following sub-steps:

[0104] Sub-step 2121: Obtain the initial data transmission speed configured for the source Internet Protocol address when a service request is received from the client.

[0105] The initial data transfer rate can be set based on the trustworthiness of the source IP address and the initial permission level. For example, the higher the trustworthiness and the higher the initial permission level, the higher the initial data transfer rate can be set, and vice versa.

[0106] Sub-step 2122: If the number of abnormal service requests sent from the source Internet Protocol address within a preset time period is greater than or equal to the second preset abnormal number threshold, then reduce the initial data transmission speed to obtain the target data transmission speed.

[0107] If the number of anomalies is greater than or equal to the second preset anomaly threshold, it indicates that too many abnormal requests were sent from the source IP address, suggesting low credibility of the source IP address. In this case, the initial data transmission rate is reduced to achieve the target data transmission rate.

[0108] For example, after substep 2122, it also includes:

[0109] Sub-step 2123: Use the target data transmission speed to update the initial data transmission speed so that when a new service request is received from the client, a new target data transmission speed can be obtained based on the updated initial data transmission speed.

[0110] Specifically, the target data transmission speed is used to replace the initial data transmission speed. The target data transmission speed is determined to be the initial data transmission speed when a new business request is received from the client. Based on the updated initial data transmission speed, the new target data transmission speed is obtained by referring to the methods in sub-steps 2121 to 2122.

[0111] Step 213: Based on the target data transmission speed, transmit the access results to the client.

[0112] In this embodiment, if the number of abnormal requests originating from the source IP address is greater than or equal to a first preset threshold for the number of abnormal requests, the permission level for the source IP address is reduced. If the target service request is determined to be an abnormal request, or the new permission level is lower than the permission level threshold set for the target service, it is determined that the client does not have access permission to access the target service, in order to prevent abnormal or low-permission target service requests from accessing the target service and causing data leakage of the target service.

[0113] In the event of abnormal requests when identifying target business information, user privacy information can be quickly determined based on keywords. The determined user privacy information is then filtered from the business request information, stored, and logs generated. This approach can both save abnormal target business requests for analysis and recording and prevent user privacy leaks.

[0114] If the target service request is a legitimate request, and the new permission level is higher than or equal to the permission level threshold set for the target service, then the client is deemed to have access permission to access the target service. This ensures the security of the target service. Obtaining the target data transmission speed and transmitting the access result based on that speed satisfies the data transmission requirements between the server and client.

[0115] This embodiment also provides a business request processing method applied to a client, the method including:

[0116] The system sends a target service request to the server, which then uses the service identifier to determine the number of service requests sent within a preset time period based on the source Internet Protocol address. Based on the number of requests and a preset request count threshold, as well as the data packet size and a preset data packet size threshold, the system determines whether the target service request is an abnormal request. Based on the determination result, the system determines the client's access permissions to the target service.

[0117] Among them, the target service identifier of the target service accessed by the target service request, the source Internet Protocol address when the client sends the target service request, and the size of the data packet corresponding to the target service request.

[0118] Based on the method of this embodiment, abnormal target business requests with abnormal request counts or abnormal data packet sizes can be avoided from accessing the target business, preventing the server from executing abnormal target business requests and feeding back the access results to the client. This avoids the problem of data leakage to illegal clients that make abnormal business access. This embodiment improves the security of business request processing.

[0119] Reference Figure 3 The service request processing method in this embodiment may further include the following steps:

[0120] Step S1: The server sets the business identifier and user identifier.

[0121] The server assigns a unique business ID to each business function and a unique user ID to each user. During the execution of business functions, business requests are identified and tracked using the business ID and user ID, preventing information from being maliciously tampered with or obtained during the business process.

[0122] Step S2: At the kernel level, the server obtains the network traffic when the client sends a target business request to the server.

[0123] For example, eBPF technology can be used to acquire network traffic data in real time at the kernel level, including but not limited to key information such as IP address, port number, packet size, and transport protocol. This helps to comprehensively understand the dynamic changes in network traffic and promptly detect potential abnormal traffic.

[0124] Step S3: Analyze the network traffic that sends the target service request.

[0125] For example, machine learning algorithms can be used to analyze the traffic data obtained based on the target business request to identify whether the target business request is an abnormal request.

[0126] For example, abnormal behavior can be distinguished by comparing it with the characteristics of normal traffic.

[0127] For example, rate limiting rules can be formulated to restrict traffic to abnormal target business requests or prevent them from accessing the target business.

[0128] Specifically, rate limiting rules can include: limiting the access frequency of specific IP addresses, and limiting the amount of data transmitted within a specific time period. By implementing rate limiting rules, the spread of abnormal traffic can be effectively controlled, preventing it from causing further impact on the system.

[0129] Step S4: Determine whether the target business request is an abnormal request. If yes, proceed to step S5; otherwise, return to step S2.

[0130] For example, abnormal requests may include at least one of the following: sending data packets to the server at high frequency, abnormal data packet size, sending business requests during abnormal data transmission periods, etc.

[0131] If the target service request meets any of the above abnormal request criteria, it is determined to be an abnormal request; otherwise, the target service request is determined to be a normal request.

[0132] Step S5: Store and analyze the data related to the target business request.

[0133] It can perform data storage and analysis on both normal and abnormal business requests, or it can perform data storage and analysis only on abnormal target business requests.

[0134] Specifically, it can acquire data such as the IP address, event, behavior, and time of target business requests and store it on the ground for subsequent analysis. Based on the analysis results, it can further understand the characteristics and patterns of abnormal behavior, and formulate more accurate rate limiting strategies based on these characteristics and patterns.

[0135] Step S6: Based on the analysis results, control the data traffic and permission levels for data transmission between the server and the client.

[0136] Methods for traffic limiting level control can include: implementing traffic limiting levels for IP addresses based on analysis results. For IP addresses that frequently exhibit abnormal behavior, stricter rate limiting measures can be implemented, such as reducing their access permissions or limiting their data transmission speed. For IP addresses exhibiting normal behavior, their access permissions can be maintained or appropriately relaxed to ensure the normal operation of the system.

[0137] Step S7: Based on the controlled data traffic and permission level, block the target business requests sent by the client.

[0138] Upon identifying abnormal behavior, it is characterized and tracked using business ID and user ID, and timely blocking measures are taken to prevent its further spread. Simultaneously, normal behavior is also subject to necessary detection and protection to ensure it is unaffected by abnormal behavior. For example, blocking strategies are implemented at the kernel level to effectively isolate abnormal behavior and protect system security and stability.

[0139] refer to Figure 4 It illustrates a service request processing apparatus 30 provided in an embodiment of this application. The service request processing apparatus 30 includes:

[0140] The first acquisition module 301 is used to acquire the service request information of the service request in response to the service request sent by the client. The service request information includes: the target service identifier of the target service accessed by the service request, the source Internet Protocol address when the client sends the service request, and the data packet size corresponding to the service request.

[0141] The second acquisition module 302 is used to acquire, based on the service identifier, the number of times a service request for accessing a target service is sent within a preset time period based on the source Internet Protocol address;

[0142] The third acquisition module 303 is used to obtain the judgment result of whether a business request is an abnormal request based on the number of requests and a preset request number threshold, as well as the data packet size and a preset data packet size threshold.

[0143] The first determination module 304 is used to determine the client's access permissions to the target service based on the judgment result.

[0144] Optionally, the service request information also includes: the permission level corresponding to the source Internet Protocol address when the client sends a target service request based on the source Internet Protocol address. The service request processing device also includes:

[0145] The fourth acquisition module is used to acquire the number of abnormal service requests sent from the source Internet Protocol address within a preset time period;

[0146] The first update module is used to reduce the permission level and obtain a new permission level if the number of anomalies is greater than or equal to the first preset threshold for the number of anomalies.

[0147] The first determining module 304 includes:

[0148] The first determination submodule is used to determine that the client does not have access to the target service if the target service request is an abnormal request and / or the new permission level is lower than the permission level threshold set for the target service.

[0149] Optionally, the first determining module 304 includes:

[0150] The second determination submodule is used to determine if the target business request is a normal request and the new permission level is higher than or equal to the permission level threshold set for the target business, and then determine that the client has the permission to access the target business.

[0151] If it is determined that the client has access permission to access the target service, device 30 also includes:

[0152] The fifth acquisition module is used to access the target service according to the target service request after determining the client's access permissions based on the judgment result, and obtain the access result of the target service.

[0153] The sixth acquisition module is used to acquire the target data transmission speed for transmitting access results to the client;

[0154] The first transmission module is used to transmit the access results to the client based on the target data transmission speed.

[0155] Optionally, the fifth acquisition module may include:

[0156] The acquisition submodule is used to obtain the initial data transmission speed configured for the source Internet Protocol address when a target service request is received from the client;

[0157] The second update submodule is used to reduce the initial data transmission speed to obtain the target data transmission speed if the number of abnormal service requests sent from the source Internet Protocol address within a preset time period is greater than or equal to a second preset abnormal number threshold.

[0158] Optionally, device 30 also includes:

[0159] The third update submodule is used to update the initial data transmission speed using the target data transmission speed after obtaining the data transmission speed for transmitting access results to the client. This allows the module to obtain a new target data transmission speed based on the updated initial data transmission speed when a new business request is received from the client.

[0160] Optionally, if the service request information includes user privacy information, the device 30 further includes:

[0161] The second determination module is used to determine the user privacy information in the business request information based on preset keywords after determining the client's access permissions to the target business according to the judgment result.

[0162] The seventh acquisition module is used to filter user privacy information in business request information to obtain filtered business request information;

[0163] The log generation module is used to store filtered business request information and generate abnormal business request logs based on the filtered business request information.

[0164] Optionally, the first determining module includes:

[0165] The third determination submodule is used to determine that the target business request is an abnormal request if the number of requests is greater than or equal to a preset request number threshold and / or the data packet size is greater than or equal to a preset data packet size threshold.

[0166] The fourth determination submodule is used to determine that the target business request is a normal request if the number of requests is less than a preset request number threshold and the data packet size is less than a preset data packet size threshold.

[0167] In this embodiment, abnormal target business requests with abnormal request counts or abnormal data packet sizes can be avoided from accessing the target business, preventing the server from executing abnormal target business requests and feeding back the access results to the client. This avoids the problem of data leakage to unauthorized clients that make abnormal business access requests, and this embodiment improves the security of business request processing.

[0168] Reference Figure 5 The electronic device 400 may include one or more of the following components: processing component 402, memory 404, power supply component 406, multimedia component 408, audio component 410, input / output (I / O) interface 412, sensor component 414, and communication component 416.

[0169] Processing component 402 typically controls the overall operation of electronic device 400, such as operations associated with display, telephone calls, data communication, camera operation, and recording. Processing component 402 may include one or more processors 420 to execute instructions to perform all or part of the steps of the methods described above. Furthermore, processing component 402 may include one or more modules to facilitate interaction between processing component 402 and other components. For example, processing component 402 may include a multimedia module to facilitate interaction between multimedia component 408 and processing component 402.

[0170] Memory 404 is used to store various types of data to support the operation of electronic device 400. Examples of this data include instructions for any application or method operating on electronic device 400, contact data, phonebook data, messages, pictures, multimedia, etc. Memory 404 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 storage, flash memory, magnetic disk, or optical disk.

[0171] Power supply component 406 provides power to various components of electronic device 400. Power supply component 406 may include a power management system, one or more power supplies, and other components associated with generating, managing, and distributing power to electronic device 400.

[0172] Multimedia component 408 includes an interface that provides an output interface between electronic device 400 and a user. In some embodiments, the interface may include a liquid crystal display (LCD) and a touch panel (TP). If the interface includes a touch panel, the interface may be implemented as a touchscreen to receive input signals from the user. The touch panel includes one or more touch sensors to sense touches, swipes, and gestures on the touch panel. The touch sensors may not only sense the boundaries of touch or swipe actions but also detect the duration and pressure associated with the touch or swipe operation. In some embodiments, multimedia component 408 includes a front-facing camera and / or a rear-facing camera. When electronic device 400 is in an operating mode, such as a shooting mode or a multimedia mode, the front-facing camera and / or rear-facing camera may receive external multimedia data. Each front-facing camera and rear-facing camera may be a fixed optical lens system or have focal length and optical zoom capabilities.

[0173] Audio component 410 is used to output and / or input audio signals. For example, audio component 410 includes a microphone (MIC) used to receive external audio signals when electronic device 400 is in an operating mode, such as call mode, recording mode, and voice recognition mode. The received audio signals may be further stored in memory 404 or transmitted via communication component 416. In some embodiments, audio component 410 also includes a speaker for outputting audio signals.

[0174] Input / output (I / O) interface 412 provides an interface between processing component 402 and peripheral interface modules, such as keyboards, click wheels, buttons, etc. These buttons may include, but are not limited to, home buttons, volume buttons, power buttons, and lock buttons.

[0175] Sensor assembly 414 includes one or more sensors for providing state assessments of various aspects of electronic device 400. For example, sensor assembly 414 may detect the on / off state of electronic device 400, the relative positioning of components such as the display and keypad of electronic device 400, changes in position of electronic device 400 or a component of electronic device 400, the presence or absence of user contact with electronic device 400, orientation or acceleration / deceleration of electronic device 400, and temperature changes of electronic device 400. Sensor assembly 414 may include a proximity sensor configured to detect the presence of nearby objects without any physical contact. Sensor assembly 414 may also include a light sensor, such as a CMOS or CCD image sensor, for use in imaging applications. In some embodiments, sensor assembly 414 may also include an accelerometer, gyroscope, magnetometer, pressure sensor, or temperature sensor.

[0176] Communication component 416 facilitates wired or wireless communication between electronic device 400 and other devices. Electronic device 400 can access wireless networks based on communication standards, such as WiFi, carrier networks (such as 2G, 3G, 4G, or 5G), or combinations thereof. In one exemplary embodiment, communication component 416 receives broadcast signals or broadcast-related information from an external broadcast management system via a broadcast channel. In one exemplary embodiment, communication component 416 also includes a near-field communication (NFC) module to facilitate short-range communication. For example, the NFC module may be implemented based on radio frequency identification (RFID) technology, Infrared Data Association (IrDA) technology, ultra-wideband (UWB) technology, Bluetooth (BT) technology, and other technologies.

[0177] In an exemplary embodiment, the electronic device 400 may be implemented by one or more application-specific integrated circuits (ASICs), digital signal processors (DSPs), digital signal processing devices (DSPDs), programmable logic devices (PLDs), field-programmable gate arrays (FPGAs), controllers, microcontrollers, microprocessors, or other electronic components to implement a service request processing method provided in the embodiments of this application.

[0178] In an exemplary embodiment, a non-transitory computer-readable storage medium including instructions is also provided, such as a memory 404 including instructions, which can be executed by a processor 420 of an electronic device 400 to perform the above-described method. For example, the non-transitory storage medium may be a ROM, random access memory (RAM), CD-ROM, magnetic tape, floppy disk, and optical data storage device, etc.

[0179] Figure 6This is a block diagram of an electronic device 500 according to another embodiment of the present invention. For example, the electronic device 500 may be provided as a server. (See also...) Figure 6 The electronic device 500 includes a processing component 522, which further includes one or more processors, and memory resources represented by a memory 532 for storing instructions, such as application programs, that can be executed by the processing component 522. The application programs stored in the memory 532 may include one or more modules, each corresponding to a set of instructions. Furthermore, the processing component 522 is configured to execute instructions to perform a business request processing method provided in embodiments of this application.

[0180] Electronic device 500 may also include a power supply component 526 configured to perform power management of electronic device 500, a wired or wireless network interface 550 configured to connect electronic device 500 to a network, and an input / output (I / O) interface 558. Electronic device 500 may operate on an operating system stored in memory 532, such as Windows Server™, Mac OS X™, Unix™, Linux™, FreeBSD™, or similar.

[0181] Other embodiments of this application will readily occur to those skilled in the art upon consideration of the specification and practice of the application disclosed herein. This application is intended to cover any variations, uses, or adaptations of this application that follow the general principles of this application and include common knowledge or customary techniques in the art not disclosed herein. The specification and examples are to be considered exemplary only, and the true scope and spirit of this application are indicated by the following claims.

[0182] It should be understood that this application is not limited to the precise structure described above and shown in the accompanying drawings, and various modifications and changes can be made without departing from its scope. The scope of this application is limited only by the appended claims. 。

Claims

1. A business request processing method, characterized in that, Applied to the server side, the method includes: In response to a target service request sent by a client, the service request information of the target service request is obtained; the service request information includes: the target service identifier of the target service accessed by the target service request, the source Internet Protocol address, and the data packet size corresponding to the target service request; Based on the service identifier, obtain the number of service requests sent to access the target service within a preset time period, based on the source Internet Protocol address; Based on the number of requests and the preset request number threshold, as well as the data packet size and the preset data packet size threshold, a judgment result is obtained as to whether the target business request is an abnormal request; Based on the judgment result, the client's access permissions to the target service are determined; If the service request information further includes: the permission level corresponding to the source Internet Protocol address when the client sends the target service request based on the source Internet Protocol address, then the method further includes: Get the number of abnormal service requests sent from the source Internet Protocol address within a preset time period; If the number of anomalies is greater than or equal to the first preset threshold for the number of anomalies, then the permission level is reduced to obtain a new permission level; The step of determining the client's access rights to the target service based on the judgment result includes: If the target service request is an abnormal request, and / or the new permission level is lower than the permission level threshold set for the target service, then it is determined that the client does not have the permission to access the target service. If the target service request is a normal request, and the new permission level is higher than or equal to the permission level threshold set for the target service, then it is determined that the client has the permission to access the target service. If it is determined that the client has access permission to access the target service, then after determining the client's access permission to the target service based on the determination result, the method further includes: Access the target service according to the target service request, and obtain the access result of the target service; Obtain the initial data transmission rate configured for the source Internet Protocol address when the target service request sent by the client is received; If, within the preset time period, the number of abnormal service requests originating from the source Internet Protocol address is greater than or equal to a second preset abnormal number threshold, then the initial data transmission speed is reduced to obtain the target data transmission speed. Based on the target data transmission speed, the access result is transmitted to the client.

2. The method according to claim 1, characterized in that, After obtaining the target data transmission speed for transmitting access results to the client, the method further includes: The initial data transmission speed is updated using the target data transmission speed, so that when a new service request is received from the client, a new target data transmission speed can be obtained based on the updated initial data transmission speed.

3. The method according to claim 1, characterized in that, If the service request information includes user privacy information, then after determining the client's access rights to the target service based on the judgment result, the method further includes: If the determination result indicates that the target service request is an abnormal request, then the user privacy information in the service request information is determined based on preset keywords; The user privacy information in the business request information is filtered to obtain the filtered business request information. Store the filtered business request information and generate abnormal business request logs based on the filtered business request information.

4. The method according to any one of claims 1 to 3, characterized in that, The step of obtaining a judgment result on whether the target service request is an abnormal request based on the number of requests and a preset request number threshold, and the data packet size and a preset data packet size threshold, includes: If the number of requests is greater than or equal to the preset request number threshold, and / or the data packet size is greater than or equal to the preset data packet size threshold, then the target service request is determined to be an abnormal request. If the number of requests is less than the preset request number threshold and the data packet size is less than the preset data packet size threshold, then the target service request is determined to be a normal request.

5. A business request processing device, characterized in that, Applied to the server side, the device includes: The first acquisition module is used to acquire business request information of the business request in response to a business request sent by the client; the business request information includes: the target business identifier of the target business accessed by the business request, the source Internet Protocol address, and the data packet size corresponding to the business request; The second acquisition module is used to acquire, based on the service identifier, the number of times a service request for accessing the target service is sent within a preset time period based on the source Internet Protocol address; The third acquisition module is used to obtain a judgment result on whether the business request is an abnormal request based on the number of requests and a preset request number threshold, as well as the data packet size and a preset data packet size threshold. The first determining module is used to determine the client's access permissions to the target service based on the determination result; The service request information also includes: the permission level corresponding to the source Internet Protocol address when the client sends a target service request based on the source Internet Protocol address; the device also includes: The fourth acquisition module is used to acquire the number of abnormal service requests sent from the source Internet Protocol address within a preset time period; The first update module is used to reduce the permission level and obtain a new permission level if the number of anomalies is greater than or equal to the first preset threshold for the number of anomalies. The first determining module includes: The first determination submodule is used to determine that the client does not have access to the target service if the target service request is an abnormal request and / or the new permission level is lower than the permission level threshold set for the target service. The second determination submodule is used to determine if the target business request is a normal request and the new permission level is higher than or equal to the permission level threshold set for the target business, and then determine that the client has the permission to access the target business. If it is determined that the client has access permission to access the target service, the device further includes: The fifth acquisition module is used to access the target service according to the target service request after determining the client's access permissions based on the judgment result, and obtain the access result of the target service. The sixth acquisition module is used to acquire the target data transmission speed for transmitting access results to the client; The first transmission module is used to transmit the access results to the client based on the target data transmission speed; The fifth acquisition module includes: The acquisition submodule is used to obtain the initial data transmission speed configured for the source Internet Protocol address when a target service request is received from the client; The second update submodule is used to reduce the initial data transmission speed to obtain the target data transmission speed if the number of abnormal service requests sent from the source Internet Protocol address within a preset time period is greater than or equal to a second preset abnormal number threshold.

6. An electronic device, characterized in that, It includes a processor and a memory, the memory storing a program or instructions that can run on the processor, the program or instructions being executed by the processor to implement the steps of the method as described in any one of claims 1 to 4.

7. A readable storage medium, characterized in that, The readable storage medium stores a program or instructions that, when executed by a processor, implement the steps of the method as described in any one of claims 1 to 4.

Images