System security detection method and device, equipment and storage medium

Abstract

The invention provides a system security detection method, device and equipment and a storage medium, and is applied to the field of data security, and the method comprises the steps: obtaining network traffic generated in a system operation process, screening the network traffic to obtain target traffic, and carrying out the structural processing of the target traffic to obtain standardized data; executing corresponding detection strategies for different unauthorized scenes based on the standardized data; and outputting a detection result corresponding to the detection strategy execution result. According to the method, the network traffic generated in the operation process of the service system is acquired and processed to form the standardized data, and the corresponding detection strategies are executed for different scenes based on the standardized data, so that the recognition accuracy and comprehensiveness of various unauthorized behaviors in the system are improved, and the user experience is improved. And complex scenes such as unauthorized conditions among different authority levels and unauthorized conditions among merchants of the same level can be detected in a targeted manner.

Description

Technical Field

[0001] This application relates to the field of data security, and in particular to a system security detection method, apparatus, device and storage medium. Background Technology

[0002] Individual business owner service systems contain richer and more sensitive information. Due to the complexity of access control and the increasing functionality as the system evolves, privilege escalation vulnerabilities are easily introduced during system development, often due to oversight or developers' insufficient understanding or experience of the design. Therefore, individual business owner service systems have a high demand for privilege escalation detection, requiring a comprehensive assessment of potential privilege escalation scenarios under the characteristics of access control. However, existing system security detection technologies are mostly designed for general systems or specific non-merchant service scenarios, resulting in incomplete detection coverage and insufficient targeting. Summary of the Invention

[0003] This application provides a system security detection method, apparatus, device, and storage medium to address the problems of incomplete detection coverage and insufficient targeting in existing system security detection methods.

[0004] To solve the above-mentioned technical problems, this application is implemented as follows: Firstly, embodiments of this application provide a system security detection method. The method includes: The system acquires network traffic generated during system operation, filters the network traffic to obtain target traffic, and performs structured processing on the target traffic to obtain standardized data. Based on the standardized data, corresponding detection strategies are executed for different unauthorized access scenarios; wherein, the unauthorized access scenarios include at least one of unauthorized access, vertical unauthorized access, and horizontal unauthorized access. Output the detection results corresponding to the execution result of the detection strategy.

[0005] Secondly, embodiments of this application also provide a system security detection device. This system security detection device includes: The acquisition module is used to acquire network traffic generated during the operation of the individual business service system, and after filtering and structuring, obtain standardized data for storage in the database; The execution module is used to read the database, construct request packets, and execute corresponding detection strategies for different unauthorized access scenarios; wherein, the unauthorized access scenarios include unauthorized access, vertical unauthorized access, horizontal unauthorized access, sensitive data protection, service parameter restrictions, and extended interface control; The output module is used to output the detection results.

[0006] Thirdly, embodiments of this application also provide an electronic device, including a processor, a memory, and a computer program stored in the memory and executable on the processor, wherein the computer program, when executed by the processor, implements the steps of the above-described system security detection method.

[0007] Fourthly, embodiments of this application also provide a computer-readable storage medium storing a computer program, which, when executed by a processor, implements the steps of the above-described system security detection method.

[0008] This application's embodiment of the system security detection method includes acquiring network traffic generated during system operation, filtering the network traffic to obtain target traffic, and performing structured processing on the target traffic to obtain standardized data; executing corresponding detection strategies based on the standardized data for different unauthorized access scenarios; wherein the unauthorized access scenarios include at least one of unauthorized access, vertical unauthorized access, and horizontal unauthorized access; and outputting detection results corresponding to the execution results of the detection strategies. This method acquires network traffic generated during the operation of a service system, filters it to obtain target traffic, performs structured processing to form standardized data, and then executes corresponding detection strategies for different scenarios based on this standardized data, finally outputting detection results. It effectively combines the characteristics of hierarchical permissions, permission domain division, and data isolation in service system permission management, improving the accuracy and comprehensiveness of identifying various unauthorized behaviors in the system. It can effectively detect basic security issues such as unauthorized access, and can also specifically detect complex scenarios such as unauthorized access between different permission levels and unauthorized access between merchants at the same level, thereby improving the system's response efficiency to permission risks and providing more reliable security for the service system. Attached Figure Description

[0009] To more clearly illustrate the technical solutions of the embodiments of this application, the drawings used in the description of the embodiments of this application 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.

[0010] Figure 1 This is a flowchart of the system security detection method provided in the embodiments of this application; Figure 2 This is a flowchart of network traffic acquisition and processing provided in an embodiment of this application; Figure 3 This is a schematic diagram of a similarity comparison strategy provided in an embodiment of this application; Figure 4 This is a schematic diagram illustrating the configuration of scan traffic according to an embodiment of this application; Figure 5 This is a schematic diagram illustrating the generation of a scanning task according to an embodiment of this application; Figure 6 This is a structural diagram of a system security detection device provided in an embodiment of this application; Figure 7 This is a structural diagram of an electronic device provided in an embodiment of this application. Detailed Implementation

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

[0012] This application provides a system security detection method. See also... Figure 1 , Figure 1 This is a flowchart of the system security detection method provided in the embodiments of this application, such as... Figure 1 As shown, it includes the following steps: Step 101: Obtain network traffic generated during system operation, filter the network traffic to obtain target traffic, and perform structured processing on the target traffic to obtain standardized data; In this step, we can take the merchant service system as an example. The merchant service system is a system that provides services to individual business owners (hereinafter referred to as "merchants"). It contains sensitive information such as merchant name, unified social credit code, bank account, and transaction records. Moreover, the permission management has the characteristics of hierarchical permission, permission domain division, and data isolation, such as the difference in permission levels between system administrators, merchant administrators, and merchant employees, and the permission domain division of functional modules such as payment processing and tax management.

[0013] The aforementioned acquisition of network traffic generated during system operation can be understood as comprehensively capturing various interactive data during system operation by deploying data collection mechanisms at key system communication nodes such as gateways and interface layers; for example, such as Figure 2 As shown, a traffic capture agent can be deployed on the gateway machine in the test environment to actively capture network traffic (including HTTP requests and responses) from the gateway's network interface card and send it to a stream processing platform (such as Kafka). For example, a merchant service system's gateway generates tens of thousands of traffic data entries daily, and the agent can capture this data in real time and transmit it to the stream processing platform for temporary storage.

