A method, apparatus, and storage medium for handling vulnerabilities in a search service.

Abstract

This application discloses a method, apparatus, and storage medium for handling search service vulnerabilities. This application receives a search request and obtains the first search keyword of the current worker thread corresponding to the search request; checks whether the first search keyword is in a blocked word list; when the first search keyword is in the blocked word list, it does not respond to the search request; when the first search keyword is not in the blocked word list, it responds to the search request, obtains the third search keyword and the corresponding worker thread identifier for each worker thread running in the search service; writes the third search keyword into the first worker thread file corresponding to the worker thread identifier, and monitors the working status of the current worker thread; when an abnormal crash is detected in the current worker thread, it loads the third search keyword recorded in the first worker thread file into the blocked word list. By monitoring the service, it avoids repeated abnormal crashes and improves the efficiency of handling search service vulnerabilities.

Description

Technical Field

[0001] This invention relates to the field of computers, and more specifically to a method, apparatus, and storage medium for handling vulnerabilities in search services. Background Technology

[0002] As a background service, the search service needs to provide 24 / 7 uninterrupted search capabilities, returning corresponding search results based on the entered search keywords. The stability of a background service fundamentally relies on the robustness of its code and logic. When there are code defects or logical errors, the service often crashes or terminates due to reasons such as corrupted process memory or abnormal access to memory addresses, resulting in the inability to provide normal service. For search services, a significant portion of these problems are caused by defects resulting from specific search keywords.

[0003] The service defect protection mechanisms used in existing technologies mainly include: (1) monitoring abnormal crashes and automatically restarting the service after an abnormal crash; (2) improving the testing process before going live and providing gray-scale services during the change process; and (3) manually intervening by reserving switches in the code in advance, which requires foresight and has a lag. These mechanisms complement each other, but they cannot effectively prevent repeated abnormal crashes of the service, resulting in poor efficiency in searching for service vulnerabilities. Summary of the Invention

[0004] This application provides a method, apparatus, and storage medium for handling search service vulnerabilities, which can improve the efficiency of handling search service vulnerabilities.

[0005] This application provides a method for handling search service vulnerabilities, the method including:

[0006] Receive a search request and obtain the first search keyword for the current worker thread corresponding to the search request;

[0007] Check whether the first search keyword is in the blocked word list, which is generated by loading and recording the second search keyword corresponding to each worker thread when an abnormal crash occurs.

[0008] When the first search keyword is in the blocked word list, the search request is not responded to;

[0009] When the first search keyword is not in the blocked word list, respond to the search request and obtain the third search keyword and the corresponding worker thread identifier for each worker thread running in the search service;

[0010] Write the third search keyword of each worker thread into the first worker thread file corresponding to the worker thread identifier, and monitor the working status of the current worker thread;

[0011] When an abnormal crash is detected in the current working thread, the third search keyword of each working thread recorded in the first working thread file is loaded into the masking word table.

[0012] Accordingly, embodiments of this application also provide a device for handling search service vulnerabilities, including:

[0013] The receiving unit is used to receive search requests and obtain the first search keyword of the current working thread corresponding to the search request;

[0014] The checking unit is used to check whether the first search keyword is in the blocked word list, which is generated by loading the second search keyword corresponding to each worker thread when an abnormal crash occurs.

[0015] A blocking unit is configured to not respond to the search request when the first search keyword is in the blocked word list;

[0016] The response unit is configured to respond to the search request when the first search keyword is not in the blocked word list, and obtain the third search keyword and the corresponding worker thread identifier for each worker thread running in the search service;

[0017] The monitoring unit is used to write the third search keyword of each working thread into the first working thread file corresponding to the working thread identifier, and to monitor the working status of the current working thread.

[0018] The loading unit is used to load the third search keyword of each working thread recorded in the first working thread file into the masking word table when an abnormal crash is detected in the current working thread.

[0019] In one embodiment, the monitoring unit includes:

[0020] The recording subunit is used to write the third search keyword of each worker thread into the first worker thread file corresponding to the worker thread identifier in a blocking write and overwrite manner, and record the information digest value of the binary executable file of the current service process.

[0021] The first monitoring subunit is used to monitor the working status of the current working thread.

[0022] In one embodiment, the recording subunit includes:

[0023] The calculation subunit is used to calculate the MD5 value of the binary executable file of the current service process using the MD5 message digest algorithm, so as to obtain the message digest value of the binary executable file;

[0024] The write subunit is used to write the information digest value to the second worker thread file in a blocking write and overwrite manner.

[0025] In one embodiment, the loading unit includes:

[0026] The restart subunit is used to restart the service process;

[0027] The first loading subunit is used to load the third search keyword of each working thread recorded in the first working thread file into the masking word list when a second working thread file is detected to have the same information digest value as the information digest value of the current service process.

[0028] The clearing subunit is used to clear the masking word list, the first working thread file, and the second working thread file when a second working thread file containing a non-existent record's message digest value is detected to have the same message digest value as the current service process's message digest value.

[0029] In one embodiment, the loading unit includes:

[0030] A tagging subunit is used to tag the search request and restart the search request;

[0031] The second monitoring subunit is used to monitor the working status of the current working thread;

[0032] The second loading subunit is used to load the third search keyword of each working thread recorded in the first working thread file into the masking word table when the current working thread is detected to have crashed abnormally again.

[0033] In one embodiment, the receiving unit includes:

[0034] A sub-unit is created to start the search service. A recording sub-process is created through a branch function. The recording sub-process is used to receive the third search keyword to be recorded and the corresponding worker thread identifier sent by each worker thread in the search service.

[0035] The acquisition subunit is used to receive search requests and acquire the first search keyword of the current working thread corresponding to the search request.

[0036] In one embodiment, the monitoring unit includes:

[0037] The first writing sub-unit is used to write the third search keyword of each working thread to the first working thread file corresponding to the working thread identifier after the recording sub-process receives the third search keyword to be recorded and the corresponding working thread identifier sent by each working thread in the search service.

