Redis cache source-return-free hidden danger detection method and device, storage medium and computer equipment
Patent Information
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2025-12-17
- Publication Date
- 2026-04-10
Smart Images
Figure CN121833772A_ABST
Abstract
Description
Technical Field
[0001] This application relates to the field of computer technology, and in particular to a method, apparatus, storage medium, and computer equipment for detecting the risk of Redis cache not returning to the origin server. Background Technology
[0002] In modern high-concurrency distributed systems, high-performance caches such as Redis are widely used to improve application performance and reduce the load on backend databases. Typically, an application first queries Redis to retrieve data; if the cache misses, it queries the backend database from the origin server and writes the result back to Redis to ensure a high hit rate for subsequent requests. However, during complex business development and iteration, developers often overlook cache invalidation handling. If Redis becomes invalid due to cache expiration, service restart, or accidental data cleanup, and the application has not correctly implemented the origin server query logic, requests will fail to retrieve data, leading to empty pages or empty data, severely impacting user experience and potentially causing business interruption. These hidden dangers are difficult to detect when operating smoothly in a production environment, usually only becoming apparent when a real failure occurs, resulting in high repair costs and significant losses.
[0003] Existing methods primarily rely on manually constructing cache invalidation scenarios for testing, but this approach has significant limitations. Manual testing has low coverage; testers cannot comprehensively simulate all possible cache invalidation situations, leading to some cache non-originating point issues going undetected. Testing efficiency is low; constructing invalidation scenarios and verifying originating point logic depend on manual operations, which are time-consuming and highly repetitive. It is difficult to simulate complex online request traffic; manual testing struggles to reproduce the multi-user, high-concurrency, and complex business request scenarios of a real production environment, making it difficult to expose potential problems early. Therefore, existing methods lack a solution capable of efficiently identifying cache non-originating point vulnerabilities. Summary of the Invention
[0004] The purpose of this application is to at least address one of the aforementioned technical deficiencies, particularly the lack of an efficient solution for identifying cached non-originating vulnerabilities in existing methods.
[0005] Firstly, this application provides a method for detecting the potential for Redis cache to fail to originate from the source, the method including:
[0006] Record request traffic while the test environment is running normally, and generate a unique trace identifier for each Redis cache query request;
[0007] When each Redis cache query request is received, the query key in each Redis cache query request is modified so that each Redis cache query request returns a null value;
[0008] Obtain the link behavior information of the Redis cache query request corresponding to each tracking identifier;
[0009] If, based on the behavior information of each link, it is determined that there is a Redis cache query request that returns without any data being retrieved from the origin, then high-risk information is generated to indicate that there is no data retrieval from the origin.
[0010] In one embodiment, the step of modifying the query key in each Redis cache query request upon receipt of each Redis cache query request includes:
[0011] Upon receiving each Redis cache query request, the target method name of the target class name in each Redis cache query request is intercepted, the query key in each Redis cache query request is obtained, and the query key is replaced with a non-existent random key, and the modified Redis cache query request is executed.
[0012] In one embodiment, the step of obtaining the link behavior information of each tracking identifier corresponding to the Redis cache query request includes:
[0013] Access behaviors are intercepted by probes at cache access locations, database access locations, and external interface call locations. Based on the tracking identifiers carried in the access behaviors, access behaviors belonging to the same tracking identifier are aggregated to obtain the link behavior information of the Redis cache query request corresponding to each tracking identifier.
[0014] In one embodiment, the process of determining whether a Redis cache query request exists but does not result in a data retrieval operation after being returned, based on the behavior information of each link, includes:
[0015] For each Redis cache query request, if no database query behavior, external interface request behavior, or cache write behavior associated with the same tracing identifier is detected in the corresponding link behavior information after the Redis cache query request returns a null value, it is determined that the Redis cache query request did not perform a data retrieval operation.
[0016] In one embodiment, the method further includes:
[0017] Obtain the response body of the corresponding interface for each Redis cache query request, and for each response body, if the response body has specific response body characteristics, generate risk-free information to indicate that no origin server is required.
[0018] In one embodiment, the method further includes:
[0019] For each query key in a Redis cache query request, if the query key has specific cache key characteristics, risk-free information is generated to indicate that no origin server access is required.
[0020] Secondly, this application provides a cache-free origin vulnerability detection device, the device comprising:
[0021] The trace identifier generation module is used to record request traffic while the test environment is running normally and generate a unique trace identifier for each Redis cache query request;
[0022] The query key modification module is used to modify the query key in each Redis cache query request when it is received, so that each Redis cache query request returns a null value;
[0023] The link behavior information acquisition module is used to acquire the link behavior information of the Redis cache query request corresponding to each tracking identifier;
[0024] The module for generating high-risk information about no data return to the origin is used to generate high-risk information indicating no data return to the origin if, based on the behavior information of each link, it is determined that there is a Redis cache query request that returns without any data return to the origin.
[0025] In one embodiment, the query key modification module includes:
[0026] The query key modification unit is used to intercept the target method name of the target class name in each Redis cache query request when it is received, obtain the query key in each Redis cache query request, replace the query key with a non-existent random key, and continue to execute the modified Redis cache query request.
[0027] Thirdly, this application provides a storage medium storing computer-readable instructions, which, when executed by one or more processors, cause the one or more processors to perform the steps of any of the Redis cache no-origin vulnerability detection methods described in the above embodiments.
[0028] Fourthly, this application provides a computer device, including: one or more processors, and a memory;
[0029] The memory stores computer-readable instructions, which, when executed by one or more processors, perform the steps of any of the Redis cache no-origin vulnerability detection methods described in the above embodiments.
[0030] As can be seen from the above technical solutions, the embodiments of this application have the following advantages:
[0031] This application provides a method, apparatus, storage medium, and computer equipment for detecting Redis cache non-originating point vulnerabilities. By recording request traffic during normal operation in a test environment and generating a unique tracer for each Redis cache query request, it achieves automatic tracking and monitoring of the entire cache access process. When processing each Redis cache query request, the query key is adjusted to return a null value, thereby automatically acquiring the link behavior information for each request. By analyzing the link behavior information, it can accurately determine which Redis cache query requests did not perform an originating point operation after returning the result, and generate corresponding high-risk non-originating point vulnerabilities. Compared with existing methods that rely on manually constructing cache failure scenarios, this method requires no manual intervention, can efficiently cover complex business scenarios and fault scenarios, realistically reproduces abnormal online traffic behavior, and thus systematically identifies cache non-originating point vulnerabilities. This method significantly improves detection coverage and accuracy, helps to discover potential risks in advance, ensures system stability and reliability, and solves the problem of difficulty in efficiently identifying cache non-originating point vulnerabilities in existing technologies. Attached Figure Description
[0032] To more clearly illustrate the technical solutions in the embodiments of this application or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.
[0033] Figure 1 A flowchart illustrating the Redis cache no-origin vulnerability detection method provided in this application embodiment;
[0034] Figure 2 This is a schematic diagram of the Redis cache no-origin vulnerability detection device provided in the embodiments of this application;
[0035] Figure 3 This is a schematic diagram of the internal structure of a computer device provided in an embodiment of this application. Detailed Implementation
[0036] 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.
[0037] This application provides a method for detecting the potential issue of Redis cache not returning to the origin server. The following embodiments illustrate this method using a computer device as an example. It is understood that the computer device can be any device with data processing capabilities, including but not limited to a single server, server cluster, personal laptop, desktop computer, etc. Figure 1 As shown, the method may include the following steps:
[0038] S101: Records request traffic while the test environment is running normally and generates a unique trace identifier for each Redis cache query request.
[0039] Request traffic refers to the actual sequence of client requests occurring within the application, including cache query requests and corresponding business requests. It accurately reflects the application's access characteristics and business logic in a production environment. A Redis cache query request is a data read operation initiated against the Redis cache to determine if the required data exists in the cache. The test environment is a data processing environment that is functionally similar to but independent of the production environment, used to securely simulate and verify application behavior. The tracing identifier is a unique tag generated for each Redis cache query request, used to associate the request's behavior and processing results throughout the entire access chain, enabling tracking and analysis of the entire request process.
[0040] In practice, request traffic can be acquired by deploying traffic collection tools in the production environment. These tools monitor the communication between the client and the cache, recording request and response data in chronological order to create replayable log files or data sequences. During recording, key request characteristics, including request timestamps, request sources, query keys, and other relevant business parameters, can be retained to ensure complete recording of real access behavior in the test environment. This provides foundational data support for reproducing abnormal online traffic through fault injection.
[0041] When recording request traffic in the test environment, a unique trace identifier is generated for each Redis cache query request received. The trace identifier can be generated based on a combination of the request's timestamp, client identifier, query key, and random number or sequence number, ensuring that each Redis cache query request is unique and traceable throughout the test traffic. The generated trace identifier is then associated with key feature information of the request, maintaining the request order and chain relationship, providing a complete data foundation for subsequent analysis of each request's behavior in the cache access chain.
[0042] By recording request traffic and generating trace identifiers during normal operation in the test environment, the cache access chain and request characteristics can be accurately depicted. This provides a reliable data foundation for reproducing online anomalies and covering abnormal business processes under fault injection conditions. Generating a unique trace identifier for each Redis cache query request accurately links the request's behavior and processing results throughout the entire access chain, avoiding untraceable behavior issues caused by request obfuscation or data loss. This approach enables independent and controllable monitoring of the entire process of each Redis cache query request, providing a complete and reliable data foundation for subsequent analysis of cache origin pull situations. This improves detection coverage and accuracy, helps identify potential cache non-origin pull risks early, and ensures application stability and reliability.
[0043] S102: When each Redis cache query request is received, modify the query key in each Redis cache query request so that each Redis cache query request returns a null value.
[0044] In Redis cache query requests, the query key is a key field used to uniquely identify the requested data. The query key allows you to locate the corresponding data entry in the cache. Returning a null value means the cache system returns an empty response when it receives the query request but cannot find the corresponding data entry.
[0045] In practical implementation, when a Redis cache query request is received, the query key in the request can be processed to point to a data entry that does not exist in the cache, thus ensuring that the caching system returns a null value response. Processing methods can include adding specific identifiers, random strings, or sequence numbers before or after the original query key, or encrypting or hashing the query key to generate a unique query key-value pair that does not exist in the cache. This process can be dynamically generated based on the timestamp, client identifier, or business parameters of each request, ensuring that the modified query key for each Redis cache query request is unique and will not be repeated throughout the entire test traffic, thereby avoiding conflicts or overwriting between different requests.
[0046] After modifying the query key, the processed request can be sent to the caching system. When the caching system processes the request, it will return a null response because the corresponding data entry does not exist in the cache. Meanwhile, other characteristics of the Redis cache query request, including the original query key, request source, request time, and associated tracking identifiers, are preserved and recorded in internal data structures or logs to accurately track the processing and behavior of each request in subsequent analysis.
[0047] By modifying the query key of each Redis cache query request to return a null value, cache miss scenarios can be automatically reproduced in the test environment, thereby obtaining complete chain behavior information for each request under cache miss conditions. This approach can accurately simulate the subsequent origin pull behavior that may be caused by cache invalidation, providing a reliable data foundation for subsequent analysis of whether there are potential cache misses. By automatically generating null responses, cache access situations under different query keys and various business scenarios can be systematically covered, improving the coverage and accuracy of detection, helping to discover potential risks in advance, and ensuring application stability and reliability.
[0048] S103: Obtain the link behavior information of the Redis cache query request corresponding to each tracking identifier.
[0049] Link behavior information refers to the records of access and processing related to Redis cache query requests, including request sending time, cache response content, cache hit or miss status, whether a back-to-origin operation occurred, and related business processing information. This information can completely describe the processing trajectory of the request in the system.
[0050] In practical implementation, the tracking identifier for each Redis cache query request can be queried and matched to extract the request processing information corresponding to that identifier from internal data structures or log records. Processing methods may include reading the request's timestamp, query key, cache response status, and cache origin retrieval operation record, combining this information to generate complete chain behavior information. During extraction, the behavior information recorded in the data structure can be associated with its respective tracking identifier according to the request sequence, enabling full-process behavior tracking and analysis for each request. In this way, cache access and origin retrieval behaviors can be systematically collected and recorded, ensuring that the processing of each request can be accurately tracked and reproduced in the test environment.
[0051] By acquiring the link behavior information of each Redis cache query request corresponding to a tracking identifier, the processing trajectory of each request during cache access can be completely recorded, including request sending, cache response status, and origin server access operations, thus accurately reflecting the actual behavior of cache access. This approach ensures that the processing of each request is independent and traceable, providing a reliable data foundation for subsequent assessment of whether there are potential origin server access vulnerabilities in the cache, improving detection coverage and accuracy, helping to identify potential risks in advance, and ensuring the stability and reliability of application systems.
[0052] S104: If, based on the behavior information of each link, it is determined that there is a Redis cache query request that returns without a data return operation, then high-risk information is generated to indicate that there is no data return operation.
[0053] In this context, "origin pull" refers to the application's action of retrieving and returning data from a backend database or other data source when a cache miss or cached data becomes invalid. High-risk information indicating no origin pull refers to warning messages generated by analyzing link behavior information, indicating that a Redis cache query request did not perform an origin pull after returning a response, potentially leading to data loss or business anomalies.
[0054] In the implementation process, we can first use the tracking identifier of each Redis cache query request to accurately locate all processing records corresponding to the request from the recorded link behavior information, including cache response status, cache hit or miss indicators, origin retrieval operation time, and related business processing information. When comparing the cache response result with subsequent data retrieval behavior, we can determine the origin retrieval situation by analyzing whether the content returned by the request contains write operations to Redis and whether there are operations to retrieve data from the backend database or other data sources. If it is found that the Redis cache query request does not perform an origin retrieval operation after returning the response, and there is no write operation to Redis, it can be determined that the request has no potential origin retrieval risk.
[0055] Once a no-origin risk is identified, the request's tracking identifier, original query key, request sending time, response status, and relevant business parameters can be recorded to generate complete no-origin high-risk information. During processing, this high-risk information can be stored in internal log files or structured data tables for subsequent summary analysis, statistical processing, trend assessment, or triggering of automatic alarm mechanisms. In faulty request scenarios, high-risk information can be sorted and categorized according to request order or timestamps to ensure that each record corresponds one-to-one with its corresponding Redis cache query request, achieving accurate tracking.
[0056] By analyzing the behavioral information corresponding to each Redis cache query request, it is possible to accurately determine whether a back-to-origin operation was performed after the request returned a response. If no back-to-origin operation was performed, a high-risk "no back-to-origin" message can be generated, thereby identifying potential cache back-to-origin vulnerabilities. This approach can systematically discover requests that may lead to data loss or business anomalies, providing reliable data for subsequent analysis and risk control. This improves the coverage and accuracy of detection, helps to identify potential problems in advance, and ensures the data integrity, stability, and reliability of the application system.
[0057] In the above embodiments, by recording request traffic during normal operation in the test environment and generating a unique tracking identifier for each Redis cache query request, automatic tracking and monitoring of the entire cache access process is achieved. When processing each Redis cache query request, the query key is adjusted to return a null value, thereby automatically obtaining the link behavior information of each request. By analyzing the link behavior information, it is possible to accurately determine which Redis cache query requests did not perform a back-to-origin operation after returning the result, and generate corresponding high-risk information for no back-to-origin operation. Compared with existing methods that rely on manually constructing cache failure scenarios, this method requires no manual intervention, can efficiently cover complex business scenarios and fault scenario requests, and realistically reproduce abnormal online traffic behavior, thereby systematically identifying cache no-back-to-origin risks. This method significantly improves detection coverage and accuracy, helps to discover potential risks in advance, ensures system stability and reliability, and solves the problem of difficulty in efficiently identifying cache no-back-to-origin risks in existing technologies.
[0058] In one embodiment, the step of modifying the query key in each Redis cache query request upon receipt of each Redis cache query request includes:
[0059] Upon receiving each Redis cache query request, the target method name of the target class name in each Redis cache query request is intercepted, the query key in each Redis cache query request is obtained, and the query key is replaced with a non-existent random key, and the modified Redis cache query request is executed.
[0060] Here, the target class name refers to the name of the class in the application code that defines the cache access logic. This class contains methods for handling Redis cache query requests. The target method name refers to the specific method name in the target class that performs the cache query operation, which processes the query request and returns the corresponding cached data. The random key is a unique identifier value generated by the system that does not exist in the cache. It is used to replace the original query key to simulate a cache miss scenario.
[0061] In practice, when a Redis cache query request is received, the target class name and target method name corresponding to the request can be identified first, and the call entry point of the target method can be captured through dynamic interception technology. During interception, the query key can be extracted from the input parameters of the method call. This query key is used to identify the corresponding data entry in the cache. After obtaining the query key, a unique random key can be generated using an internal system algorithm. This random key combines elements such as a timestamp, request sequence number, and random number to ensure that the corresponding data entry does not exist in the cache, thus guaranteeing that the replaced query request will not hit the cache.
[0062] After replacing the query key with a random key, the modified Redis cache query request can continue to be sent to the caching system. When the caching system processes this request, it will return a null response because the query key points to a non-existent data entry. Simultaneously, other key characteristics of the request can be retained, including the request sending time, client identifier, associated tracing identifier, and business request parameters. This information is recorded in internal data structures or logs for subsequent analysis of each request's behavior in the cache access chain. During this process, the request order and chain relationship can be maintained, allowing each request in a failure scenario to be independently traced and reproduced.
[0063] By intercepting the target method corresponding to the target class name in each Redis cache query request and obtaining the query key, then replacing the query key with a random key that does not exist in the cache and continuing to execute the request, cache miss scenarios can be automatically generated in the test environment. This accurately simulates the processing behavior of requests when the cache expires. This approach ensures that each request is independent and traceable, while obtaining complete request chain information. It provides a reliable data foundation for analyzing whether there are hidden risks of cache non-originating point issues, thereby improving the coverage and accuracy of detection, identifying potential risks in advance, and ensuring the data integrity, stability, and reliability of the application system.
[0064] In one embodiment, the step of obtaining the link behavior information of each tracking identifier corresponding to the Redis cache query request includes:
[0065] Access behaviors are intercepted by probes at cache access locations, database access locations, and external interface call locations. Based on the tracking identifiers carried in the access behaviors, access behaviors belonging to the same tracking identifier are aggregated to obtain the link behavior information of the Redis cache query request corresponding to each tracking identifier.
[0066] Among these, cache access locations refer to the code locations within an application system that initiate queries or write operations to a high-performance caching system, used to acquire or store data to improve access performance. Database access locations refer to the code locations within an application system that perform data read operations on a backend database or data source, used to acquire and save data when there is a cache miss or data updates. External interface call locations refer to the code locations within an application system that call third-party services or external system interfaces to acquire or process data. Probes are monitoring programs embedded in these access locations, used to intercept access behavior and obtain relevant information. Access behavior refers to the operation records generated during cache access, database access, or external interface calls, including request parameters, response status, call time, and associated tracking identifiers.
[0067] In practical implementation, probes can be deployed at cache access locations, database access locations, and external interface call locations. These probes can be embedded in the system's execution path to capture the operation information of each access request in real time. When a probe intercepts an access request, it can extract key information contained in the access behavior, such as tracking identifiers, query keys, request parameters, request sending time, client identifiers, and response status. Each access behavior information can be immediately written to the internal data cache after collection to ensure that the processing process of each request can be completely recorded in fault scenarios, avoiding information loss.
[0068] Subsequently, based on the tracking identifier carried in each access action, all access actions belonging to the same request can be aggregated. During the aggregation process, access actions can be sorted according to timestamp order or method call chain order, and cached access results, database access records, and external interface call statuses can be uniformly integrated to generate complete link behavior information corresponding to each tracking identifier. During the integration process, each cache hit or miss, whether the database was retrieved from the origin server, and whether the external interface call was successful can be marked to ensure that the link information is comprehensive and continuous.
[0069] After processing, the generated link behavior information can be stored in a structured data table, log file, or distributed storage system, supporting subsequent analysis, statistics, risk assessment, or visualization of the access link for each Redis cache query request. In fault scenarios, batch writing and indexing mechanisms can improve storage efficiency and retrieval speed, while maintaining a one-to-one correspondence between each link behavior information and its corresponding tracking identifier, thereby ensuring accurate tracking of cache origin retrieval behavior.
[0070] By intercepting access behaviors at cache access, database access, and external interface call locations, and aggregating behaviors of the same request based on tracking identifiers within the access behaviors, the processing chain of each Redis cache query request can be completely reconstructed, including cache hit or miss, origin pull operations, and external interface call information. This approach systematically captures and correlates all access behaviors for each request, providing a reliable data foundation for accurately analyzing cache origin pull situations and identifying potential origin pull vulnerabilities. This improves detection coverage and accuracy, helps to identify potential risks early, and ensures the data integrity, stability, and reliability of the application system.
[0071] In one embodiment, the process of determining whether a Redis cache query request exists but does not result in a data retrieval operation after being returned, based on the behavior information of each link, includes:
[0072] For each Redis cache query request, if no database query behavior, external interface request behavior, or cache write behavior associated with the same tracing identifier is detected in the corresponding link behavior information after the Redis cache query request returns a null value, it is determined that the Redis cache query request did not perform a data retrieval operation.
[0073] Specifically, database query behavior refers to the operation of retrieving data from the backend database when the cache is not hit. External interface request behavior refers to the data request operation initiated to a third-party service or external system when the cache is not hit. Cache write behavior refers to the operation of writing data retrieved from the database or external interface into the cache to ensure that subsequent requests hit the cache.
[0074] In the implementation process, the return result of each Redis cache query request can be obtained first, and it can be determined whether the returned data is null. During this determination, various information such as the cache response status code, the length of the returned content, and the integrity of the data structure can be combined to accurately determine the return result. When a cache query returns a null value, all access behaviors associated with that tracking identifier can be extracted from the corresponding link behavior information based on the request's tracking identifier. These access behaviors include database query records, representing operations that retrieve data from the backend database; external interface call records, representing data request operations initiated to third-party services or external systems; and cache write operation records, representing operations that write data retrieved from the database or external interface back to the cache. During the extraction process, various behaviors can be sorted according to the access timestamp to maintain the time order and call order of the request processing link.
[0075] Subsequently, the extracted access behaviors can be analyzed and judged. If no database query behavior, external interface request behavior, or cache write behavior is detected after a null value is returned, it can be determined that the Redis cache query request did not perform a data retrieval operation. During the analysis, the execution status of each access behavior can be verified by combining the request sending time, query key, client identifier, and business context information to ensure the accuracy and completeness of the judgment results. After processing, the analysis results, along with the associated request tracking identifier, query key, request time, and other key business information, can be uniformly recorded in an internal data table, structured log, or distributed storage system for subsequent statistical analysis, summarization, trend analysis, or triggering of automatic alarms.
[0076] By analyzing the behavior of each Redis cache query request after it returns a null value, if no database query, external interface request, or cache write is detected, it can be determined that the request did not perform a data retrieval operation. This approach can accurately identify potential cache non-origin retrieval risks, providing complete and traceable processing information for each request. This provides a reliable data foundation for subsequent risk analysis, statistics, and alerts, improving detection coverage and accuracy. It also helps to identify potential problems that may lead to data loss or business anomalies in advance, ensuring the data integrity, stability, and reliability of the application system.
[0077] In one embodiment, the method further includes:
[0078] Obtain the response body of the corresponding interface for each Redis cache query request, and for each response body, if the response body has specific response body characteristics, generate risk-free information to indicate that no origin server is required.
[0079] The interface response body refers to the data content returned by the caching system, database, or external interface during a Redis cache query request or origin retrieval operation, including status codes, response data fields, and business information. Specific response body characteristics refer to features contained in the response body that may indicate a normal response or no risk, such as containing keywords like "token expired" / "requires re-login," or a long response text. Risk-free information that does not require origin retrieval refers to a risk record generated upon discovering a specific response body, used to identify requests that may not require origin retrieval but are not risky for the business logic.
[0080] In the specific implementation process, for Redis cache query requests identified as having no origin server access risk in the initial detection phase, the corresponding interface response body can be further obtained, including cached return results, database origin server data, or external interface return content. Subsequently, feature analysis is performed on the above response body to determine whether the no origin server access risk falls under the category of "no origin server access but no business risk." For example, the response body can be checked for specific business-level response body features such as token expiration, requirement to re-login, or data expiration prompts. The structure, text length, or key field prompts of the returned content can also be used to assist in the judgment. During the analysis process, the tracking identifier, query key, and business context of the corresponding request can be combined to achieve refined identification of requests with no origin server access risk.
[0081] When the response body contains the aforementioned specific response body characteristics, risk-free information can be generated to identify requests that do not require a callback to the origin server. This risk-free information, along with the request's tracking identifier, query key, response time, and other business auxiliary information, is recorded in an internal data table, structured log, or distributed storage system. Through this secondary analysis mechanism, marked requests with no origin server risk can be automatically filtered and identified as "no origin server - no risk" without altering the preceding risk detection process. This effectively reduces the false alarm rate and prevents these requests from entering subsequent manual confirmation or alarm processes.
[0082] By introducing response body feature analysis after identifying no-origin-connection risk, requests initially judged to have no-origin-connection risk can be further screened, filtering out scenarios that are normal and do not require origin-connection. This approach not only significantly reduces the false positive rate in the no-origin-connection detection process but also reduces the workload of manual investigation, improving the accuracy and stability of the overall detection chain. By identifying "no-origin-connection but no risk" data in advance, the system can focus more on the real problem points, further improving the efficiency and accuracy of no-origin-connection risk management.
[0083] In one embodiment, the method further includes:
[0084] For each query key in a Redis cache query request, if the query key has specific cache key characteristics, risk-free information is generated to indicate that no origin server access is required.
[0085] Among them, specific cache key features refer to features in the query key that may not require a source retrieval, such as excessively long key length, irregular text, or content containing the keyword "token".
[0086] In the implementation process, for Redis cached query requests identified in the initial detection phase as having potential risks of no-origin requests, their query keys can be further obtained and their features analyzed to determine whether the risk falls under the "no-origin - no-risk" category. Specifically, it can be checked whether the query key contains specific cache key characteristics, such as a significantly excessively long query key, random and irregular text content, or business keywords like "token" that typically do not trigger a database origin request. Combined with the business context, it can also be determined whether such query keys belong to a logical scenario where returning a null value will not affect the business process, thus assisting in determining whether the risk of no-origin requests does not need to be included in subsequent manual investigation.
[0087] When the query key confirms the presence of the aforementioned specific cache key characteristics, risk-free information indicating "no need for origin server lookup" can be generated. This risk-free information, along with the tracking identifier, query key, recording time, and relevant business attributes of the corresponding Redis cache query request, is saved to an internal data table, structured log, or distributed storage system. Through this secondary analysis process, requests initially identified as having no origin server lookup risk can be automatically filtered and transformed into "no origin server lookup - risk-free" data, thereby preventing them from entering subsequent risk alerts or manual verification processes and reducing unnecessary investigation burden.
[0088] By performing query key-level feature analysis on Redis cache query requests identified as having potential risks of no origin server access, and generating risk-free information upon detecting specific cache key characteristics, this approach effectively distinguishes between "genuine risks of no origin server access" and "risk-free requests that do not require origin server access." This method filters out risk-free data in advance during the risk detection process, significantly reducing false positives, minimizing manual investigation workload, and improving the overall accuracy and efficiency of risk identification. Simultaneously, the secondary analysis mechanism ensures that the system only issues alerts for situations that could genuinely lead to data loss or business anomalies, further enhancing the stability of the caching system and the reliability of the data processing chain.
[0089] The following describes the cache no-origin vulnerability detection device provided in the embodiments of this application. The cache no-origin vulnerability detection device described below can be referred to in correspondence with the Redis cache no-origin vulnerability detection method described above. Figure 2 As shown, this application provides a cache non-origin vulnerability detection device, the device comprising:
[0090] The tracing identifier generation module 201 is used to record request traffic when the test environment is running normally and generate a unique tracing identifier for each Redis cache query request;
[0091] The query key modification module 202 is used to modify the query key in each Redis cache query request when each Redis cache query request is received, so that each Redis cache query request returns an empty value;
[0092] Link behavior information acquisition module 203 is used to acquire link behavior information of Redis cache query requests corresponding to each tracking identifier;
[0093] The high-risk information generation module 204 is used to generate high-risk information indicating no data return to the origin if, based on the behavior information of each link, it is determined that there is a Redis cache query request that returns without data return to the origin.
[0094] In one embodiment, the query key modification module 202 includes:
[0095] The query key modification unit is used to intercept the target method name of the target class name in each Redis cache query request when it is received, obtain the query key in each Redis cache query request, replace the query key with a non-existent random key, and continue to execute the modified Redis cache query request.
[0096] In one embodiment, the link behavior information acquisition module 203 includes:
[0097] The link behavior information acquisition unit is used to intercept access behavior through probes at cache access location, database access location and external interface call location, and aggregate access behavior belonging to the same tracking identifier according to the tracking identifier carried in the access behavior to obtain the link behavior information of Redis cache query request corresponding to each tracking identifier.
[0098] In one embodiment, the high-risk information generation module 204 without a source includes:
[0099] The link behavior information analysis unit is used to determine that for each Redis cache query request, if no database query behavior, external interface request behavior, or cache write behavior associated with the same tracing identifier is detected in the corresponding link behavior information after the Redis cache query request returns a null value, then the Redis cache query request has not performed a data back-to-origin operation.
[0100] In one embodiment, the apparatus further includes:
[0101] The first risk-free information generation module is used to obtain the response body of the interface corresponding to each Redis cache query request, and for each response body, if the response body has specific response body characteristics, it generates risk-free information to indicate that there is no need to go back to the origin.
[0102] In one embodiment, the apparatus further includes:
[0103] The second risk-free information generation module is used to generate risk-free information indicating that no origin server access is required for each query key in a Redis cache query request if the query key has specific cache key characteristics.
[0104] In one embodiment, this application also provides a storage medium storing computer-readable instructions, which, when executed by one or more processors, cause the one or more processors to perform the steps of the Redis cache no-origin vulnerability detection method as described in any of the above embodiments.
[0105] In one embodiment, this application also provides a computer device storing computer-readable instructions that, when executed by one or more processors, cause the one or more processors to perform the steps of the Redis cache no-origin vulnerability detection method as described in any of the above embodiments.
[0106] Indicatively, such as Figure 3 As shown, Figure 3 This is a schematic diagram of the internal structure of a computer device 300 provided in an embodiment of this application. The computer device 300 can be provided as a server. (Refer to...) Figure 3 The computer device 300 includes a processing component 302, which further includes one or more processors, and memory resources represented by memory 301 for storing instructions, such as application programs, that can be executed by the processing component 302. The application programs stored in memory 301 may include one or more modules, each corresponding to a set of instructions. Furthermore, the processing component 302 is configured to execute instructions to perform the Redis cache no-origin vulnerability detection method of any of the above embodiments.
[0107] The computer device 300 may also include a power supply component 303 configured to perform power management of the computer device 300, a wired or wireless network interface 304 configured to connect the computer device 300 to a network, and an input / output (I / O) interface 305. The computer device 300 may operate on an operating system stored in memory 301, such as Windows Server™, Mac OS X™, Unix™, Linux™, Free BSD™, or similar.
[0108] Those skilled in the art will understand that Figure 3 The structure shown is merely a block diagram of a portion of the structure related to the present application and does not constitute a limitation on the computer device to which the present application is applied. Specific computer devices may include more or fewer components than those shown in the figure, or combine certain components, or have different component arrangements.
[0109] Finally, it should be noted that in this document, relational terms such as "first" and "second" are used only to distinguish one entity or operation from another, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Furthermore, 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. Unless otherwise specified, 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. In this document, "a," "an," "the," "the," and "its" may also include plural forms unless the context clearly indicates otherwise. "Multiple" refers to at least two, such as 2, 3, 5, or 8, etc. "And / or" includes any and all combinations of the related listed items.
[0110] The various embodiments in this specification are described in a progressive manner. Each embodiment focuses on the differences from other embodiments. The various embodiments can be combined as needed, and the same or similar parts can be referred to each other.
[0111] The above description of the disclosed embodiments enables those skilled in the art to make or use this application. Various modifications to these embodiments will be readily apparent to those skilled in the art, and the general principles defined herein may be implemented in other embodiments without departing from the spirit or scope of this application. Therefore, this application is not to be limited to the embodiments shown herein, but is to be accorded the widest scope consistent with the principles and novel features disclosed herein.
Claims
1. A method for detecting potential issues with Redis caching without origin server access, characterized in that, The method includes: Record request traffic while the test environment is running normally, and generate a unique trace identifier for each Redis cache query request; When each Redis cache query request is received, the query key in each Redis cache query request is modified so that each Redis cache query request returns a null value; Obtain the link behavior information of the Redis cache query request corresponding to each of the aforementioned tracking identifiers; If, based on the behavior information of each link, it is determined that there is a Redis cache query request that returns without a data return operation to the origin, then high-risk information indicating no data return to the origin is generated.
2. The method for detecting Redis cache non-origin vulnerability according to claim 1, characterized in that, The step of modifying the query key in each Redis cache query request when each Redis cache query request is received includes: Upon receiving each Redis cache query request, the target method name of the target class name in each Redis cache query request is intercepted, the query key in each Redis cache query request is obtained, and the query key is replaced with a non-existent random key, and the modified Redis cache query request is executed.
3. The method for detecting Redis cache non-origin vulnerability according to claim 1, characterized in that, The step of obtaining the link behavior information of each Redis cache query request corresponding to the tracking identifier includes: Access behaviors are intercepted by probes at cache access locations, database access locations, and external interface call locations. Based on the tracking identifiers carried in the access behaviors, access behaviors belonging to the same tracking identifier are aggregated to obtain the link behavior information of the Redis cache query request corresponding to each tracking identifier.
4. The method for detecting Redis cache non-origin vulnerability according to claim 1, characterized in that, The process of determining, based on each of the link behavior information, that there are Redis cache query requests that, after being returned, do not have a data retrieval operation, includes: For each Redis cache query request, if no database query behavior, external interface request behavior, or cache write behavior associated with the same tracing identifier is detected in the corresponding link behavior information after the Redis cache query request returns a null value, then it is determined that the Redis cache query request did not perform a data back-to-origin operation.
5. The method for detecting Redis cache non-origin vulnerability according to any one of claims 1 to 4, characterized in that, The method further includes: Obtain the response body of the interface corresponding to each Redis cache query request, and for each response body, if the response body has specific response body characteristics, generate risk-free information to indicate that no origin server is required.
6. The method for detecting Redis cache non-origin vulnerability according to any one of claims 1 to 4, characterized in that, The method further includes: For each query key in the Redis cache query request, if the query key has a specific cache key characteristic, then risk-free information is generated to indicate that no origin server access is required.
7. A device for detecting potential issues with Redis cache back-to-origin services, characterized in that, The device includes: The trace identifier generation module is used to record request traffic while the test environment is running normally and generate a unique trace identifier for each Redis cache query request; The query key modification module is used to modify the query key in each Redis cache query request when each Redis cache query request is received, so that each Redis cache query request returns a null value; The link behavior information acquisition module is used to acquire the link behavior information of each Redis cache query request corresponding to the tracking identifier; The module for generating high-risk information about no data return to the origin is used to generate high-risk information indicating no data return to the origin if, based on the behavior information of each link, it is determined that there is a Redis cache query request that returns without any data return to the origin.
8. The Redis cache no-origin vulnerability detection device according to claim 7, characterized in that, The query key modification module includes: The query key modification unit is used to intercept the target method name of the target class name in each Redis cache query request when each Redis cache query request is received, obtain the query key in each Redis cache query request, replace the query key with a non-existent random key, and continue to execute the modified Redis cache query request.
9. A storage medium, characterized in that: The storage medium stores computer-readable instructions, which, when executed by one or more processors, cause the one or more processors to perform the steps of the Redis cache no-origin vulnerability detection method as described in any one of claims 1 to 6.
10. A computer device, characterized in that, include: One or more processors, and memory; The memory stores computer-readable instructions, which, when executed by the one or more processors, perform the steps of the Redis cache no-origin vulnerability detection method as described in any one of claims 1 to 6.