[0014] The aforementioned filtering of network traffic to obtain target traffic can be understood as extracting valid data directly related to the target system from the collected full traffic based on preset identification information related to the detection target (such as system-specific identifiers, business characteristic fields, etc.), excluding irrelevant and interfering traffic, and achieving precise data focus. For example, based on preset merchant service identification information carried in the network traffic, such as "Dj-Rc: SecTest" or "X-Kd-Source:sectest" in the header, target traffic belonging to merchant services can be filtered from the captured traffic, excluding irrelevant traffic not belonging to merchant services, such as internal system test traffic. For instance, if the header of a traffic contains "X-Kd-Source: sectest", it is determined to be target traffic.

[0015] The aforementioned structuring of target traffic to obtain standardized data can be understood as taking unstructured or semi-structured raw traffic data, organizing it according to a unified data model (covering core elements such as request methods, resource paths, parameters, and responses), and ensuring data uniqueness through deduplication mechanisms (such as generating unique identifiers based on key information). The result is standardized data with a unified format that can be directly used for detection and analysis. Target traffic can be structured according to a preset data structure, and unique identifiers can be generated based on hash algorithms to remove duplicate data. For example, the MD5 algorithm can be used to encrypt "method+domain+url," and the generated hash value serves as the basis for interface deduplication—if two traffic entries have the same hash value, they are considered duplicate interface traffic, and only one is retained. The final standardized data can be stored in a relational database (such as MySQL) for subsequent detection.

[0016] In some alternative implementations, data processing can be optimized. For example, when processing queries and their bodies, duplicates can be deduplicated and multiple copies saved to facilitate testing with different data, improving the efficiency and accuracy of subsequent privilege escalation detection. Simultaneously, scanning logs are recorded and the database is marked; during the next scan cycle, these markings can be used to determine whether to repeat the scan, further improving efficiency.

[0017] Step 102: Execute corresponding detection strategies for different unauthorized access scenarios based on the standardized data; In this step, the unauthorized access scenarios are categorized based on the access control characteristics of the merchant service system. In some optional implementations, these may include unauthorized access, vertical unauthorized access, horizontal unauthorized access, sensitive data protection, service parameter restrictions, and extended interface control. Corresponding detection strategies are executed for different scenarios.

[0018] Step 103: Output the detection result corresponding to the execution result of the detection strategy.

[0019] In this step, the "output detection results" can take various forms depending on actual needs. These can include a direct determination of whether a vulnerability exists, or detailed information such as vulnerability type, risk level, and scope, to comprehensively reflect the system's access control and security status. In some optional implementations, a "vulnerability exists" or "no vulnerability" determination can be output, or other results can be output to characterize the system's security. In some optional implementations, the output results, including vulnerability type, involved interfaces, and response data, can also be recorded in a log.

[0020] For example: If the unauthorized access detection returns a status code of 200 and does not contain the keyword "insufficient permissions", then output "An unauthorized access vulnerability exists". If a plaintext phone number is found during a sensitive data scan, the message "A sensitive data leakage vulnerability exists" will be output.

[0021] The test results can be notified to the administrator in real time through the alarm system, or stored in the database for subsequent auditing.

[0022] In the system security detection method of this application embodiment, network traffic generated during the operation of the service system is acquired, target traffic is filtered and structured to form standardized data, and then corresponding detection strategies are executed for different scenarios based on the standardized data, finally outputting the detection results. This method effectively combines the characteristics of hierarchical permissions, permission domain division, and data isolation in the service system's permission management, improving the accuracy and comprehensiveness of identifying various unauthorized behaviors in the system. It can effectively detect basic security issues such as unauthorized access, and can also specifically detect complex scenarios such as unauthorized access between different permission levels and unauthorized access between merchants at the same level, thereby improving the system's response efficiency to permission risks and providing more reliable security for the service system.

[0023] Optionally, the step of acquiring network traffic generated during system operation, filtering the network traffic to obtain target traffic, and performing structured processing on the target traffic to obtain standardized data includes: Capture network traffic generated during system operation at the gateway in the test environment; Target traffic is filtered based on the preset merchant service identification information carried in the network traffic; The target traffic is structured according to a preset data structure, and a unique identifier is generated based on a hash algorithm to remove duplicate traffic data in the target traffic, thereby obtaining the standardized data.

[0024] In the system security detection method of this application embodiment, network traffic generated during system operation is captured at the test environment gateway. The test environment gateway is a key node in the system's network communication, through which all network data entering and leaving the individual business service system flows. A dedicated traffic capture tool can be deployed at the gateway; for example, a network traffic capture tool like Buger / goreplay can be used. This tool can intrusively monitor relevant gateway ports in real time, thereby capturing all network traffic data flowing through the gateway comprehensively and accurately. This captured traffic data can include various interactive information during system operation, such as request and response data between merchants and the system server, and communication data between different modules within the system, providing rich raw material for subsequent detection work.

[0025] Target traffic can be filtered based on pre-defined merchant service identification information carried in network traffic. The network traffic of the individual business service system is mixed with network traffic from other systems, requiring specific identification information to distinguish traffic related to the merchant service. This pre-defined merchant service identification information typically exists in the network traffic data in the form of specific HTTP request headers, such as "Dj-Rc: SecTest" or "X-Kd-Source: sectest". After acquiring network traffic, traffic capture tools can parse and match the header information in each data stream. Only traffic containing pre-defined merchant service identification information in its headers will be identified as target traffic and filtered out, eliminating a large amount of irrelevant interference traffic and improving the targeting and efficiency of subsequent detection work.

[0026] Structured processing of target traffic according to a predefined data structure allows for the generation of unique identifiers based on hash algorithms to remove duplicate traffic data, resulting in standardized data. The predefined data structure specifies how the target traffic is organized and stored, typically encompassing fields such as method (representing the HTTP request method, e.g., GET, POST), domain (domain name, i.e., the domain name of the target server), url (Uniform Resource Locator, detailing the requested resource path), query (query parameters in the request), header (detailed content of the HTTP request headers), response (response data returned by the server), hash (hash value used to identify the uniqueness of data), and description (a brief description of the traffic data). In some optional implementations, after the target traffic is processed according to this predefined data structure, it is stored in a relational database (such as MySQL) for further processing and analysis.

[0027] In some optional implementations, a unique identifier is generated based on a hash algorithm to remove duplicate traffic data from the target traffic. A hash algorithm is an algorithm that maps data of arbitrary length to a fixed-length hash value. For example, the commonly used MD5 algorithm can convert a data string into a 128-bit hash value. In some optional implementations, the SHA1 algorithm can also be used, which maps data to a 160-bit hash value. In this scenario, key parts of the traffic data can be selected, such as "method + domain + url," as input to the hash algorithm to calculate a unique hash value. When new target traffic data needs to be stored, its hash value can be calculated first and then compared with the hash values ​​of data already stored in the database. If the hash values ​​are the same, it means that the traffic data is a duplicate of the stored data and is therefore discarded. Only data with different hash values ​​is stored in the database. This method effectively avoids the interference of duplicate data with subsequent detection work, ensuring the accuracy and uniqueness of the final standardized data, and laying a solid data foundation for subsequent detection strategies for different unauthorized access scenarios.