[0038] In one embodiment, the monitoring unit includes:

[0039] The second writing subunit is used to write the third search keyword of each working thread into the first working thread file corresponding to the working thread identifier through the working thread.

[0040] Accordingly, this application also provides a computer device, including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the program to implement the steps in any of the search service vulnerability handling methods provided in the embodiments of this application.

[0041] Furthermore, embodiments of this application also provide a readable storage medium storing a computer program thereon, wherein the computer program, when executed by a processor, implements the steps in any of the search service vulnerability handling methods provided in embodiments of this application.

[0042] This application embodiment receives a search request and obtains the first search keyword of the current worker thread corresponding to the search request; checks whether the first search keyword is in a blocked word list, which is generated by loading the second search keyword corresponding to each worker thread when an abnormal crash occurs; when the first search keyword is in the blocked word list, the search request is not responded to; when the first search keyword is not in the blocked word list, the search request is responded to, and the third search keyword and corresponding worker thread identifier of each worker thread running in the search service are obtained; the third search keyword of each worker thread is written into the first worker thread file corresponding to the worker thread identifier, and the working status of the current worker thread is monitored; when an abnormal crash is detected in the current worker thread, the third search keyword of each worker thread recorded in the first worker thread file is loaded into the blocked word list. In this way, by recording the third search keyword of each worker thread running in the search service and monitoring the service, when an abnormal crash occurs in the search service, the recorded third search keyword of each worker thread is loaded into the blocked word list, avoiding repeated abnormal crashes in the search service and improving the efficiency of handling search service vulnerabilities. Attached Figure Description

[0043] To more clearly illustrate the technical solutions in the embodiments of the present invention, the accompanying drawings used in the description of the embodiments will be briefly introduced below. Obviously, the accompanying drawings described below are only some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0044] Figure 1This is a schematic diagram of the implementation environment scenario for the search service vulnerability handling method provided in the embodiments of this application;

[0045] Figure 2 This is a flowchart illustrating the method for handling search service vulnerabilities provided in an embodiment of this application;

[0046] Figure 3 This is another flowchart illustrating the method for handling search service vulnerabilities provided in this application embodiment;

[0047] Figure 4 This is a flowchart illustrating the process of creating a child process to record a third search keyword using a branch function in the method for handling search service vulnerabilities provided in this application embodiment;

[0048] Figure 5 This is a schematic diagram of the structure of the device for handling search service vulnerabilities provided in this application embodiment;

[0049] Figure 6 This is a schematic diagram of the server structure provided in an embodiment of this application. Detailed Implementation

[0050] 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, and 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.

[0051] This application provides a method, apparatus, computer device, and storage medium for handling search service vulnerabilities. The apparatus for handling search service vulnerabilities can be integrated into a computer device, which can be a server or a terminal, etc.

[0052] refer to Figure 1 , Figure 1 This diagram illustrates an implementation environment scenario for the search service vulnerability handling method provided in this application, including server A and terminal B. Server A and terminal B, as well as the terminals themselves, can be connected via a communication network. This communication network includes wireless and wired networks, where the wireless network includes one or more combinations of wireless wide area networks (WANs), wireless local area networks (LANs), wireless metropolitan area networks (MANs), and wireless personal networks (PANs). The network includes network entities such as routers and gateways, which are not shown in the diagram. Terminal B can interact with server A through the communication network; for example, a user of terminal B can access server A to complete a search service.

[0053] Server A can be a standalone physical server, a server cluster or distributed system composed of multiple physical servers, or a cloud server providing basic cloud computing services such as cloud services, cloud databases, cloud computing, cloud functions, cloud storage, network services, cloud communication, middleware services, domain name services, security services, content delivery network (CDN) services, and big data and artificial intelligence platforms. Server A is primarily used to receive requests sent by terminal B and provide computing or application services. Specifically, this server can provide search services for users to perform search queries. Server A can receive search requests, obtain the first search keyword for the current worker thread corresponding to the search request; check if the first search keyword is in the masked word list; if the first search keyword is in the masked word list, it does not respond to the search request; if the first search keyword is not in the masked word list, it responds to the search request, obtains the third search keyword and corresponding worker thread identifier for each worker thread running in the search service; writes the third search keyword of each worker thread into the first worker thread file corresponding to the worker thread identifier, and monitors the working status of the current worker thread; when an abnormal crash is detected in the current worker thread, it loads the third search keyword of each worker thread recorded in the first worker thread file into the masked word list.

[0054] Terminal B can be an electronic device with search and query functions, such as a smartphone, tablet, laptop, desktop computer, smart speaker, or smartwatch, but it is not limited to these. Users can install various clients on the terminal, allowing them to input search keywords to perform searches.

[0055] It should be noted that, Figure 1 The schematic diagram illustrating the implementation environment of the search service vulnerability handling method is merely an example. The implementation environment of the virtual object switching method described in this application embodiment is intended to more clearly illustrate the technical solution of this application embodiment and does not constitute a limitation on the technical solution provided in this application embodiment.

[0056] The following sections provide detailed descriptions of each example. It should be noted that the order in which the embodiments are described is not intended to limit the preferred order of the embodiments.

[0057] Example 1

[0058] In this embodiment, the description will be from the perspective of a device for handling search service vulnerabilities. This device can be integrated into a server, such as a search server. The server can be a single server or a server cluster composed of multiple servers.

[0059] Please see Figure 2 , Figure 2 This is a flowchart illustrating a method for handling search service vulnerabilities provided in an embodiment of this application. The method for handling search service vulnerabilities includes:

[0060] In step 101, a search request is received, and the first search keyword of the current working thread corresponding to the search request is obtained.

[0061] In one embodiment, a user enters a first search keyword, which may be a search keyword such as "X-Xun Technology", "agent" or "Zhang San", thereby triggering a search request. The server generates a current working thread based on the search request. The current working thread contains the first search keyword, and the server can obtain the first search keyword from the current working thread.

