A method and apparatus for checking client security

Abstract

The one or more embodiments of the specification provide a method and device for checking client security, the method comprising: in response to a first request sent by a client to be checked, generating a first check value and returning the first check value to a source address contained in the first request; receiving a second request containing the source address and obtaining a second check value contained in the second request; and determining that the client to be checked passes the check if it is determined that the second check value is generated based on the first check value.

Description

Technical Field

[0001] This specification relates to one or more embodiments in the field of data transmission, and more particularly to a method and apparatus for verifying client security. Background Technology

[0002] In related technologies, when a client needs a service from a server, the client can send a request to the server. The server can identify the source address in the request and, if that source address corresponds to the source address of a secure client, process the service requested. However, this process does not verify whether the request initiator is a secure client. Therefore, an insecure client can also send a request to the server, modifying the source address in the request to the address corresponding to a secure client, thereby impersonating a secure client to attack the server and consume its resources. Summary of the Invention

[0003] In view of this, one or more embodiments of this specification provide a method and apparatus for verifying client security, which can solve the shortcomings existing in related technologies.

[0004] To achieve the above objectives, one or more embodiments of this specification provide the following technical solutions:

[0005] According to a first aspect of one or more embodiments of this specification, a client security verification method is provided, the method comprising:

[0006] In response to the first request sent by the client to be verified, a first verification value is generated and the first verification value is returned to the source address contained in the first request;

[0007] Receive a second request containing the source address, and obtain the second checksum contained in the second request;

[0008] If the second verification value is determined to be generated based on the first verification value, the client to be verified is determined to have passed the verification.

[0009] According to a second aspect of one or more embodiments of this specification, a client security verification method is provided, the method comprising:

[0010] Generation unit: In response to the first request sent by the client to be verified, generates a first verification value and returns the first verification value to the source address contained in the first request;

[0011] Receiving unit: receives a second request containing the source address, and obtains a second checksum contained in the second request;

[0012] Determination Unit: If the second verification value is determined to be generated based on the first verification value, the client to be verified is determined to pass the verification.

[0013] According to a third aspect of one or more embodiments of this specification, an electronic device is provided, comprising:

[0014] processor;

[0015] Memory used to store processor-executable instructions;

[0016] The processor implements the steps of the method as described in the first aspect by running the executable instructions.

[0017] According to a fourth aspect of one or more embodiments of this specification, a computer-readable storage medium is provided that stores computer instructions thereon, which, when executed by a processor, implement the steps of the method as described in the first aspect.

[0018] According to a fifth aspect of one or more embodiments of this specification, a computer program is provided that, when executed by a processor, implements the steps of the method as described in the first aspect.

[0019] As can be seen from the above technical solutions, the client security verification method provided in one or more embodiments of this specification, on the one hand, upon receiving a first request sent by the client to be verified, returns a first verification value to the source address contained in the first request, enabling the server to obtain a second verification value in a second request containing the source address, and verify the security of the client to be verified based on the second verification value, thereby realizing the verification of client security and avoiding resource waste caused by the server returning a response to an insecure client; on the other hand, since the secure client can generate a second verification value based on the first verification value and send the second verification value to the server for verification, the server determines that the client to be verified has passed the verification when it determines that the second verification value is generated based on the first verification value, so that the secure client can pass the verification and obtain the service provided by the server. Attached Figure Description

[0020] Figure 1 This is an exemplary embodiment of an architecture diagram of a client security verification system.

[0021] Figure 2 This is a flowchart illustrating a client security verification method provided in an exemplary embodiment.

[0022] Figure 3a This is a schematic diagram of determining a second check value provided in an exemplary embodiment.

[0023] Figure 3bThis is a schematic diagram illustrating another method for determining a second check value, provided in an exemplary embodiment.

[0024] Figure 4 This is a flowchart of a retransmission mechanism provided in an exemplary embodiment.

[0025] Figure 5 This is a schematic structural diagram of a device provided in an exemplary embodiment.

[0026] Figure 6 This is a block diagram of a client security verification device provided in an exemplary embodiment. Detailed Implementation

[0027] Exemplary embodiments will now be described in detail, examples of which are illustrated in the accompanying drawings. When the following description relates to the drawings, unless otherwise indicated, the same numerals in different drawings denote the same or similar elements. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with one or more embodiments of this specification. Rather, they are merely examples of apparatuses and methods consistent with some aspects of one or more embodiments of this specification as detailed in the appended claims.