[0028] In this implementation, by capturing network traffic at the gateway of the test environment, the comprehensiveness and originality of the merchant service system's interactive data are ensured. Target traffic is filtered based on preset merchant service identification information, eliminating irrelevant data that is not related to merchant services, thus improving the targeting of data processing. Structured processing according to a preset structure and deduplication using a hash algorithm ensures the standardization, uniqueness, and validity of the data. This provides standardized data support for subsequent unauthorized access vulnerability detection and lays a reliable data foundation for accurately identifying various unauthorized behaviors.

[0029] Optionally, the execution of corresponding detection strategies for different unauthorized access scenarios includes: In cases where the unauthorized access scenario is an unauthorized access violation or a vertical unauthorized access violation, the detection strategy includes matching preset keywords and analyzing service response status information; In the case of a horizontal unauthorized access scenario, a first detection strategy is executed. The first detection strategy includes matching preset keywords, analyzing service response status information, and comparing the similarity of the service response status information. The detection result is deemed to have a vulnerability if any of the following conditions are met: Matching preset keywords successfully; The service response status information is abnormal; The similarity of the service response status information exceeds a preset threshold.

[0030] In the system security detection method of this application embodiment, the aforementioned unauthorized access can be understood as the act of accessing protected system resources without any verification credentials, such as login information or permission tokens. For example, directly accessing sensitive data pages of the merchant management backend without being logged in, or obtaining merchant transaction records without carrying valid cookies / tokens.

[0031] The aforementioned vertical privilege escalation, also known as "layered privilege escalation," can be understood as occurring between entities at different privilege levels, such as a system administrator and a merchant administrator, or a merchant administrator and a merchant employee, where a lower-privilege entity attempts to access a higher-privilege resource. It can include two types: Unauthorized access by non-overlapping merchants: Unauthorized access between entities with completely non-overlapping permissions, such as a merchant employee accessing the system administrator's exclusive full set of de-identified merchant data; Overlapping merchant privileges: Unauthorized access between entities with overlapping permissions, such as a merchant employee accessing merchant fund summary data that can only be viewed by the merchant administrator.

[0032] The aforementioned horizontal privilege escalation can be understood as occurring between entities at the same permission level, or between different permission domains / ends at the same level, such as the "merchant end" and the "finance and tax end" and "management end," where one entity attempts to access the exclusive resources of another entity at the same level. For example, Merchant A accesses the merchant's transaction details, or the "merchant end" account accesses the "finance and tax end's" tax data by replacing cookies, etc.

[0033] The aforementioned preset keywords can be understood as predefined text identifiers used by the system to determine permission status, such as "insufficient permissions", "unauthorized access", "please log in first", "no operation permission", etc., to help determine whether the access is compliant.

[0034] The service response status information mentioned above mainly refers to HTTP response status codes, which are used to characterize the processing result of the request, such as 200 (request successful), 403 (access denied, insufficient permissions), 401 (unauthorized, verification required), etc.

[0035] The similarity of the service response status information mentioned above can be understood as the degree of similarity between the response data of two requests (such as returned text or JSON structure). It is calculated using a string similarity algorithm (such as the Levenshtein Distance algorithm in the disclosure document) to determine whether a subject at the same level has accessed similar sensitive data without authorization.

[0036] For unauthorized access and vertical privilege escalation, the detection strategy focuses on "matching preset keywords" and "analyzing service response status information," as exemplified by: When matching preset keywords, the system will scan the service response data for predefined "permission verification failed" keywords, such as "insufficient permissions" or "please contact the administrator to obtain permissions." If no such keyword is matched, it means that the access may not have been blocked by access control; if it is matched, it means that access control is in effect.

[0037] To analyze service response status information, you can combine the HTTP status code to determine whether the access was successful: If the status code is 200 (request successful) and the response contains the target resource data, such as the merchant name and transaction amount, it means that the unauthorized access was successful. If the status code is 403 (Access Denied) or 401 (Unauthorized), and the response contains keywords such as "insufficient permissions," it indicates that the access control is effective and there are no vulnerabilities.

[0038] In some alternative implementations, specific detection scenarios for vertical unauthorized access are addressed: For non-intersecting merchants who exceed their permissions, access to high-permission interfaces can be achieved by configuring "0-permission Cookie" or "low-permission Cookie". For example, if a merchant employee's Cookie is used to access the system administrator's interface, and a 200 status code is returned without the keyword "insufficient permissions", then a vulnerability is identified. For instances of unauthorized access by overlapping merchants, such as in a "group member-group leader" relationship, if a "group member" requests resources exclusive to the "group leader" and receives a 200 status code instead of a 403, then a vulnerability is identified.

[0039] For example: If a request without a login cookie is sent to a merchant's funds page, and the response does not contain the keyword "Please log in first", there may be an unauthorized access vulnerability.

[0040] The aforementioned horizontal privilege escalation detection, based on "matching preset keywords" and "analyzing service response status information," adds "comparing the similarity of service response status information." The logic is consistent with vertical privilege escalation, requiring verification of whether the same-level entity returns the "insufficient permissions" keyword and 403 / 401 status codes when accessing the other party's resources. For example, if Merchant A uses its own cookie to access Merchant B's interface and returns a 200 status code without the "unauthorized access" keyword, a preliminary assessment indicates a risk of privilege escalation.

[0041] To assess the similarity of service response status information, a string similarity algorithm (such as the Levenshtein Distance algorithm in the disclosure document) can be used to calculate the similarity between the response data (such as returned JSON or text) of two requests. This algorithm calculates the minimum number of operations required to convert one string into another, such as the number of insertions, deletions, and replacements. In some optional implementations, similarity can be quantified, such as a score of 0 to 100, with higher scores indicating greater similarity. Of course, other methods of quantifying similarity can also be used, and this application does not specifically limit the methods used in this embodiment.

[0042] For example, if Merchant A and Merchant B are at the same permission level and each uses their own Cookie to request the "transaction record" interface, if the similarity of their response data exceeds 80% (preset threshold) and both contain sensitive information such as specific transaction amount and time, it is determined that Merchant A may have accessed Merchant B's data without authorization.