[0062] The search service vulnerability handling method provided in this application embodiment can be applied to search services employing multi-process, multi-thread, and multi-coroutine service models. It should be noted that the search service vulnerability handling method provided in this application embodiment can also be applied to search services employing single-process, single-thread, and single-coroutine service models, and is also within the scope of protection of this application. However, such single-process, single-thread, and single-coroutine service models are generally not used for industrial-grade services. For clarity, the term "worker thread" is used in this application embodiment; a worker thread can be a process, thread, or coroutine.

[0063] The embodiments of this application are applicable to general search service scenarios where search keywords are used as input, such as the WeChat search scenario. When a user enters a search keyword, the search service system returns the corresponding search results to the client. The various subsystems in the search backend service system related to the search keyword, such as those performing retrieval, search keyword processing, error correction, and intent analysis, can all apply the search service vulnerability handling method provided in the embodiments of this application.

[0064] In step 102, it is checked whether the first search keyword is in the blocked word list, which is generated by loading the second search keyword corresponding to each worker thread when an abnormal crash occurs.

[0065] In one embodiment, a search request is received from a terminal, the first search keyword of the current working thread corresponding to the search request is obtained, and it is checked whether the first search keyword is in the blocked word list. If the first search keyword is found to be in the blocked word list, step 103 is executed; if the first search keyword is not found to be in the blocked word list, step 104 is executed.

[0066] In this context, "abnormal crash" refers to a service's abnormal exit or termination due to code defects or logical errors. When an operating system receives certain signals and an abnormal crash occurs, it writes the contents of the process's address space and other information about the process's state to a disk file called a kernel dump. This disk file typically contains the program's runtime memory, register states, stack pointer, memory management information, etc. When a user enters search keywords to trigger a search request, the entered keywords may cause code defects or logical errors, leading to an abnormal crash in the service process. This results in the server being unable to provide search services normally, and the user being unable to perform search queries. Therefore, this embodiment of the application can pre-create a masked keyword list, loading the search keywords being processed by each worker thread when the service process experiences an abnormal crash into the masked keyword list. When the server processes the current search keyword, it iterates through the masked keyword list. If the currently processed search keyword is found in the masked keyword list, the search requests corresponding to these search keywords can be directly blocked, avoiding the possibility of repeated abnormal crashes in the service process. The masked keyword list is generated by loading the search keywords that each worker thread was processing when the abnormal crash occurred. This masked keyword list can be a collection of search keywords.

[0067] In one embodiment, a user enters a first search keyword to trigger a search request. The server receives the search request and checks whether the first search keyword is in the blocked word list. If the first search keyword is not in the blocked word list, a third search keyword for each worker thread is recorded. When the search service crashes abnormally, the recorded third search keyword for each worker thread is loaded into the blocked word list. After a worker thread crashes abnormally, when the server receives another search request triggered by the user's first search keyword, it checks whether the first search keyword is in the blocked word list. If the first search keyword is in the blocked word list, the server does not respond to the search request.

[0068] In step 103, when the first search keyword is in the blocked word list, the search request is not responded to.

[0069] The server checks if the first search keyword is in the blocked term list. If it is, it means that the search request corresponding to that keyword previously caused a crash in the server process while being processed. Therefore, the server adds the first search keyword to the blocked term list. Consequently, if the server processes another search request triggered by the same first search keyword, it may cause another crash in the service process, resulting in the server being unable to provide normal search services. Therefore, the server does not respond to this search request to avoid repeated crashes in the search service.

[0070] In one embodiment, when the first search keyword is in the blocked word list and does not respond to the search request, a non-response prompt operation is performed in the client. For example, the user can be prompted that the search keyword entered this time may cause an error, so the search request operation will not respond.

[0071] In step 104, when the first search keyword is not in the blocked word list, the system responds to the search request and obtains the third search keyword and the corresponding worker thread identifier for each worker thread running in the search service.

[0072] The server checks whether the first search keyword is in the blocked term list. If the first search keyword is not in the blocked term list, it means that the first search keyword has not caused an abnormal crash in the server's historical service process, or that this is the first time the server is processing a search request triggered by the first search keyword. Therefore, in response to the search request, the server obtains the third search keyword and the corresponding worker thread identifier for each worker thread currently running in the search service.

[0073] In step 105, the third search keyword of each worker thread is written into the first worker thread file corresponding to the worker thread identifier, and the working status of the current worker thread is monitored.

[0074] Since search service crashes often occur because logic from other worker threads corrupts the memory of the current worker thread, it's crucial to record the third search keyword being processed by each worker thread at the time of the crash. This allows the recorded third search keyword to be added to the masked keyword list in real-time upon a crash. After responding to the search request, the server writes the third search keyword of each running worker thread to the first worker thread file corresponding to that thread's identifier, while simultaneously monitoring the current worker thread's status.

[0075] In one embodiment, a child process created using a fork function can write the third search keyword of each worker thread into the first worker thread file corresponding to that worker thread identifier. Specifically, the fork function creates a recording child process. After the recording child process receives the third search keyword to be recorded and the corresponding worker thread identifier sent by each worker thread in the search service, the server uses the recording child process to write the third search keyword of each worker thread into the first worker thread file corresponding to that worker thread identifier.

[0076] In one embodiment, the third search keyword of each worker thread can also be written to the first worker thread file corresponding to the worker thread identifier using a worker thread writing method. Specifically, when a worker thread receives a search request, it obtains the third search keyword and the corresponding worker thread identifier of each worker thread running in the search service, and the server writes the third search keyword of each worker thread to the first worker thread file corresponding to the worker thread identifier through the worker thread.

[0077] To more effectively record the third search keyword for each worker thread, when writing the third search keyword of each worker thread to the first worker thread file corresponding to that worker thread identifier, both blocking write and overwrite write methods can be used. Specifically, the overwrite write method can overwrite the search keywords recorded in the last successfully executed search service. The blocking write method avoids the problem of data loss caused by the operating system writing data to the first worker thread file in a non-blocking manner before it can actually locate the first worker thread file in the event of a search service crash.