[0028] It should be noted that the steps of the corresponding methods are not necessarily performed in the order shown and described in this specification in other embodiments. In some other embodiments, the methods may include more or fewer steps than described in this specification. Furthermore, a single step described in this specification may be broken down into multiple steps in other embodiments; and multiple steps described in this specification may be combined into a single step in other embodiments.

[0029] The user information (including but not limited to user device information, user personal information, etc.) and data (including but not limited to data used for analysis, data stored, data displayed, etc.) involved in this application are all information and data authorized by the user or fully authorized by all parties. Furthermore, the collection, use and processing of the relevant data must comply with the relevant laws, regulations and standards of the relevant countries and regions, and corresponding operation entry points are provided for users to choose to authorize or refuse.

[0030] To further illustrate one or more embodiments of this specification, the following embodiments are provided:

[0031] Figure 1 This is an exemplary embodiment of an architecture diagram of a client security verification system, such as... Figure 1 As shown, the architecture diagram includes: terminal 11, terminal 12 and server 13.

[0032] Terminals 11 and 12 can be any type of electronic device that a user can use, such as mobile phones, tablets, laptops, PDAs (Personal Digital Assistants), wearable devices (such as smart glasses, smartwatches, etc.), etc., and this specification does not limit them. Client programs can run on terminals 11-12, enabling them to be configured as clients. It should be noted that the client in this specification can include a web application based on a B / S (Browser / Server) architecture, or a client based on a C / S (Client / Server) architecture, and this specification does not limit them.

[0033] Server 13 can be a physical server containing a single host, or server 13 can be a virtual server hosted in a host cluster. Server 13 can run server-side programs, thus configuring server 13 as a server.

[0034] Clients and servers can interact, with clients sending requests to the server to obtain services. Generally, most clients are secure, and the source address in their requests is their own legitimate address. However, some clients are insecure; their requests may contain a fake source address, potentially a spoofed address of another client. Insecure clients can pose security risks to the server by sending requests with false source addresses, such as DDoS (Distributed Denial of Service) attacks or other forms of attacks.

[0035] In related technologies, data interaction can be achieved by pre-establishing a connection between the client and server. For example, the client and server can establish a connection by handshaking based on the TCP (Transmission Control Protocol). During the handshake, both the client and server can exchange identity verification via TCP requests to confirm each other's identities. The server can also verify whether the client is a secure client at this time. For instance, the server can avoid providing services to insecure clients to prevent DDoS attacks.

[0036] However, establishing a connection between the client and server takes time, so data interaction via TCP can result in relatively high latency, making it unsuitable for scenarios such as live streaming and real-time document collaboration. Therefore, related technologies propose using connectionless protocols for data interaction between the client and server. For example, the client and server can interact using the UDP (User Datagram Protocol). Of course, other connectionless protocols are also applicable to the technical solutions described in this specification, and this specification does not impose any limitations on them.

[0037] When exchanging data using the UDP protocol, there is no need for the client and server to establish a connection beforehand. The client can directly send UDP requests to the server, and the server can provide corresponding services based on the received UDP requests. Because the UDP protocol does not require the client and server to establish a connection beforehand, the server cannot verify whether the client is secure through a handshake. Therefore, in connectionless data exchange, insecure clients can also send requests to the server, causing the server to respond to the request, such as providing corresponding services, thereby consuming server resources.

[0038] To address the problems existing in related technologies, this specification proposes a method for verifying client security.

[0039] In the client security verification method proposed in this specification, the server can generate a first verification value in response to a first request sent by the client to be verified, and return the first verification value to the source address contained in the first request. The server to be verified can receive a second request containing the source address and obtain the second verification value contained in the second request. If it is determined that the second verification value is generated based on the aforementioned first verification value, the client to be verified is determined to have passed the verification, that is, the client to be verified is determined to be a secure client.

[0040] The above scheme achieves two objectives. First, upon receiving a first request from the client to be verified, the server returns a first verification value to the source address contained in the first request. This allows the server to obtain a second verification value from a second request containing the source address and verify the security of the client based on the second verification value. This ensures client security and avoids resource waste caused by the server returning responses to insecure clients. Second, since a secure client can generate a second verification value based on the first verification value and send it to the server for verification, the server determines that the client to be verified has passed verification if the second verification value is generated based on the first verification value. This allows the secure client to pass verification and obtain the services provided by the server.