[0043] A system is considered to have a vulnerability if any of the following conditions are met: The above-mentioned successful matching of preset keywords means that the response did not match preset keywords such as "insufficient permissions" or "unauthorized," indicating that access control did not trigger an interception. For example, if a user with low privileges accesses a resource with high privileges and the response does not contain an "unauthorized access" message, it suggests that unauthorized access may have occurred.

[0044] An abnormal service response status information refers to an HTTP status code that is "successful" (e.g., 200) or an unexpected "non-rejection" status code (e.g., 302 redirecting to a sensitive page). For example, returning a 200 status code and directly displaying the merchant's bank account information when unauthorized access is requested is considered an abnormal status information.

[0045] The similarity of service response status information exceeding a preset threshold can be understood as a vulnerability in horizontal privilege escalation detection. If the similarity of two response data (e.g., the Levenshtein Distance calculation result) exceeds a system preset threshold (e.g., 80%), and the data contains sensitive information such as merchant addresses and transaction details, then a vulnerability is identified. The threshold can be adjusted according to the business scenario. For example, the threshold can be set to 60% for sensitive data scenarios and 90% for non-sensitive scenarios. In some optional implementations, the above similarity threshold can also be dynamically adjusted according to the data sensitivity. For example, the threshold can be set to 50% for highly sensitive data such as merchant ID numbers, and 90% for ordinary merchant name data. Alternatively, the threshold can be automatically optimized by training a model using historical vulnerability data. This application embodiment does not specifically limit this aspect.

[0046] In some alternative implementations, in addition to the Levenshtein Distance algorithm, other string similarity algorithms (such as cosine similarity, Jaccard coefficient) can be used, or dedicated similarity calculation logic can be designed for structured data (such as JSON), such as comparing field overlap, field value similarity, etc. This application does not specifically limit the implementation of these algorithms.

[0047] This implementation employs a detection strategy that matches preset keywords and analyzes service response status information for unauthorized access and vertical privilege escalation scenarios. For horizontal privilege escalation scenarios, an additional first detection strategy comparing the similarity of service response status information is added. Based on judgment conditions such as successful keyword matching, abnormal service response status information, and response information similarity exceeding a preset threshold, the system achieves accurate and comprehensive identification of different privilege escalation scenarios within the service system. It effectively detects the basic risk of unauthorized access to resources and specifically identifies vertical privilege escalation between different permission levels and horizontal privilege escalation between entities at the same level. In particular, the similarity comparison enhances the detection capability for complex horizontal privilege escalation behaviors such as cross-merchant and cross-permission domain actions, thereby improving the security and reliability of the system's permission management.

[0048] Optionally, the unauthorized access scenario also includes sensitive data protection; The implementation of corresponding detection strategies for different unauthorized access scenarios includes: In the case of sensitive data protection in the unauthorized access scenario, a second detection strategy is executed. The second detection strategy includes scanning whether the service response status information contains preset sensitive data. If the service response status information contains preset sensitive data, the system is determined to have a vulnerability.

[0049] In the system security detection method of this application embodiment, the aforementioned sensitive data protection scenario can be understood as a scenario where access control is implemented for sensitive information related to merchant operations in the service system, such as identity information, account information, and transaction records. Since the merchant service system contains far more sensitive data than individual users, such as merchant names, unified social credit codes, and bank account numbers, unauthorized disclosure of this data can lead to serious security risks. Therefore, it needs to be tested as a separate unauthorized access scenario.

[0050] The second detection strategy mentioned above can be understood as a detection strategy specifically designed for sensitive data protection scenarios. Its core is to identify sensitive data that is not protected in accordance with the specifications by scanning service response information, and to ensure that sensitive information is only accessed by authorized entities in accordance with the de-identification rules.

[0051] The aforementioned preset sensitive data can be understood as the merchant's sensitive information that the system predefines and requires strict protection, including but not limited to mobile phone number, ID card number, bank card number, unified social credit code, merchant name, address, plaintext password, email address, landline telephone number, etc.

[0052] The service response status information mentioned above can be the specific data content returned in the HTTP response (such as HTML text, JSON structure, etc.), from which it can be extracted and identified whether it contains preset sensitive data.

[0053] The core of the second detection strategy can be understood as "scanning whether the service response status information contains preset sensitive data". The specific process is as follows: The system can first clearly define the sensitive data types to be detected and the corresponding de-identification specifications, i.e., the legal display format. Sensitive data not displayed according to these specifications is considered "preset sensitive data." For example, core sensitive data and de-identification rules may include: Mobile phone number: Keep the first 3 digits and the last 2 digits, and replace the middle with "*" (e.g., 131*****83). If the complete mobile phone number appears in plain text, it is preset sensitive data. ID number: Keep the first 2 and last 3 digits, and replace the middle with "*" (e.g., 37***************317). Complete plaintext or data that has not been de-identified according to the rules is considered preset sensitive data. Bank card number: Keep the first 4 digits and the last 4 digits, and replace the middle digits with "*" (e.g., 6202***1234). Complete card numbers or those that are not thoroughly de-identified are considered as preset sensitive data. Unified Social Credit Code / Tax ID: Only the 11th to 14th digits are anonymized (e.g., 91110228MA****L85F). Data that is not anonymized or has an incorrect anonymization range is considered pre-defined sensitive data. Other types, such as addresses (first 4 characters + last 2 characters + 4 asterisks in the middle) and merchant names (first character + last 2 characters + asterisks in the middle), must be strictly anonymized according to the rules; otherwise, they will be considered as preset sensitive data.

[0054] Scanning service response data can be understood as the system, after obtaining service response status information, using techniques such as text matching and regular expressions to scan whether it contains the aforementioned unmasked, pre-defined sensitive data. For example, scanning the returned JSON data {"merchant_phone":"complete mobile phone number"} and finding a complete mobile phone number in plaintext indicates that it contains pre-defined sensitive data. The returned HTML text "Merchant Address: No. 88, C Road, B District, City A" was scanned and found to be un-masked according to the format "first 4 characters + last 2 characters + 4 asterisks in the middle" (the correct format should be "AB****8"). It was determined to contain preset sensitive data.

[0055] The above vulnerability determination rules can be understood as follows: if a scan finds any pre-defined sensitive data in the service response status information, i.e., sensitive information not displayed according to the de-identification specifications, then the system is directly determined to have a vulnerability. For example, if a merchant administrator queries subordinate merchant information and the response contains a complete bank account number in plaintext, it is determined to be a vulnerability. When the system administrator accesses the merchant list, the merchant name is displayed as the full company name (without masking, it is "A***** Company"), which is identified as a vulnerability.