[0078] In one embodiment, the third search keyword of each worker thread can be written to the same worker thread file, or the third search keyword of each worker thread can be written to multiple worker thread files, such as the first worker thread file corresponding to the worker thread identifier. To record more efficiently and avoid contention when multiple worker threads write to the same worker thread file, this embodiment uses the method of writing the third search keyword of each worker thread to the first worker thread file corresponding to the worker thread identifier.

[0079] In one embodiment, to determine whether the service process that experienced an abnormal crash has changed, the message digest value of the current service process's binary executable file can be recorded when the third search keyword of each worker thread is written into the first worker thread file corresponding to that worker thread identifier. The step of recording the message digest value of the current service process's binary executable file may include:

[0080] (1) The MD5 message digest algorithm is used to calculate the MD5 value of the binary executable file of the current service process to obtain the message digest value of the binary executable file;

[0081] (2) Write the message digest value to the second worker thread file in a blocking write and overwrite manner.

[0082] In one embodiment, when writing the message digest value to the second worker thread file using a blocking write and overwrite method, the message digest value can be either part of the filename of the second worker thread file or written into the content of the second worker thread file. An executable file refers to a file that can be loaded and executed by the operating system, including file formats such as .exe, .sys, and .com. The presentation of executable programs varies depending on the operating system environment.

[0083] In this embodiment, the worker thread file, the first worker thread file, and the second worker thread file all belong to the local worker thread file.

[0084] In step 106, when an abnormal crash is detected in the current working thread, the third search keyword of each working thread recorded in the first working thread file is loaded into the masking word table.

[0085] To prevent repeated crashes, the service process is automatically restarted when a crash is detected in the current worker thread. Specifically, when the server detects a crash in the current worker thread, it indicates the presence of a search keyword that triggered the crash. After the service process restarts, the third search keyword recorded in the first worker thread file for each worker thread is loaded into the keyword blocking table.

[0086] In one embodiment, to ensure that the keywords loaded into the masked keyword list are second search keywords that may cause the current service process to crash abnormally, the step of the server loading the third search keywords of each worker thread recorded in the first worker thread file into the masked keyword list when it detects an abnormal crash in the current worker thread may include:

[0087] (1) Restart the service process.

[0088] Specifically, when an abnormal crash is detected in the current working thread, the service process monitoring and restart mechanism detects that the service process does not exist and restarts the service process.

[0089] (2) When a second worker thread file is detected to have the same information digest value as the current service process, the third search keyword of each worker thread recorded in the first worker thread file is loaded into the mask word table.

[0090] (3) When a second working thread file with the same message digest value as the current service process is detected that does not contain any records, the mask word list, the first working thread file, and the second working thread file are cleared.

[0091] After the server restarts the service process, it checks the local worker thread files to determine if the service process that crashed abnormally has changed. When a second worker thread file is detected with the same message digest value as the current service process, the third search keyword for each worker thread recorded in the first worker thread file is loaded into the masking word list.

[0092] In one embodiment, when a second worker thread file is detected to have a recorded message digest value that is identical to the message digest value of the current service process, it indicates that the service process has been modified since the abnormal crash. At this point, the recorded search keywords are the third search keywords that each worker thread was processing when the service process crashed before the modification, and are no longer applicable to the current service process's masked keyword list. Therefore, the masked keyword list, the first worker thread file, and the second worker thread file are cleared. The service process modification could be caused by changes in code logic or fixing code issues.

[0093] In some implementations, to increase the effectiveness of blocking third search keywords, the step of loading the third search keywords of each worker thread recorded in the first worker thread file into the blocking keyword list may include:

[0094] (1.1) Mark the search request and restart the search request;

[0095] (1.2) Monitor the working status of the current worker thread;

[0096] (1.3) When the current working thread is detected to have crashed again, the third search keyword of each working thread recorded in the first working thread file is loaded into the masking word table.

[0097] Before loading the third search keyword of each worker thread recorded in the first worker thread file into the masked keyword list, the search request is marked, and then the search request is restarted. If the service crashes again, it indicates that the third search keyword did not cause the service process to crash due to accidental reasons. Therefore, the third search keyword of each worker thread is loaded into the masked keyword list. By marking the search request and restarting it, it is determined whether the third search keyword caused the service process to crash accidentally. This effectively avoids loading some search keywords that did not cause the service process to crash into the masked keyword list, improving the effectiveness of third search keyword masking and enhancing the server's search service capabilities.

[0098] In one implementation, if the worker thread does not crash abnormally, the search request service is normal, the search service business logic is executed, and the search results are returned to the client.

[0099] As described above, this embodiment of the application receives a search request and obtains the first search keyword of the current worker thread corresponding to the search request; checks whether the first search keyword is in the blocked word list, which is generated by loading the second search keyword corresponding to each worker thread when an abnormal crash occurs; when the first search keyword is in the blocked word list, the search request is not responded to; when the first search keyword is not in the blocked word list, the search request is responded to, and the third search keyword and the corresponding worker thread identifier of each worker thread running in the search service are obtained; the third search keyword of each worker thread is written into the first worker thread file corresponding to the worker thread identifier, and the working status of the current worker thread is monitored; when an abnormal crash is detected in the current worker thread, the third search keyword of each worker thread recorded in the first worker thread file is loaded into the blocked word list. In this way, by recording the third search keyword of each worker thread and monitoring the service, when an abnormal crash occurs in the service, the recorded third search keyword of each worker thread is loaded into the blocked word list, avoiding repeated abnormal crashes in the service and improving the efficiency of handling search service vulnerabilities.

[0100] Example 2

[0101] Based on the method described in Embodiment 1, the following examples will provide further detailed explanations.

[0102] In this embodiment, the method for handling search service vulnerabilities is implemented with the server as the execution entity, and a branch function is used to create a recording subprocess to record the third search keyword of each worker thread, which is then used for description.

[0103] Please see Figure 3 , Figure 3Another flowchart illustrating the method for handling search service vulnerabilities provided in this application embodiment. The method flow may include:

[0104] In step 201, the server starts the search service, creates a record subprocess through a branch function, receives search requests, and obtains the first search keyword of the current working thread corresponding to the search request.

[0105] Please refer to the following: Figure 4 , Figure 4 This diagram illustrates the process of initializing the service process, creating a recording subprocess via a branch function, and recording the third search keyword. The server starts the search service, initializes the service process, and simultaneously creates a recording subprocess via a branch function. This recording subprocess is a continuously looping process that receives the third search keyword to be recorded and its corresponding worker thread identifier from the server, generated based on the search request. When a user enters the first search keyword in the client, triggering a search request, the server receives the request and retrieves the first search keyword for the current worker thread corresponding to that request. This first search keyword can be a search term that the user has questions about or is interested in, such as "XX Company," "Li Si," or "Ninja," etc.

[0106] The embodiments of this application are applicable to general search service scenarios where search keywords are used as input, such as the WeChat search scenario, where users enter search keywords and the search service system returns the corresponding search results to the client.

[0107] In step 202, the server checks whether the first search keyword is in the blocked word list, which is generated by loading the second search keyword corresponding to each worker thread when an abnormal crash occurs.

[0108] Please continue reading for more details. Figure 4 The service process starts and initializes, loading the masked keyword list. Upon receiving a search request, the server retrieves the first search keyword for the current worker thread corresponding to that request and then checks if that first search keyword is in the masked keyword list. This masked keyword list is generated by loading and recording the second search keywords corresponding to each worker thread at the time of the abnormal crash. This masked keyword list can be a collection of the second search keywords processed by each worker thread that was running at the time of the historical abnormal crash.

[0109] In step 203, when the first search keyword is in the blocked term list, the server does not respond to the search request.

[0110] When the first search keyword is in the blocked term list, it indicates that the search request corresponding to the first search keyword has been processed by the server, causing an abnormal crash in the service process. The server will not respond to this search request to avoid a possible recurrence of the abnormal crash. In one implementation, when the server does not respond to the search request, it performs a corresponding prompting operation on the client, such as displaying a prompt box, reminding the user that the entered search keyword may cause a service exception. Therefore, this search request will not be responded to, and the server will wait for the next search request triggered by the user.

[0111] In step 204, when the first search keyword is not in the blocked word list, the server responds to the search request and obtains the third search keyword and the corresponding worker thread identifier for each worker thread running in the search service.

[0112] Please continue reading for more details. Figure 4 When the first search keyword is not in the blocked keyword list, it indicates that the first search keyword has not caused the service process to crash abnormally in the server's historical service process, or that the server is processing the search request triggered by the first search keyword for the first time, and it is unknown whether the first search keyword will cause the service process to crash abnormally. Therefore, the server responds to the search request and obtains the third search keyword and the corresponding worker thread identifier for each worker thread running in the search service. In one embodiment, inter-process communication (IPC) can be used to obtain the third search keyword and the corresponding worker thread identifier carried in the search request. In one embodiment, the IPC can use inter-process communication mechanisms such as local sockets, pipes, or message queues, all of which are within the scope of protection of this application.

[0113] In step 205, the server writes the third search keyword of each worker thread into the first worker thread file corresponding to the worker thread identifier in a blocking write and overwrite manner, records the information digest value of the binary executable file of the current service process, and monitors the working status of the current worker thread.

[0114] Please continue reading for more details. Figure 4After the server responds to the search request, it records the third search keyword for each worker thread in a blocking write and overwrite manner to the first worker thread file corresponding to the worker thread identifier through a child process. To determine if the service process has changed and to ensure that the second search keyword loaded into the masked keyword list is the one that might cause the current service process to crash, the information digest value of the current service process's binary executable file is recorded and the current worker thread's working status is monitored while writing the third search keyword for each worker thread to the first worker thread file. The overwrite method overwrites the search keywords recorded in the last successfully executed search service before writing the third search keyword for each worker thread to the first worker thread file. The blocking write method also avoids the problem of data loss caused by the operating system writing data to the buffer first when writing to the first worker thread file in a non-blocking manner, which might not have enough time to actually locate the first worker thread file when the search service crashes.

[0115] In one embodiment, the step of recording the message digest value of the binary executable file of the current service process may include:

[0116] (1) The MD5 message digest algorithm is used to calculate the MD5 value of the binary executable file of the current service process to obtain the message digest value of the binary executable file;

[0117] (2) Write the message digest value to the second worker thread file in a blocking write and overwrite manner.

[0118] In one embodiment, the information digest value can be written into the second working thread file as part of the file content of the second working thread file, or it can be written into the second working thread file as part of the filename of the second working thread file.

[0119] In step 206, when the server detects an abnormal crash in the current worker thread, it restarts the service process.

[0120] Specifically, when an abnormal crash is detected in the current working thread, the server's pre-configured service process monitoring and restart mechanism detects that the service process is not present and restarts the service process.

[0121] In step 207, when a second worker thread file is detected to have a record digest value that is the same as the digest value of the current service process, the server marks the search request.

[0122] After restarting the service process, the server uses the MD5 message digest algorithm to calculate the MD5 value of the current service process's binary executable file to obtain the message digest value of the current service process. Then, it checks the local worker thread files. When a second worker thread file with the same message digest value as the current service process is detected, it indicates that the service process has not changed after the abnormal crash, and the server marks the search request.

[0123] The local worker thread files include the first worker thread file and the second worker thread file.

[0124] In step 208, the server restarts the search request and monitors the current working thread's status.

[0125] After marking the search request that crashed abnormally, the server restarts the search request and monitors the working status of the current worker thread.

[0126] In step 209, when the current worker thread is detected to have crashed abnormally again, the server loads the third search keyword of each worker thread recorded in the first worker thread file into the mask word table.

[0127] When a worker thread is detected to crash again, it indicates that the crash may not be accidental. To ensure the stability of the search service, the server loads the third search keyword for each worker thread recorded in the first worker thread file into the masked word list. In one embodiment, when the server encounters a search request triggered by the same third search keyword again, it checks the masked word list. If the third search keyword is found in the masked word list, the server does not respond to the search request, thus preventing repeated crashes of the search service.