[0041] Figure 2 This is a flowchart illustrating a client security verification method as provided in an exemplary embodiment. Figure 2 As shown, the method may include the following steps:

[0042] Step 202: In response to the first request sent by the client to be verified, generate a first verification value and return the first verification value to the source address contained in the first request.

[0043] The client to be verified can be any client that sends a request to the server. The first request is a request sent by the client to be verified to the server. The first request contains a source address, and the server can use this source address to return the generated first verification value to the client corresponding to the source address. From the server's perspective, the source address contained in any request can be used to represent the network address of the sender of that request. For example, the server may identify the source address contained in the first request as the source address of the client to be verified, but it cannot directly distinguish whether this source address is the real address or a fake address of the client to be verified. The aforementioned source address can be, for example, a source IP address or a source MAC address, etc., and this specification does not impose any restrictions on this.

[0044] It is worth noting that the client corresponding to the source address can be the client that sent the first request to be verified, or it can be another client that is different from the client to be verified.

[0045] If the client to be verified is a secure client, the client corresponding to the source address in the first request is the client to be verified. If the client to be verified is an insecure client, the client to be verified can modify the source address in the first request to the source address corresponding to the secure client. In this case, the client corresponding to the source address in the first request is a different client from the client to be verified.

[0046] When the client to be verified is the client corresponding to the source address, the client to be verified can receive the first verification value and respond to it, thereby completing the security verification. When the client to be verified is not the client corresponding to the source address, the client to be verified cannot receive the first verification value, and the client that receives the first verification value will not respond to it because it did not send the first request. Therefore, the server will not receive a response to the first verification value, which makes the client to be verified fail the security verification.

[0047] In one embodiment, generating the first verification value includes: randomly generating the first verification value. The first verification value can be randomly generated by the server, and it can be a random sequence of numbers, a random string, or other forms of numerical value, or any combination of the above. This specification does not limit this.

[0048] In this embodiment, the server uses a generated random number as the first verification value, making the first verification value variable. This prevents insecure clients from obtaining the first verification value by intercepting historical verification values ​​or making exhaustive guesses, ensuring that insecure clients cannot correctly generate the second verification value. This helps improve the accuracy of the server's security verification of the client.

[0049] Step 204: Receive a second request containing the source address and obtain the second checksum contained in the second request.

[0050] The source address contained in the second request is the same as the source address contained in the first request. After returning the first verification value, the server can identify the source address contained in all subsequent requests. If a request is found to contain the same source address as the first request, it is identified as the second request.

[0051] After the second request is determined, the server can obtain the second verification value from the second request.

[0052] Step 206: If it is determined that the second verification value is generated based on the first verification value, then the client to be verified is determined to have passed the verification.

[0053] If the client to be verified is a secure client, it can receive the first verification value sent by the server and generate a second verification value based on that first value. Therefore, if the server determines that the second verification value is generated based on the first verification value, it can conclude that the client to be verified has passed the verification, meaning it is a secure client.

[0054] If the client to be verified is not an insecure client, it will not receive the first verification value and will be unable to generate the second verification value based on the first verification value. Therefore, the server will not receive the second verification value, or the second verification value received by the server will not be generated based on the first verification value. In this case, the client to be verified will fail the verification, meaning the client to be verified is an insecure client.

[0055] In this embodiment, on the one hand, upon receiving a first request from the client to be verified, the server returns a first verification value to the source address contained in the first request, enabling the server to obtain a second verification value from a second request containing the source address. The server then verifies the security of the client based on this second verification value, thereby verifying the client's security and avoiding resource waste caused by the server returning responses to insecure clients. On the other hand, since the secure client can generate a second verification value based on the first verification value and send it to the server for verification, the server determines that the client to be verified has passed verification if the second verification value is generated based on the first verification value. This allows the secure client to pass verification and obtain the services provided by the server.

[0056] The second check value is determined to be generated based on the first check value if any of the following conditions are met: the second check value is consistent with the first check value; or the second check value is generated by processing the first check value according to preset processing logic.

[0057] In one embodiment, if the client to be verified is a secure client, the client can directly use the received first verification value as the second verification value and return a second request containing the second verification value to the server. In this case, if the first verification value and the second verification value are consistent, the server can determine that the second verification value was generated based on the first verification value and confirm that the client to be verified is a secure client. In this embodiment, directly using the first verification value as the second verification value eliminates the need for either the client or the server to process the first verification value, thus improving verification efficiency.