[0056] This implementation incorporates sensitive data protection into unauthorized access scenarios and executes a second detection strategy: scanning service response status information for pre-defined sensitive data. Upon detecting the presence of such data, a vulnerability is identified, enabling targeted protection of sensitive merchant information (such as bank accounts, ID numbers, and unified social credit codes) within the service system. This approach can more accurately target highly sensitive merchant-specific data. Through clear sensitive data identification and detection rules, it more effectively identifies the risk of information leakage due to non-compliant anonymization, ensuring that sensitive data is only displayed within authorized limits and according to anonymization requirements. This strengthens the system's security protection of core merchant information and reduces the risk of sensitive data leakage to some extent.

[0057] Optionally, the unauthorized access scenario also includes service parameter restrictions and extended interface control; The implementation of corresponding detection strategies for different unauthorized access scenarios includes: In cases where the unauthorized access scenario involves service parameter restrictions or extended interface controls, a third detection strategy is executed. The third detection strategy includes comparing the similarity and data length of service response status information before and after adding, deleting, and / or replacing parameters. The system is deemed to have a vulnerability if any of the following conditions are met: The similarity of the service response status information exceeds a preset threshold; The data length remains unchanged.

[0058] In the system security detection method of this application embodiment, the aforementioned service parameter restrictions can be understood as a constraint mechanism for interface request parameters in the individual business service system, including parameter validity verification and permission correlation verification (such as matching parameter values ​​with the permissions of the accessing subject), to prevent unauthorized access to resources by tampering with parameters. For example, the merchant query interface can be restricted to accessing only its own data through the merchant_id parameter; if the parameter is not restricted, it may lead to unauthorized access.

[0059] The aforementioned extended interface control can be understood as a permission management mechanism for system extended interfaces (such as integration interfaces with third-party financial and tax systems and payment systems). This ensures that extended interfaces are only called by authorized entities according to preset rules, avoiding the risk of unauthorized access due to oversights in interface design. For example, the merchant batch data export interface needs strict control over its calling parameters to prevent unauthorized entities from obtaining the full amount of merchant data.

[0060] The third detection strategy can be understood as a detection strategy specifically designed for service parameter restrictions and extended interface control scenarios. It can determine whether the parameter constraints are effective by actively modifying request parameters (adding, deleting, or replacing) and comparing the similarity and data length of the service response before and after the modification.

[0061] The above parameter operations can include the following three core ways to modify request parameters: Add parameters: Add extra parameters to the request (e.g., add target_merchant_id=xxx to the query interface); Remove parameters: Remove key parameters from the request (e.g., remove the data filtering parameter limit=10); Parameter replacement: Modify parameter values ​​(e.g., replace user_id=123 with user_id=456, or replace the two-factor authentication parameter with a valid value from another merchant). Of course, other types of parameter operation methods may also be included, but this application does not specifically limit these methods.

[0062] The similarity of the service response status information mentioned above can be understood as the degree of similarity between the response data before and after parameter modification, such as the returned JSON, text, etc. It is calculated using string similarity algorithms, such as the Levenshtein Distance algorithm, to quantify the impact of parameter modification on the response.

[0063] The data length mentioned above refers to the byte length of the response data or the length of the valid content, such as the number of key fields in JSON. It is used to determine whether parameter modification causes an abnormal range of returned data, such as a significant increase or decrease in data length after deleting limiting parameters.

[0064] The third detection strategy described above uses a closed-loop logic of "modifying parameters to compare responses" to detect the effectiveness of service parameter limitations and extended interface controls.

[0065] The parameter operation design can target specific interfaces, such as merchant information query interfaces and extended payment interfaces, and perform the following operations based on their parameter characteristics: Add parameters: Add permission-related parameters, such as adding dealerID=other_merchant other merchant ID to the merchant transaction query interface to test whether transaction data of unauthorized merchants can be obtained; Remove parameters: Remove parameters used for access control or data filtering, such as removing scope=my_merchant (which limits the query to only your own merchants) from the merchant list interface, and test whether it returns all merchant data; Replace parameters: Modify parameter values ​​to values ​​outside the authorized range. For example, replace access_token in the extended interface with a valid token from another entity, or modify merchant_no to the ID of another merchant, and test whether the corresponding data can be accessed.

[0066] Furthermore, we can obtain the service responses before and after the parameter modification and analyze them from two dimensions: Similarity comparison: A string similarity algorithm, such as Levenshtein Distance, is used to calculate the similarity between two responses. For example, after replacing merchant_id, if the similarity of core information such as merchant name and address in the response exceeds a preset threshold, it indicates that the parameter modification has not effectively restricted data access and may constitute unauthorized access. Data length comparison: Calculate the byte length or number of valid fields in the two responses. For example, if removing the limit parameter increases the response data length from 1024 bytes to 10240 bytes, it indicates that the parameter limit is ineffective. If the length does not change, such as returning sensitive data of the same length after replacing the parameter, the parameter may not have been actually validated.

[0067] A system can be deemed to have a vulnerability if any of the following conditions are met: Similarity exceeds a preset threshold: For example, after adding other merchant ID parameters, the similarity between the response data and the original response reaches 90% (the threshold can be adjusted according to data sensitivity), indicating that similar data can be accessed without authorization by adding parameters; No change in data length: For example, if the response data length is exactly the same as the original response after deleting the permission verification parameter and contains complete sensitive information, it indicates that the parameter restriction is not effective and there is a risk of unauthorized access.

[0068] For example, when Merchant A calls the "Transaction Record Query Interface," the original request includes merchant_id=A, returning A's transaction data (512 bytes in length). During detection, the parameter is replaced with merchant_id=B. If the response data has a similarity of 85% to the original response (exceeding the 80% threshold) and the length is still 512 bytes, a vulnerability is identified, meaning Merchant A has unauthorized access to Merchant B's transaction records.