[0128] In step 210, when a second worker thread file with a message digest value that does not contain any records and is identical to the message digest value of the current service process is detected, the server clears the mask word list, the first worker thread file, and the second worker thread file.

[0129] When a second worker thread file is detected that does not contain a record with the same message digest value as the current service process, it indicates that the service process may have changed after the abnormal crash due to code logic modification or code problem fixing. In this case, the recorded search keyword is the third search keyword that each worker thread was processing when the service process crashed abnormally before the change, and it is no longer applicable to the masked word list loaded into the current service process. Therefore, the masked word list, the first worker thread file, and the second worker thread file are cleared.

[0130] As can be seen from the above, in this embodiment, the server starts a search service, creates a record subprocess through a branch function, receives a search request, and obtains the first search keyword of the current worker thread corresponding to the search request; it checks whether the first search keyword is in the masked word list, which is generated by loading the second search keyword corresponding to each worker thread when the record crashes abnormally; when the first search keyword is in the masked word list, the server does not respond to the search request; when the first search keyword is not in the masked word list, the server responds to the search request, obtains the third search keyword of each worker thread running in the search service and the corresponding worker thread identifier; the server writes the third search keyword of each worker thread to the first worker thread file corresponding to the worker thread identifier in a blocking write and overwrite write manner, and records the current... The server monitors the current worker thread's status by analyzing the digest value of the binary executable file of the service process. When the server detects an abnormal crash in the current worker thread, it restarts the service process. If a second worker thread file with the same digest value as the current service process is detected, the server marks the search request. The server restarts the search request and monitors the current worker thread's status. If the current worker thread crashes again, the server loads the third search keyword recorded in the first worker thread file into a masked word list. If no second worker thread file with the same digest value as the current service process is detected, the server clears the masked word list, the first worker thread file, and the second worker thread file. In this way, a recording subprocess is created through a branch function. This subprocess records the third search keyword of each worker thread and monitors the service process. When the service crashes abnormally, the recorded third search keyword of each worker thread is loaded into the masked word list, preventing repeated abnormal crashes and improving the efficiency of handling service vulnerabilities.

[0131] Example 3

[0132] To facilitate better implementation of the search service vulnerability handling method provided in this application embodiment, this application embodiment also provides an apparatus based on the above-described search service vulnerability handling method, which can be integrated into a server. The meanings of the terms used are the same as in the above-described search service vulnerability handling method, and specific implementation details can be found in the descriptions in the above embodiments.

[0133] Please see Figure 5 , Figure 5 This is a schematic diagram of the structure of a search service vulnerability processing device provided in an embodiment of this application. The search service vulnerability processing device may include a receiving unit 301, an inspection unit 302, a shielding unit 303, a response unit 304, a monitoring unit 305, and a loading unit 306.

[0134] The receiving unit 301 is used to receive a search request and obtain the first search keyword of the current working thread corresponding to the search request.

[0135] The checking unit 302 is used to check whether the first search keyword is in the blocked word list. The blocked word list is generated by loading the second search keyword corresponding to each worker thread when an abnormal crash occurs.

[0136] The blocking unit 303 is used to not respond to the search request when the first search keyword is in the blocked term list;

[0137] The response unit 304 is used to respond to the search request when the first search keyword is not in the blocked word list, and to obtain the third search keyword and the corresponding worker thread identifier for each worker thread running in the search service.

[0138] The monitoring unit 305 is used to write the third search keyword of each working thread into the first working thread file corresponding to the working thread identifier, and to monitor the working status of the current working thread.

[0139] The loading unit 306 is used to load the third search keyword of each working thread recorded in the first working thread file into the masking word table when an abnormal crash is detected in the current working thread.

[0140] In one embodiment, the monitoring unit 305 includes:

[0141] The recording subunit is used to write the third search keyword of each worker thread into the first worker thread file corresponding to the worker thread identifier in a blocking write and overwrite manner, and to record the information digest value of the binary executable file of the current service process.

[0142] The first monitoring subunit is used to monitor the working status of the current working thread.

[0143] In one embodiment, the recording subunit includes:

[0144] The calculation subunit is used to calculate the MD5 value of the binary executable file of the current service process using the MD5 message digest algorithm, so as to obtain the message digest value of the binary executable file;

[0145] Write sub-unit, used to write the message digest value to the second worker thread file in a blocking write and overwrite manner.

[0146] In one embodiment, the loading unit 306 includes:

[0147] The restart subunit is used to restart the service process;

[0148] The first loading subunit is used to load the third search keyword of each working thread recorded in the first working thread file into the mask word table when a second working thread file is detected to have a recorded message digest value that is the same as the message digest value of the current service process.

[0149] The clear subunit is used to clear the masking word list, the first working thread file, and the second working thread file when a second working thread file containing a non-existent record's message digest value is detected to have the same message digest value as the current service process.

[0150] In one embodiment, the loading unit 306 includes:

[0151] The tagging subunit is used to tag the search request and restart the search request;

[0152] The second monitoring subunit is used to monitor the working status of the current working thread;

[0153] The second loading subunit is used to load the third search keyword of each worker thread recorded in the first worker thread file into the masking word table when the current worker thread is detected to have crashed abnormally again.

[0154] In one embodiment, the receiving unit 301 includes:

[0155] Create a sub-unit to start the search service. Create a recording sub-process through a branch function. This recording sub-process is used to receive the third search keyword to be recorded and the corresponding worker thread identifier sent by each worker thread in the search service.

[0156] The sub-unit is used to receive search requests and retrieve the first search keyword of the current worker thread corresponding to the search request.

[0157] In one embodiment, the monitoring unit 305 includes:

[0158] The first writing sub-unit is used to write the third search keyword of each working thread to the first working thread file corresponding to the working thread identifier after the recording sub-process receives the third search keyword to be recorded and the corresponding working thread identifier sent by each working thread running in the search service.