[0058] In another embodiment, if the client to be verified is a secure client, the client can process the received first verification value according to preset processing logic to generate a second verification value. The preset processing logic can be determined in advance by the secure client and the server. Specifically, the preset processing logic can be to perform calculations on the first verification value according to a predetermined algorithm to obtain the second verification value; the algorithm can be an incrementing algorithm or a secure hash algorithm, etc.; the preset processing logic can also be to encrypt the first verification value according to a predetermined key; the preset processing logic can also be to determine the value corresponding to the first verification value as the second verification value in a predetermined mapping table, where the mapping table records the second verification values ​​corresponding to different first verification values. This specification does not limit the specific processing logic.

[0059] For example, such as Figure 3aAs shown, server 31 can send the first verification value 301 to client 32 to be verified. Client 32 can take the received first verification value 301 as input and process the input according to preset processing logic 303 to obtain the output second verification value 302. Client 32 can send the obtained second verification value 302 to server 31, and server 31 can parse the second verification value 302 according to preset processing logic 304a to obtain the third verification value 305. Preset processing logic 304a can be the inverse logic of preset processing logic 303. For example, if preset processing logic 303 is to encrypt the first verification value according to a predetermined key to obtain the second verification value, then preset processing logic 304a can be to decrypt the second verification value according to a predetermined key to obtain the third verification value. Server 31 can compare the third verification value 305 with the first verification value 301. If they match, it is determined that the second verification value 302 was generated based on the first verification value 301.

[0060] like Figure 3b As shown, server 31 may also choose not to parse the second verification value 302. Server 31 can process the first verification value 301 according to the same preset processing logic 304b to obtain the fourth verification value 306. The preset processing logic 304b is the same as the preset processing logic 303. Server 31 can compare the fourth verification value 306 with the second verification value 302. If they match, it is determined that the second verification value 302 was generated based on the first verification value 301.

[0061] In this embodiment, the first verification value is processed by preset processing logic to obtain the second verification value, so that insecure clients that are unsure of the preset processing logic cannot generate the second verification value, thereby further strengthening the verification of client security and ensuring client security.

[0062] In one embodiment, the first request includes a Uniform Resource Locator (URL) for the resource targeted by the client to be verified; generating the first verification value includes: verifying the validity of the URL; and generating the first verification value if the URL is confirmed to be valid.

[0063] In the first request, the Uniform Resource Locator (URL) is used to locate the information location corresponding to the resource required by the client. For example, when the first request is a UDP request for a live streaming service, the URL in the first request is the URL of the client's streaming object.

[0064] Assume the URL in the first request is "http: / / DomainName / Filename?auth_key=timestamp-md5hash", where "DomainName" is the domain name corresponding to the server; "Filename" is the actual URL accessed from the origin server, and during validity verification, the content after " / " and before "?" is used as the actual URL accessed from the origin server; "auth_key" is the key pre-set by the server and the security client, and during validity verification, the content after "?" and before "=" is used as the key; "timestamp" is the timestamp, including the time the URL was generated and its expiration time; and "md5hash" is the string calculated using the MD5 Message-Digest Algorithm for "Filename?auth_key=timestamp". Verifying the validity of the Uniform Resource Locator (URL) can be divided into two steps: first, verifying whether the URL is within its valid duration; second, verifying whether the URL has the necessary permissions to access the required resource. The server can determine the validity period of a URL based on the "timestamp" to determine whether the URL is within its validity period; the server can determine whether the URL has permission to access the required resources based on the "md5hash".

[0065] In this embodiment, the client's security is verified only after confirming that the first request contains a Uniform Resource Locator (URL). This eliminates the need for the server to respond to the first request corresponding to an invalid URL, thus saving server resources.

[0066] In one embodiment, the first request is initiated for a target service; the method further includes: providing the target service to the client to be verified if it is determined that the client to be verified has passed the verification.

[0067] The target service can be any service that the server can provide, such as a streaming service that pulls a specific live stream or an access service that accesses a specific resource website.

[0068] In this embodiment, the target service is only provided to the client to be verified if the client passes the verification, thereby avoiding the waste of resources caused by the server providing services to insecure clients that fail the verification.

[0069] Furthermore, the first request is a UDP request; providing the target service to the client to be verified includes: providing the target service to the client to be verified based on the UDP protocol.