[0069] A certain extended payment interface requires partner access to be restricted via the `partner_code` parameter. During testing, the `override_permission=true` parameter is added. If the response data length is the same as the original response (meaning it wasn't rejected), and it contains payment keys from other partners, exceeding a similarity threshold, a vulnerability is identified, allowing bypassing the interface access control by adding this parameter.

[0070] In some optional implementations, in addition to URL parameters, the scope can be extended to the modification and detection of request body parameters (such as JSON fields in POST requests), cookie parameters (such as user_session), and header parameters (such as X-Permission-Level), covering more parameter passing methods. In this regard, the embodiments of this application do not make specific limitations.

[0071] In addition to the Levenshtein Distance algorithm, the above-mentioned similarity algorithm optimizations can employ algorithms specifically designed for structured data, such as calculating the overlap of JSON fields to compare whether key sensitive fields are consistent; or semantic similarity algorithms, such as identifying the semantic consistency of response text through natural language processing, which are suitable for unstructured text responses.

[0072] In some optional implementations, in addition to comparing the total byte length, the above data length judgment can also compare the "effective data length", such as the actual content length after filtering out spaces and redundant tags, or the "number of sensitive fields", such as the number of times fields like ID card number and bank card number appear, in order to improve the accuracy of the judgment.

[0073] Regarding the judgment results, in some optional implementations, for low-privilege entities, if deleting parameters returns high-privilege data (i.e., the data length increases and contains sensitive fields), it is judged as a vulnerability. For extended interfaces, if replacing parameters returns data exceeding the scope of cooperation (i.e., the similarity exceeds the threshold), it can be judged as a vulnerability. Furthermore, the similarity threshold can also be dynamically set according to the interface type and data sensitivity, for example: Set the threshold for highly sensitive interfaces, such as bank account interfaces, to 60% (lower tolerance). The threshold for non-sensitive interfaces, such as the merchant basic category interface, is set to 90% (higher tolerance). This application does not specifically limit this aspect.

[0074] In this implementation, the system can more accurately identify the risk of unauthorized access caused by parameter limitation failure or oversight in extended interface control through the third detection strategy. In particular, for the common attack method of "parameter tampering", the system can strengthen the security protection of service parameters and extended interfaces by modifying parameters and comparing the response through double verification, thus ensuring the integrity of the permission boundaries of the merchant service system.

[0075] Optionally, the step of implementing corresponding detection strategies for different unauthorized access scenarios based on the standardized data includes: A detection request is constructed based on the standardized data and sent in an active scanning manner; Deduplicate request parameters and save multiple copies to simulate different privilege escalation scenarios; Execute corresponding detection strategies for the different unauthorized access scenarios.

[0076] In the system security detection method of this application embodiment, the above-mentioned standardized data can be understood as network traffic data after filtering, structuring and deduplication, including structured fields such as method (request method), domain (domain name), url (resource path), query (query parameters), header (request header), and response (response data), which are the basis for constructing detection requests.

[0077] The aforementioned detection request can be understood as a simulated request generated based on standardized data for testing system access control. It retains the structural characteristics of the original request, such as the request method and path, but simulates unauthorized behavior by modifying key parameters, such as permission identifiers and merchant IDs.

[0078] The above-mentioned active scanning method can be understood as the service system actively sending a detection request to the target interface, and determining whether there is an unauthorized access vulnerability by actively triggering the system response. It can be understood as a detection mode that combines "white box + gray box".

[0079] The above request parameter deduplication can be understood as performing duplicate validation on the parameters in the detection request, removing completely identical parameter combinations, such as the same user_id, merchant_id, etc., to avoid invalid duplicate tests.

[0080] The aforementioned multiple copies can be understood as retaining or generating multiple versions with different values ​​for core parameters, such as permission level, subject identifier, and data range parameters, after deduplication. These versions can be used to simulate different unauthorized scenarios, such as different merchant IDs and cookies with different permissions.

[0081] In the system security detection method of this application embodiment, targeted testing of different unauthorized scenarios is achieved through a closed-loop logic of "constructing a request to processing parameters to conducting scenario-based detection".

[0082] For example, constructing a detection request based on standardized data and sending it in an active scanning manner can be achieved in the following way: Construct the detection request: Use standardized data as a template, retain the core structure of the original request, such as method=POST, url= / merchant / info, and basic fields in the header, and only modify the key parameters related to permissions.

[0083] Active scanning involves using a scanning engine, such as an automated tool integrated into the testing environment, to send detection requests to the target interface at a preset frequency, synchronously recording the request content and system response, which may include the response status code, response body, and response time. Active scanning can operate without relying on real business traffic and can cover low-frequency but high-risk unauthorized access scenarios, such as unauthorized access to administrator interfaces.

[0084] Deduplication of request parameters involves using a hash algorithm, such as MD5, to calculate the hash value of the parameter key-value pairs and then deduplicating the request parameters. Multiple differentiated copies can then be generated for the deduplicated core parameters, each copy corresponding to a simulated privilege escalation scenario. Specifically, this can include: Entity ID Copy: Generate different entities at the same level for entity IDs such as merchant ID and user ID, such as merchant_id=A vs merchant_id=B, for horizontal privilege escalation and different level entities, such as user_id=staff vs user_id=admin, for vertical privilege escalation parameter copies; Copies of authorization credentials: For authorization credentials such as tokens and cookies, generate copies of valid low-level credentials, such as employee cookies, invalid credentials, such as empty cookies, and high-level credentials, such as administrator cookies, for use in unauthorized access and vertical privilege escalation detection; Data range parameter copy: For data filtering parameters such as limit and scope, generate copies of "deleted parameters" (e.g., no limit) and "expanded range" (e.g., limit=1000 is replaced with limit=10) for service parameter limitation scenario detection; Sensitive field parameter copy: Generates a parameter copy for enabling / disabling the display of sensitive data for parameters containing sensitive data identifiers, used for sensitive data protection scenario detection.

[0085] In some optional implementations, the saved parameter copy can be associated with a specific unauthorized access scenario, and the corresponding detection strategy can be invoked for testing. For example: To detect unauthorized access, an invalid credential copy (such as an empty cookie) can be sent to send a detection request, and a strategy of "matching preset keywords + analyzing response status codes" can be executed, such as determining whether a 200 status code and sensitive data are returned. To address vertical privilege escalation, a copy of "low-privilege credentials + high-privilege resource parameters" can be used, and the existence of vulnerabilities can be determined by the response status code and keywords. To address horizontal privilege escalation, a copy of "same permissions, different subject parameters" can be used. By assessing response similarity, such as whether the returned data is highly similar to the actual data of Merchant B, it can be determined whether a vulnerability exists. For sensitive data protection, you can use "Enable Copy of Sensitive Fields" to scan the response for any unmasked, pre-defined sensitive data. For service parameter restrictions or extended interface controls, you can use "add, delete and / or replace parameter" copies. By comparing the similarity of responses and data length before and after parameter modification, such as whether full data is returned, you can determine whether a vulnerability exists.

[0086] In some alternative implementations, parameter copies can be automatically generated based on the rules engine, for example: Generate parameter copies covering all permission dimensions in batches according to the combination rules of "permission level = low / medium / high" and "subject type = merchant / employee / administrator"; Historical vulnerability data can also be combined to prioritize generating more variants of high-risk parameters, such as merchant_id and access_token, such as random IDs and adjacent IDs, to improve detection efficiency.

[0087] In some alternative implementations, the validity of parameter copies can be periodically verified, such as whether the token has expired, and invalid copies can be automatically removed to ensure the accuracy of the detection.

[0088] In this implementation, by actively scanning, diversifying parameter copies, and matching scenario-based strategies, it is possible to ensure that various unauthorized scenarios, especially low-frequency, high-risk scenarios, are comprehensively covered, thereby improving the initiative, accuracy, and completeness of system security detection to a certain extent.

[0089] In some alternative implementations, the following steps may be performed when selecting a similarity comparison strategy: (a) such as Figure 3 As shown, the selected scanning strategy is: explicitly adopting a similarity comparison strategy; (b) such as Figure 4 As shown, configure the scan traffic: set the domain of the scan traffic (supports fuzzy search), you can choose to scan specific traffic or all traffic, and avoid whitelisted interfaces; (c) Configure permission cookies: Set Cookie1 and Cookie2 with different permissions, such as Cookie1 for merchant employees and Cookie2 for merchant administrators; (d) such as Figure 5As shown, a scanning task is generated: the scan is executed, and when the similarity between the return values ​​of two cookies is greater than a certain empirical threshold, it is determined that there is an unauthorized access situation.

[0090] See Figure 6 , Figure 6 This is a structural diagram of a system security detection device provided in another embodiment of this application.

[0091] like Figure 6 As shown, the system safety detection device 600 includes: The acquisition module 601 is used to acquire network traffic generated during system operation, filter the network traffic to obtain target traffic, and perform structured processing on the target traffic to obtain standardized data. The execution module 602 is used to execute corresponding detection strategies for different unauthorized access scenarios based on the standardized data; wherein, the unauthorized access scenarios include at least one of unauthorized access, vertical unauthorized access, and horizontal unauthorized access. The output module 603 is used to output the detection result corresponding to the execution result of the detection strategy.

[0092] Optionally, the acquisition module 601 can also be used for: Capture network traffic generated during system operation at the gateway in the test environment; Target traffic is filtered based on the preset merchant service identification information carried in the network traffic; The target traffic is structured according to a preset data structure, and a unique identifier is generated based on a hash algorithm to remove duplicate traffic data in the target traffic, thereby obtaining the standardized data.

[0093] Optionally, the unauthorized access scenarios include unauthorized access, vertical unauthorized access, and horizontal unauthorized access; The execution module 602 can also be used for: In cases where the unauthorized access scenario is an unauthorized access violation or a vertical unauthorized access violation, the detection strategy includes matching preset keywords and analyzing service response status information; In the case of a horizontal unauthorized access scenario, a first detection strategy is executed. The first detection strategy includes matching preset keywords, analyzing service response status information, and comparing the similarity of the service response status information. The detection result is deemed to have a vulnerability if any of the following conditions are met: Matching preset keywords successfully; The service response status information is abnormal; The similarity of the service response status information exceeds a preset threshold.

[0094] Optionally, the unauthorized access scenario includes sensitive data protection; The execution module 602 can also be used for: In the case of sensitive data protection in the unauthorized access scenario, a second detection strategy is executed. The second detection strategy includes scanning whether the service response status information contains preset sensitive data. If the service response status information contains preset sensitive data, the system is determined to have a vulnerability.

[0095] Optionally, the unauthorized access scenario also includes service parameter restrictions and extended interface control; The execution module 602 can also be used for: In cases where the unauthorized access scenario involves service parameter restrictions or extended interface controls, a third detection strategy is executed. The third detection strategy includes comparing the similarity and data length of service response status information before and after adding, deleting, and / or replacing parameters. The system is deemed to have a vulnerability if any of the following conditions are met: The similarity of the service response status information exceeds a preset threshold; The data length remains unchanged.

[0096] Optionally, the execution module 602 can also be used for: A detection request is constructed based on the standardized data and sent in an active scanning manner; Deduplicate request parameters and save multiple copies to simulate different privilege escalation scenarios; Execute corresponding detection strategies for the different unauthorized access scenarios.

[0097] See Figure 7 , Figure 7 This is a structural diagram of an electronic device provided in another embodiment of this application, such as... Figure 7 As shown, the electronic device includes a processor 701, a communication interface 702, a communication bus 704, and a memory 703, wherein the processor 701, the communication interface 702, and the memory 703 interact with each other through the communication bus 704.

[0098] The memory 703 is used to store computer programs; the processor 701 is used to acquire network traffic generated during system operation, filter the network traffic to obtain target traffic, perform structured processing on the target traffic to obtain standardized data, execute corresponding detection strategies for different unauthorized access scenarios based on the standardized data, and output detection results corresponding to the execution results of the detection strategies.

[0099] Alternatively, the memory 703 can also be used for: Capture network traffic generated during system operation at the gateway in the test environment; Target traffic is filtered based on the preset merchant service identification information carried in the network traffic; The target traffic is structured according to a preset data structure, and a unique identifier is generated based on a hash algorithm to remove duplicate traffic data in the target traffic, thereby obtaining the standardized data.

[0100] Optionally, the unauthorized access scenarios include unauthorized access, vertical unauthorized access, and horizontal unauthorized access; Memory 703 can also be used for: In cases where the unauthorized access scenario is an unauthorized access violation or a vertical unauthorized access violation, the detection strategy includes matching preset keywords and analyzing service response status information; In the case of a horizontal unauthorized access scenario, a first detection strategy is executed. The first detection strategy includes matching preset keywords, analyzing service response status information, and comparing the similarity of the service response status information. The detection result is deemed to have a vulnerability if any of the following conditions are met: Matching preset keywords successfully; The service response status information is abnormal; The similarity of the service response status information exceeds a preset threshold.

[0101] Optionally, the unauthorized access scenario includes sensitive data protection; Memory 703 can also be used for: In the case of sensitive data protection in the unauthorized access scenario, a second detection strategy is executed. The second detection strategy includes scanning whether the service response status information contains preset sensitive data. If the service response status information contains preset sensitive data, the system is determined to have a vulnerability.

[0102] Optionally, the unauthorized access scenario also includes service parameter restrictions and extended interface control; Memory 703 can also be used for: In cases where the unauthorized access scenario involves service parameter restrictions or extended interface controls, a third detection strategy is executed. The third detection strategy includes comparing the similarity and data length of service response status information before and after adding, deleting, and / or replacing parameters. The system is deemed to have a vulnerability if any of the following conditions are met: The similarity of the service response status information exceeds a preset threshold; The data length remains unchanged.

[0103] Alternatively, the memory 703 can also be used for: A detection request is constructed based on the standardized data and sent in an active scanning manner; Deduplicate request parameters and save multiple copies to simulate different privilege escalation scenarios; Execute corresponding detection strategies for the different unauthorized access scenarios.

[0104] The communication bus 704 mentioned in the above electronic devices can be a Peripheral Component Interconnect (PCT) bus or an Extended Industry Standard Architecture (EISA) bus, etc. This communication bus 704 can be divided into an address bus, a data bus, a control bus, etc. For ease of identification, it is represented by only one thick line in the diagram, but this does not indicate that there is only one bus or one type of data.

[0105] Communication interface 702 is used for communication between the aforementioned terminal and other devices.

[0106] The memory 703 may include random access memory (RAM) or non-volatile memory, such as at least one disk storage device. Optionally, the memory 703 may also be at least one storage device located remotely from the aforementioned processor 701.

[0107] The processor 701 mentioned above can be a general-purpose processor, including a central processing unit (CPU), a network processor (NP), etc.; it can also be a digital signal processor (DSP), an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA), or other programmable logic devices, discrete gate or transistor logic devices, or discrete hardware components.