[0159] In one embodiment, the monitoring unit 305 includes:

[0160] The second writing subunit is used to write the third search keyword of each worker thread into the first worker thread file corresponding to the worker thread identifier through the worker thread.

[0161] The specific implementation of each of the above units can be found in the previous embodiments, and will not be repeated here.

[0162] As can be seen from the above, in this embodiment of the application, the receiving unit 301 receives a search request and obtains the first search keyword of the current working thread corresponding to the search request; the checking unit 302 checks whether the first search keyword is in the blocked word list, which is generated by loading the second search keyword corresponding to each working thread when an abnormal crash occurs; when the first search keyword is in the blocked word list, the blocking unit 303 does not respond to the search request; when the first search keyword is not in the blocked word list, the responding unit 304 responds to the search request and obtains the third search keyword of each working thread running in the search service and the corresponding working thread identifier; the monitoring unit 305 writes the third search keyword of each working thread into the first working thread file corresponding to the working thread identifier and monitors the working status of the current working thread; when the loading unit 306 detects that the current working thread has an abnormal crash, it loads the third search keyword of each working thread recorded in the first working thread file into the blocked word list. In this way, by recording the third search keyword of each worker thread and monitoring the service, when the service crashes abnormally, the recorded third search keyword of each worker thread is loaded into the masked word list, which avoids repeated abnormal crashes of the service and improves the efficiency of handling search service vulnerabilities.

[0163] Example 4

[0164] This invention also provides a server, such as... Figure 6 As shown, it illustrates a schematic diagram of the server structure involved in an embodiment of the present invention, specifically:

[0165] The server may include components such as a processor 401 with one or more processing cores, a memory 402 with one or more computer-readable storage media, a power supply 403, and an input unit 404. Those skilled in the art will understand that... Figure 5 The server architecture shown does not constitute a limitation on the server and may include more or fewer components than illustrated, or combine certain components, or have different component arrangements. Wherein:

[0166] The processor 401 is the control center of the server, connecting various parts of the server through various interfaces and lines. It performs various server functions and processes data by running or executing software programs and / or modules stored in the memory 402, and by calling data stored in the memory 402, thereby providing overall monitoring of the server. Optionally, the processor 401 may include one or more processing cores; preferably, the processor 401 may integrate an application processor and a modem processor, wherein the application processor mainly handles the operating system, user interface, and applications, and the modem processor mainly handles wireless communication. It is understood that the modem processor may not be integrated into the processor 401.

[0167] The memory 402 can be used to store software programs and modules. The processor 401 executes various functional applications and data processing by running the software programs and modules stored in the memory 402. The memory 402 may mainly include a program storage area and a data storage area. The program storage area may store the operating system, at least one application program required for a function (such as sound playback function, image playback function, etc.), etc.; the data storage area may store data created according to the use of the server, etc. In addition, the memory 402 may include high-speed random access memory, and may also include non-volatile memory, such as at least one disk storage device, flash memory device, or other volatile solid-state storage device. Accordingly, the memory 402 may also include a memory controller to provide the processor 401 with access to the memory 402.

[0168] The server also includes a power supply 403 that supplies power to the various components. Preferably, the power supply 403 can be logically connected to the processor 401 through a power management system, thereby enabling functions such as charging, discharging, and power consumption management through the power management system. The power supply 403 may also include one or more DC or AC power supplies, recharging systems, power fault detection circuits, power converters or inverters, power status indicators, and other arbitrary components.

[0169] The server may also include an input unit 404, which can be used to receive input numeric or character information, and generate keyboard, mouse, joystick, optical or trackball signal inputs related to user settings and function control.

[0170] Although not shown, the server may also include a display unit, etc., which will not be described in detail here. Specifically, in this embodiment, the processor 401 in the server loads the executable files corresponding to the processes of one or more applications into the memory 402 according to the following instructions, and the processor 401 runs the applications stored in the memory 402 to realize various functions, as follows:

[0171] The system receives a search request and retrieves the first search keyword for the current worker thread corresponding to the search request. It then checks if the first search keyword is in the masked word list, which is generated by loading the second search keyword corresponding to each worker thread when an abnormal crash occurs. If the first search keyword is in the masked word list, the system does not respond to the search request. If the first search keyword is not in the masked word list, the system responds to the search request, retrieves the third search keyword for each worker thread currently running in the search service, and retrieves the corresponding worker thread identifier. The system writes the third search keyword for each worker thread to the first worker thread file corresponding to the worker thread identifier and monitors the current worker thread's working status. When an abnormal crash is detected in the current worker thread, the system loads the third search keyword for each worker thread recorded in the first worker thread file into the masked word list.

[0172] It should be noted that the server provided in this application embodiment and the method for handling search service vulnerabilities applicable to servers in the above embodiments belong to the same concept. The specific implementation process can be found in the above method embodiments, and will not be repeated here.

[0173] Example 5

[0174] Those skilled in the art will understand that all or part of the steps in the various methods of the above embodiments can be performed by instructions, or by instructions controlling related hardware. These instructions can be stored in a computer-readable storage medium and loaded and executed by a processor.

[0175] To this end, embodiments of the present invention provide a storage medium storing a plurality of instructions that can be loaded by a processor to execute steps in any of the search service vulnerability handling methods provided in the embodiments of the present invention. For example, the instructions can execute the following steps:

[0176] The system receives a search request and retrieves the first search keyword for the current worker thread corresponding to the search request. It then checks if the first search keyword is in the masked word list, which is generated by loading the second search keyword corresponding to each worker thread when an abnormal crash occurs. If the first search keyword is in the masked word list, the system does not respond to the search request. If the first search keyword is not in the masked word list, the system responds to the search request, retrieves the third search keyword for each worker thread currently running in the search service, and retrieves the corresponding worker thread identifier. The system writes the third search keyword for each worker thread to the first worker thread file corresponding to the worker thread identifier and monitors the current worker thread's working status. When an abnormal crash is detected in the current worker thread, the system loads the third search keyword for each worker thread recorded in the first worker thread file into the masked word list.