[0070] Because UDP is not a connection-oriented protocol, it has the characteristics of low resource consumption and fast processing speed. Therefore, it is often used in the transmission of audio, video and ordinary data. For example, commonly used chat software and live streaming both use the UDP protocol.

[0071] The server provides the target service to the client to be verified based on the UDP protocol, that is, it transmits data to the client to be verified in the form of UDP packets. Taking a live streaming scenario as an example, if the first request is a request to pull a live stream for a specific live room, the server can pull the live stream from that live room and send the live stream data to the client to be verified in the form of UDP, thereby providing the pull stream service to the client to be verified.

[0072] In this embodiment, the target service is provided to the client to be verified based on the UDP protocol. Since the UDP protocol is not a connection-oriented protocol, it has the characteristics of low resource consumption and fast processing speed. This makes the service provided by the server highly real-time and has low resource consumption, thereby improving the efficiency of the service.

[0073] In one embodiment, the method further includes: ignoring the second request if it is determined that the second verification value was not generated based on the first verification value.

[0074] Ignoring the second request means not responding to it and not providing the service requested by the second request to the client being verified. If the client being verified is insecure, the server can ignore the second request to avoid consuming unnecessary resources for insecure clients.

[0075] In this embodiment, by ignoring the second request when it is determined that the second verification value is not generated based on the first verification value, on the one hand, upon receiving the first request sent by the client to be verified, the server returns the first verification value to the source address contained in the first request, enabling the server to obtain the second verification value in the second request containing the source address, and verify the security of the client to be verified based on the second verification value, thereby realizing the verification of client security and avoiding resource waste caused by the server returning a response to an insecure client; on the other hand, since the secure client can generate the second verification value based on the first verification value and send the second verification value to the server for verification, the server determines that the client to be verified passes the verification when it is determined that the second verification value is generated based on the first verification value, so that the secure client can pass the verification and obtain the service provided by the server.

[0076] In one embodiment, a retransmission mechanism is added to the client security verification method.

[0077] Figure 4 This is a flowchart illustrating a retransmission mechanism provided in an exemplary embodiment. For example... Figure 4As shown, the method may include the following steps:

[0078] Step 401: Return the first verification value. Step 402: Start the timer.

[0079] The server can be equipped with a timer that starts counting the duration of time before a second request is received after the first verification value is returned.

[0080] Step 403: Has the second request been received?

[0081] The server can periodically check whether a second request has been received. This period is less than a preset duration; for example, if the preset duration is 3 seconds, this period is 0.3 seconds. If the server has received the second request, it proceeds to step 404 and resets the timer. If the server has not received the second request, it proceeds to step 405 and checks whether the preset duration has been reached. If the timer has not reached the preset duration, the server can return to step 403 to continue checking whether a second request has been received. If the timer has reached the preset duration, it proceeds to step 406 and returns to the first verification value.

[0082] The first checksum returned can be the same as or different from the first checksum returned. For example, if the first checksum returned is 5 and the second checksum returned is 10, then any subsequent second checksum returned, whether it is 5 or 10, will pass the client's checksum verification.

[0083] Step 407: Increment the timer count by 1. Step 408: Check if the preset count has been reached.

[0084] If the preset number of attempts is 3, and step 406 is the second time the first verification value is returned, then the count will be incremented by 1 to 1, which is less than the preset number of attempts. The process will then return to step 402 and restart the count. If step 406 is the fourth time the first verification value is returned, then the count will be incremented by 1 to reach 3, which is the preset number of attempts. The process will then proceed to step 409, where the response will stop and the server will no longer respond to the first request.

[0085] In this embodiment, by adding a retransmission mechanism to the client security verification, the client to be verified is prevented from failing to receive the first verification value due to the loss of data packets during transmission, thereby preventing the client verification result from being incorrect due to data packet loss and increasing the accuracy of the client security verification.