[0108] This application also provides a computer-readable storage medium storing a computer program. When executed by a processor, this computer program implements the various processes of the above-described system security detection method embodiments and achieves the same technical effects. To avoid repetition, it will not be described again here. The computer-readable storage medium may be a read-only memory (ROM), a random access memory (RAM), a magnetic disk, or an optical disk, etc.

[0109] It should be noted that, in this document, 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 that element.

[0110] Through the above description of the embodiments, those skilled in the art can clearly understand that the methods of the above embodiments can be implemented by means of software plus necessary general-purpose hardware platforms. Of course, they can also be implemented by hardware, but in many cases the former is a better implementation method. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, can be embodied in the form of a software product. This computer software product is stored in a storage medium (such as ROM / RAM, magnetic disk, optical disk) and includes several instructions to cause a terminal (which may be a mobile phone, computer, server, air conditioner, or network device, etc.) to execute the methods described in the various embodiments of this application.

[0111] The embodiments of this application have been described above with reference to the accompanying drawings. However, this application is not limited to the specific embodiments described above. The specific embodiments described above are merely illustrative and not restrictive. Those skilled in the art can make many other forms under the guidance of this application without departing from the spirit and scope of the claims, and all of these forms are within the protection scope of this application.

Claims

1. A system security detection method, characterized in that, The method includes: The system acquires network traffic generated during system operation, filters the network traffic to obtain target traffic, and performs structured processing on the target traffic to obtain standardized data. Based on the standardized data, corresponding detection strategies are executed for different unauthorized access scenarios; Output the detection result corresponding to the execution result of the detection strategy; The privilege escalation scenarios include unauthorized access privilege escalation, vertical privilege escalation, and horizontal privilege escalation; The implementation of corresponding detection strategies for different unauthorized access scenarios includes: In cases where the unauthorized access scenario is an unauthorized access violation or a vertical unauthorized access violation, the detection strategy includes matching preset keywords and analyzing service response status information; In the case of a horizontal unauthorized access scenario, a first detection strategy is executed. The first detection strategy includes matching preset keywords, analyzing service response status information, and comparing the similarity of the service response status information. The detection result is deemed to have a vulnerability if any of the following conditions are met: Matching preset keywords successfully; The service response status information is abnormal; The similarity of the service response status information exceeds a preset threshold.