[0177] According to one aspect of this application, a computer program product or computer program is provided, comprising computer instructions stored in a computer-readable storage medium. A processor of a computer device reads the computer instructions from the computer-readable storage medium and executes the computer instructions, causing the computer device to perform the methods provided in the various optional implementations of the above embodiments.

[0178] For details on the implementation of each of the above operations, please refer to the previous examples, which will not be repeated here.

[0179] The storage medium may include: read-only memory (ROM), random access memory (RAM), disk or optical disk, etc.

[0180] Since the instructions stored in the storage medium can execute the steps in any of the search service vulnerability handling methods provided in the embodiments of the present invention, the beneficial effects that any of the search service vulnerability handling methods provided in the embodiments of the present invention can achieve can be realized. For details, please refer to the previous embodiments, which will not be repeated here.

[0181] The above provides a detailed description of a method, apparatus, and system for handling search service vulnerabilities provided by embodiments of the present invention. Specific examples have been used to illustrate the principles and implementation methods of the present invention. The descriptions of the above embodiments are only for the purpose of helping to understand the method and core ideas of the present invention. At the same time, for those skilled in the art, there will be changes in specific implementation methods and application scope based on the ideas of the present invention. Therefore, the content of this specification should not be construed as a limitation of the present invention.

Claims

1. A method for handling vulnerabilities in a search service, characterized in that, include: Start the search service, receive search requests, and obtain the first search keyword of the current working thread corresponding to the search request; Check whether the first search keyword is in the blocked word list, which is generated by loading and recording the second search keyword corresponding to each worker thread when an abnormal crash occurs. When the first search keyword is in the blocked word list, the search request is not responded to; When the first search keyword is not in the blocked word list, respond to the search request and obtain the third search keyword and the corresponding worker thread identifier of each worker thread running in the search service through the recording subprocess; Write the third search keyword of each worker thread into the first worker thread file corresponding to the worker thread identifier, record the information digest value of the binary executable file of the current service process, and monitor the working status of the current worker thread. When an abnormal crash is detected in the current working thread, the service process is restarted. The abnormal crash refers to the abnormal exit or termination of the service caused by code defects or logical errors. When a second worker thread file is detected to have the same message digest value as the current service process, the third search keyword of each worker thread recorded in the first worker thread file is loaded into the masked word list; When a second worker thread file is detected that has no record digest value and has the same digest value as the current service process, the masking word list, the first worker thread file, and the second worker thread file are cleared.

2. The method for handling search service vulnerabilities as described in claim 1, characterized in that, The step of writing the third search keyword of each worker thread into the first worker thread file corresponding to the worker thread identifier includes: The third search keyword of each worker thread is written to the first worker thread file corresponding to the worker thread identifier in a blocking write and overwrite write manner.

3. The method for handling search service vulnerabilities as described in claim 1, characterized in that, The information digest value of the binary executable file of the current service process is recorded, including: The MD5 message digest algorithm is used to calculate the MD5 value of the binary executable file of the current service process to obtain the message digest value of the binary executable file; The message digest value is written to the second worker thread file in a blocking write and overwrite manner.

4. The method for handling search service vulnerabilities as described in claim 1, characterized in that, The step of loading the third search keyword of each worker thread recorded in the first worker thread file into the masked word table includes: The search request is marked, and the search request is restarted; Monitor the working status of the current worker thread; When the current working thread is detected to have crashed abnormally again, the third search keyword of each working thread recorded in the first working thread file is loaded into the masking word table.

5. The method for handling search service vulnerabilities as described in claim 1, characterized in that, The step of receiving a search request and obtaining the first search keyword of the current working thread corresponding to the search request includes: A recording subprocess is created through a branch function. The recording subprocess is used to receive the third search keyword to be recorded and the corresponding worker thread identifier sent by each worker thread in the search service. Receive a search request and obtain the first search keyword of the current working thread corresponding to the search request.

6. The method for handling search service vulnerabilities as described in claim 5, characterized in that, The step of writing the third search keyword of each worker thread into the first worker thread file corresponding to the worker thread identifier includes: After the recording subprocess receives the third search keyword to be recorded and the corresponding worker thread identifier sent by each worker thread in the search service, the recording subprocess writes the third search keyword of each worker thread into the first worker thread file corresponding to the worker thread identifier.

7. The method for handling search service vulnerabilities as described in claim 1, characterized in that, The step of writing the third search keyword of each worker thread into the first worker thread file corresponding to the worker thread identifier includes: The third search keyword of each worker thread is written into the first worker thread file corresponding to the worker thread identifier.

8. A device for handling vulnerabilities in a search service, characterized in that, include: The receiving unit is used to start the search service, receive the search request, and obtain the first search keyword of the current working thread corresponding to the search request. The checking unit is used to check whether the first search keyword is in the blocked word list, which is generated by loading the second search keyword corresponding to each worker thread when an abnormal crash occurs. A blocking unit is configured to not respond to the search request when the first search keyword is in the blocked word list; The response unit is used to respond to the search request when the first search keyword is not in the masked word list, and to obtain the third search keyword and the corresponding worker thread identifier of each worker thread running in the search service through the recording subprocess. The monitoring unit is used to write the third search keyword of each working thread into the first working thread file corresponding to the working thread identifier, record the information digest value of the binary executable file of the current service process, and monitor the working status of the current working thread. The loading unit is used to restart the service process when an abnormal crash is detected in the current worker thread. The abnormal crash refers to the abnormal exit or termination of the service due to code defects or logical errors. Then, when a second worker thread file with the same information digest value as the current service process is detected, the third search keyword of each worker thread recorded in the first worker thread file is loaded into the masking word table. When a second worker thread file with the same information digest value as the current service process is detected, the masking word table, the first worker thread file, and the second worker thread file are cleared.

9. A storage medium, characterized in that, The storage medium stores a plurality of instructions adapted for loading by a processor to execute the steps of the method for handling search service vulnerabilities as described in any one of claims 1 to 7.

Images