[0086] Figure 5 This is a schematic structural diagram of a device provided in an exemplary embodiment. Please refer to... Figure 5At the hardware level, the device includes a processor 502, an internal bus 504, a network interface 506, memory 509, and non-volatile memory 510, and may also include other hardware required for its functions. One or more embodiments of this specification can be implemented in software, for example, the processor 502 reads the corresponding computer program from the non-volatile memory 510 into memory 508 and then runs it. Of course, in addition to software implementation, one or more embodiments of this specification do not exclude other implementation methods, such as logic devices or a combination of hardware and software, etc. That is to say, the execution subject of the following processing flow is not limited to each logic unit, but can also be hardware or logic devices. On one hand, when the device receives a first request from a client to be verified, it returns a first verification value to the source address contained in the first request. This allows the server to obtain a second verification value from a second request containing the source address and verify the security of the client to be verified based on the second verification value. This achieves client security verification and avoids resource waste caused by the server returning responses to insecure clients. On the other hand, since a secure client can generate a second verification value based on the first verification value and send the second verification value to the server for verification, the server determines that the client to be verified has passed the verification if the second verification value is generated based on the first verification value. This allows the secure client to pass the verification and obtain the services provided by the server.

[0087] Please refer to Figure 6 A client-side security verification device can be applied to, for example... Figure 6 The device shown, in order to implement the technical solution of this specification, may include:

[0088] The generation unit 602 is configured to respond to a first request sent by the client to be verified, generate a first verification value, and return the first verification value to the source address contained in the first request;

[0089] The receiving unit 604 is configured to receive a second request containing the source address and obtain a second checksum contained in the second request;

[0090] The determining unit 606 is used to determine that the client to be verified passes the verification when the second verification value is determined to be generated based on the first verification value.

[0091] Optionally, the generation unit 602 is specifically used for:

[0092] The first verification value is generated randomly.

[0093] Optionally, the second check value is determined to be generated based on the first check value if any of the following conditions are met:

[0094] The second check value is consistent with the first check value;

[0095] The second verification value is generated by processing the first verification value according to a preset processing logic.

[0096] Optionally, the first request includes the Uniform Resource Locator (URL) of the initial client; the generation unit 602 is specifically used for:

[0097] Verify the validity of the Uniform Resource Locator;

[0098] If the Uniform Resource Locator (URL) is confirmed to comply with the method, the first verification value is generated.

[0099] Optionally, the first request is initiated for the target service; the method further includes:

[0100] The providing unit 608 is used to provide the target service to the client to be verified if it is determined that the client to be verified has passed the verification.

[0101] Optionally, the first request is a User Datagram Protocol (UDP) request; the providing unit 608 is specifically used for:

[0102] The target service is provided to the client to be verified based on the UDP protocol.

[0103] Optionally, the method further includes:

[0104] Ignore unit 610: If it is determined that the second verification value is not generated based on the first verification value, ignore the second request.

[0105] The systems, devices, modules, or units described in the above embodiments can be implemented by computer chips or entities, or by products with certain functions. A typical implementation device is a computer, which can take the form of a personal computer, laptop computer, cellular phone, camera phone, smartphone, personal digital assistant, media player, navigation device, email sending and receiving device, game console, tablet computer, wearable device, or any combination of these devices.

[0106] In a typical configuration, a computer includes one or more processors (CPU), input / output interfaces, network interfaces, and memory.

[0107] Memory may include non-persistent storage in computer-readable media, such as random access memory (RAM) and / or non-volatile memory, such as read-only memory (ROM) or flash RAM. Memory is an example of computer-readable media.