2. The method according to claim 1, characterized in that, The process of acquiring network traffic generated during system operation, filtering the network traffic to obtain target traffic, and performing structured processing on the target traffic to obtain standardized data includes: Capture network traffic generated during system operation at the gateway in the test environment; Target traffic is filtered based on the preset merchant service identification information carried in the network traffic; The target traffic is structured according to a preset data structure, and a unique identifier is generated based on a hash algorithm to remove duplicate traffic data in the target traffic, thereby obtaining the standardized data.

3. The method according to claim 1, characterized in that, The unauthorized access scenarios include sensitive data protection; The implementation of corresponding detection strategies for different unauthorized access scenarios includes: In the case of sensitive data protection in the unauthorized access scenario, a second detection strategy is executed. The second detection strategy includes scanning whether the service response status information contains preset sensitive data. If the service response status information contains preset sensitive data, the system is determined to have a vulnerability.

4. The method according to claim 1, characterized in that, The unauthorized access scenarios also include service parameter restrictions and extended interface controls; The implementation of corresponding detection strategies for different unauthorized access scenarios includes: In cases where the unauthorized access scenario involves service parameter restrictions or extended interface controls, a third detection strategy is executed. The third detection strategy includes comparing the similarity and data length of service response status information before and after adding, deleting, and / or replacing parameters. The system is deemed to have a vulnerability if any of the following conditions are met: The similarity of the service response status information exceeds a preset threshold; The data length remains unchanged.

5. The method according to claim 1 or 2, characterized in that, The implementation of corresponding detection strategies for different unauthorized access scenarios based on the standardized data includes: A detection request is constructed based on the standardized data and sent in an active scanning manner; Deduplicate request parameters and save multiple copies to simulate different privilege escalation scenarios; Execute corresponding detection strategies for the different unauthorized access scenarios.

6. A system safety detection device, characterized in that, The device includes: The acquisition module is used to acquire network traffic generated during system operation, filter the network traffic to obtain target traffic, and perform structured processing on the target traffic to obtain standardized data. The execution module is used to execute corresponding detection strategies for different unauthorized access scenarios based on the standardized data; The output module is used to output the detection result corresponding to the execution result of the detection strategy; The execution module is used for: In cases where the unauthorized access scenario is an unauthorized access violation or a vertical unauthorized access violation, the detection strategy includes matching preset keywords and analyzing service response status information; In the case of a horizontal unauthorized access scenario, a first detection strategy is executed. The first detection strategy includes matching preset keywords, analyzing service response status information, and comparing the similarity of the service response status information. The detection result is deemed to have a vulnerability if any of the following conditions are met: Matching preset keywords successfully; The service response status information is abnormal; The similarity of the service response status information exceeds a preset threshold.

7. An electronic device, characterized in that, It includes a processor, a memory, and a computer program stored in the memory and executable on the processor, wherein the computer program, when executed by the processor, implements the steps of the system security detection method as described in any one of claims 1 to 5.

8. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program that, when executed by a processor, implements the steps of the system security detection method as described in any one of claims 1 to 5.

9. A computer program product, characterized in that, It includes computer instructions, which, when executed by a processor, implement the steps of the system security detection method as described in any one of claims 1 to 5.

Images