[0108] Computer-readable media, including both permanent and non-permanent, removable and non-removable media, can store information using any method or technology. Information can be computer-readable instructions, data structures, modules of programs, or other data. Examples of computer storage media include, but are not limited to, phase-change memory (PRAM), static random access memory (SRAM), dynamic random access memory (DRAM), other types of random access memory (RAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory or other memory technologies, CD-ROM, digital versatile optical disc (DVD) or other optical storage, magnetic tape, disk storage, quantum memory, graphene-based storage media or other magnetic storage devices, or any other non-transferable medium that can be used to store information accessible by a computing device. As defined herein, computer-readable media does not include transient computer-readable media, such as modulated data signals and carrier waves.

[0109] A computer-readable medium (or computer-readable storage medium) of the form described above or any other form may store computer instructions thereon. When executed by a processor, these instructions implement one or more of the embodiments described above, thereby realizing the technical solutions of this specification. On the one hand, upon receiving a first request from a client to be verified, the computer-readable medium returns a first verification value to the source address contained in the first request. This allows the server to obtain a second verification value from a second request containing the source address and verify the security of the client to be verified based on the second verification value. This verifies the client's security and avoids resource waste caused by the server returning responses to insecure clients. On the other hand, since a secure client can generate a second verification value based on the first verification value and send it to the server for verification, the server determines that the client to be verified has passed verification if the second verification value is generated based on the first verification value. This allows the secure client to pass verification and obtain the services provided by the server.

[0110] This specification also provides a computer program that, when executed by a processor, implements one or more of the embodiments described above, thereby realizing the technical solutions of this specification. This computer program may be specifically recorded on the aforementioned or other computer-readable media, and this specification does not limit this. On the one hand, upon receiving a first request from a client to be verified, the computer program returns a first verification value to the source address contained in the first request, enabling the server to obtain a second verification value from a second request containing the source address. The server then verifies the security of the client to be verified based on this second verification value, thereby verifying the client's security and avoiding resource waste caused by the server returning responses to insecure clients. On the other hand, since a secure client can generate a second verification value based on the first verification value and send it to the server for verification, the server determines that the client to be verified has passed verification if the second verification value is generated based on the first verification value. This allows the secure client to pass verification and obtain the services provided by the server.

[0111] It should also be noted that the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitation, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes said element.

[0112] The foregoing has described specific embodiments of this specification. Other embodiments are within the scope of the appended claims. In some cases, the actions or steps recited in the claims may be performed in a different order than that shown in the embodiments and may still achieve the desired result. Furthermore, the processes depicted in the drawings do not necessarily require the specific or sequential order shown to achieve the desired result. In some embodiments, multitasking and parallel processing are possible or may be advantageous.

[0113] The terminology used in one or more embodiments of this specification is for the purpose of describing particular embodiments only and is not intended to limit the scope of one or more embodiments of this specification. The singular forms “a,” “described,” and “the” used in one or more embodiments of this specification and in the appended claims are also intended to include the plural forms unless the context clearly indicates otherwise. It should also be understood that the term “and / or” as used herein refers to and includes any or all possible combinations of one or more associated listed items.

[0114] It should be understood that although the terms first, second, third, etc., may be used to describe various information in one or more embodiments of this specification, such information should not be limited to these terms. These terms are only used to distinguish information of the same type from one another. For example, first information may also be referred to as second information without departing from the scope of one or more embodiments of this specification, and similarly, second information may also be referred to as first information. Depending on the context, the word "if" as used herein may be interpreted as "when," "in response to a determination," or "when," or "in the event of a determination."

[0115] The above description is merely a preferred embodiment of one or more embodiments of this specification and is not intended to limit the scope of one or more embodiments of this specification. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of one or more embodiments of this specification should be included within the protection scope of one or more embodiments of this specification.

Claims

1. A method for verifying client security, characterized in that, The method includes: In response to a first request sent by the client to be verified, a first verification value is generated and the first verification value is returned to the source address contained in the first request; the first request is a connectionless protocol request, and the source address is the network address used to characterize the sender in the connectionless protocol request; Receive a second request containing the source address, and obtain the second checksum contained in the second request; If the second verification value is determined to be generated based on the first verification value, the client to be verified is determined to have passed the verification.

2. The method according to claim 1, characterized in that, The generation of the first verification value includes: The first verification value is generated randomly.

3. The method according to claim 1, characterized in that, The second check value is determined to be generated based on the first check value if any of the following conditions are met: The second check value is consistent with the first check value; The second verification value is generated by processing the first verification value according to a preset processing logic.

4. The method according to claim 1, characterized in that, The first request contains the Uniform Resource Locator (URL) of the resource targeted by the client to be verified; The generation of the first verification value includes: Verify the validity of the Uniform Resource Locator; If the Uniform Resource Locator (URL) is confirmed to comply with the method, the first verification value is generated.

5. The method according to claim 1, characterized in that, The first request is initiated in response to the target service; the method further includes: If the client to be verified passes the verification, the target service is provided to the client to be verified.

6. The method according to claim 5, characterized in that, The first request is a User Datagram Protocol (UDP) request; Providing the target service to the client to be verified includes: The target service is provided to the client to be verified based on the UDP protocol.

7. The method according to claim 1, characterized in that, The method further includes: If it is determined that the second verification value was not generated based on the first verification value, the second request is ignored.

8. An electronic device, characterized in that, include: processor; Memory used to store processor-executable instructions; The processor implements the steps of the method as described in any one of claims 1-7 by running the executable instructions.

9. A computer-readable storage medium storing computer instructions thereon, characterized in that, When executed by the processor, this instruction implements the steps of the method as described in any one of claims 1-7.

10. A computer program, characterized in that, When the program is executed by the processor, it implements the steps of the method as described in any one of claims 1-7.

Images