A phishing website detection method, device, equipment and storage medium

Abstract

The application discloses a phishing website detection method and device, equipment and a storage medium, and relates to the technical field of computers. The method comprises the following steps: acquiring a URL of a website to be detected, and calculating a risk score of the website; when the score is between a first risk threshold and a second risk threshold, collecting the residual power, load, network delay, detection accuracy and trust score of a candidate cooperative device; determining a target candidate cooperative device according to the collected information, forwarding the URL and receiving the detection result of the target candidate cooperative device. The method filters the target candidate cooperative device by calculating the candidate score of the candidate cooperative device, and the score calculation is combined with the corresponding weight of each index. The weight is determined based on the business scenario requirement and can be adjusted according to the environmental state vector and the candidate score. Meanwhile, the screening and exit conditions of the candidate cooperative device are set, and the environmental perception trigger and weight shock suppression mechanism are also included, so that the accuracy, efficiency and system stability of the detection are improved.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of computers, and particularly relates to a phishing website detection method and device, equipment and a storage medium. BACKGROUND

[0002] With the rapid development and wide application of Internet technology, cyberspace has become an important place for people's life, work and study. However, network security threats have also emerged continuously, among which phishing websites as a common network fraud method have brought serious threats to users' personal information security and property safety. Phishing websites disguise as legitimate websites to induce users to input sensitive information such as account, password, bank card information, etc., thereby causing users' information leakage and property loss.

[0003] For the detection of the Uniform Resource Locator (URL) of a phishing website, the traditional scheme mainly detects through the detection method of black and white lists and the detection method based on feature matching in the local. The detection method based on black and white lists is to collect the known phishing website URL into the blacklist and collect the legitimate website URL into the whitelist, and when detecting, the URL to be detected is compared with the black and white lists, if it matches the blacklist, it is determined as a phishing website URL, and if it matches the whitelist, it is determined as a legitimate URL. The detection method based on feature matching is to analyze the common features of the phishing website URL, such as specific keywords, abnormal domain name structure, irregular subdomain name, etc., to construct a feature library, and then to extract and match the features of the URL to be detected, if it matches the features in the feature library, it is determined as a phishing website URL.

[0004] However, the local detection scheme has the problem of inaccurate detection. SUMMARY

[0005] The present application provides a phishing website detection method, device, equipment and storage medium, which can improve the accuracy of phishing website detection.

[0006] To achieve the above purpose, the present application adopts the following technical scheme:

[0007] In a first aspect, the present application provides a phishing website detection method, comprising:

[0008] obtaining the Uniform Resource Locator (URL) of a website to be detected;

[0009] calculating the risk score of the website to be detected according to the URL;

[0010] If the risk score is greater than a first risk threshold and less than a second risk threshold, obtain the remaining battery power, load status, network latency, detection accuracy, and trust score of each candidate collaborative device; the first risk threshold is less than the second risk threshold.

[0011] Based on the remaining power, load, network latency, detection accuracy, and trust score of each candidate collaborative device, the target candidate collaborative device is determined from among the candidate collaborative devices.

[0012] Forward the URL to the target candidate collaborative device;

[0013] Receive the detection results of the target candidate collaborative device for the URL of the website to be detected.

[0014] Optionally, determining the target candidate collaborative device from among the candidate collaborative devices based on their remaining power, load, network latency, detection accuracy, and trust score includes:

[0015] Based on the remaining power, load, network latency, detection accuracy, and trust score of each candidate collaborative device, the candidate score of each candidate collaborative device is calculated.

[0016] Based on the candidate scores, the target candidate collaborative device is determined from among the candidate collaborative devices.

[0017] Optionally, the step of calculating the candidate score for each candidate collaborative device based on its remaining power, load, network latency, detection accuracy, and trust score includes:

[0018] Obtain the first weight corresponding to the remaining power and load status, the third weight corresponding to the network latency, the fourth weight corresponding to the detection accuracy, and the second weight corresponding to the trust score;

[0019] The candidate scores for each candidate collaborative device are calculated based on its remaining power, load status, first weight corresponding to the remaining power and load status, network latency, third weight corresponding to the network latency, detection accuracy, fourth weight corresponding to the detection accuracy, trust score, and second weight corresponding to the trust score.

[0020] Optionally, obtaining the first weight corresponding to the remaining battery power and load status, the third weight corresponding to the network latency, the fourth weight corresponding to the detection accuracy, and the second weight corresponding to the trust score includes:

[0021] Obtain the requirements information for the business scenario;

[0022] Based on the demand information, determine the first weight corresponding to the remaining power and load status, the third weight corresponding to the network latency, the fourth weight corresponding to the detection accuracy, and the second weight corresponding to the trust score.

[0023] Optionally, the method further includes:

[0024] Based on the aforementioned requirements information, the screening criteria for the candidate collaborative devices are determined;

[0025] The candidate collaborative devices are filtered using the aforementioned screening criteria to obtain the remaining sub-candidate collaborative devices after filtering.

[0026] The process of determining the target candidate collaborative device from among the candidate collaborative devices based on their remaining power, load status, network latency, detection accuracy, and trust score includes:

[0027] Based on the remaining power, load, network latency, detection accuracy, and trust score of the remaining sub-candidate collaborative devices after filtering, the target candidate collaborative device is determined from the remaining sub-candidate collaborative devices.

[0028] Optionally, the method further includes:

[0029] Based on the aforementioned demand information, determine the exit conditions for the sub-candidate collaborative devices;

[0030] Filter out the target sub-candidate collaborative devices that meet the exit conditions from among multiple sub-candidate collaborative devices.

[0031] Optionally, the method further includes:

[0032] Obtain the environment state vector;

[0033] The first weight, the third weight, the fourth weight, and the second weight are adjusted based on the environmental state vector and the candidate scores.

[0034] Secondly, this application provides a phishing website detection device, comprising:

[0035] The acquisition module is used to obtain the Uniform Resource Locator (URL) of the website to be tested;

[0036] The data processing module is used to calculate the risk score of the website to be detected based on the URL; when the risk score is greater than a first risk threshold and less than a second risk threshold, it obtains the remaining power, load, network latency, detection accuracy, and trust score of each candidate collaborative device; the first risk threshold is less than the second risk threshold; and determines the target candidate collaborative device from among the candidate collaborative devices based on the remaining power, load, network latency, detection accuracy, and trust score of each candidate collaborative device.

[0037] The detection module is used to forward the URL to the target candidate collaborative device and receive the detection results of the target candidate collaborative device for the URL of the website to be detected.

[0038] Thirdly, this application provides a computing device, including a memory and a processor;

[0039] The memory stores one or more computer programs, the one or more computer programs including instructions; when the instructions are executed by the processor, the computing device performs the method as described in any one of the first aspects.

[0040] Fourthly, this application provides a computer-readable storage medium for storing a computer program for performing the method as described in any one of the first aspects.

[0041] As can be seen from the above technical solution, this application has at least the following beneficial effects:

[0042] This application addresses the inaccuracy issues of traditional localized phishing website detection solutions by constructing a layered detection method that combines initial risk scoring and in-depth verification using collaborative devices, effectively improving the accuracy and adaptability of detection. Specifically, a risk score is first calculated based on the URL to achieve an initial judgment. For suspicious URLs falling between the first and second risk thresholds, multi-dimensional status parameters (remaining battery power, load status, network latency, detection accuracy, and trust score) of candidate collaborative devices are introduced for comprehensive evaluation and screening. This ensures that detection tasks are assigned to target candidate collaborative devices, and the limitations of single localized detection are overcome through multi-device collaborative verification.

[0043] Meanwhile, by dynamically adjusting weights to adapt to the needs of different business scenarios, and by optimizing the collaborative device pool in conjunction with screening and exit conditions, detection efficiency is ensured and the reliability of results is improved. This enables more accurate identification of phishing websites, reduces false positives and false negatives, and provides stronger protection for users' personal information and property security.

[0044] It should be understood that the descriptions of technical features, technical solutions, beneficial effects, or similar language in this application do not imply that all features and advantages can be achieved in any single embodiment. Rather, it is understood that the description of a feature or beneficial effect means that a specific technical feature, technical solution, or beneficial effect is included in at least one embodiment. Therefore, the descriptions of technical features, technical solutions, or beneficial effects in this specification do not necessarily refer to the same embodiment. Furthermore, the technical features, technical solutions, and beneficial effects described in this embodiment can be combined in any suitable manner. Those skilled in the art will understand that embodiments can be implemented without one or more specific technical features, technical solutions, or beneficial effects of a particular embodiment. In other embodiments, additional technical features and beneficial effects may be identified in specific embodiments that do not embody all embodiments. Attached Figure Description

[0045] Figure 1 A flowchart illustrating a phishing website detection method provided in this application embodiment;

[0046] Figure 2 A schematic diagram of a phishing website detection device provided in an embodiment of this application;

[0047] Figure 3 This is a schematic diagram of a computing device provided in an embodiment of this application. Detailed Implementation

[0048] The terms “first,” “second,” and “third,” etc., used in this application are used to distinguish different objects, not to specify a particular order.

[0049] In the embodiments of this application, the terms "exemplary" or "for example" are used to indicate that something is an example, illustration, or description. Any embodiment or design that is described as "exemplary" or "for example" in the embodiments of this application should not be construed as being more preferred or advantageous than other embodiments or design. Specifically, the use of the terms "exemplary" or "for example" is intended to present the relevant concepts in a specific manner.

[0050] To ensure clarity and conciseness in the description of the following embodiments, a brief introduction to the related technologies is given first:

[0051] A Uniform Resource Locator (URL) is a string used to identify the location of a resource on the Internet. It contains information such as protocol, domain name, and path, and is the core analysis object for phishing website detection.

[0052] Traditional localized phishing website detection solutions suffer from insufficient accuracy, specifically manifested in a high rate of missed detections of new phishing URLs and a high rate of false positives for similar legitimate URLs, making it difficult to meet the security protection needs of complex network environments.

[0053] In the field of network security detection, collaborative detection, with its advantage of multi-device joint analysis, can improve the comprehensiveness and accuracy of threat identification and has become an important means of dealing with complex attack scenarios.

[0054] However, in practical applications, collaborative detection often faces scenarios where multiple devices coexist. Current mainstream solutions typically adopt a mode of randomly selecting a single device for collaboration. This approach makes it difficult to rationally allocate resources based on the device's resource load, computing power, and business adaptability. This not only easily leads to some devices having idle resources while others are overloaded, resulting in low overall resource utilization efficiency, but also makes it difficult to ensure the relevance and timeliness of collaborative detection because it cannot accurately match the real-time needs of specific business scenarios.

[0055] Therefore, how to select collaborative devices to maximize resource utilization while ensuring high compatibility with business scenarios has become a critical issue that urgently needs to be addressed, and this is the innovation of this application.

[0056] In view of this, embodiments of this application provide a method for detecting phishing websites, which can be executed by a processing device. The processing device can be a terminal or a server. Terminals include, but are not limited to, smartphones, tablets, laptops, personal digital assistants, or smart wearable devices. The server can be a cloud server, such as a central server in a central cloud computing cluster or an edge server in an edge cloud computing cluster. Alternatively, the server can be a server in a local data center. A local data center refers to a data center directly controlled by the user.

[0057] To address the shortcomings of traditional localized phishing website detection accuracy and the low resource utilization and poor scenario adaptability caused by the randomization of equipment selection in existing collaborative detection methods, this application proposes a scheme of risk-stratified screening plus dynamic collaborative equipment optimization selection.

[0058] This application constructs a layered detection framework based on URL risk scoring. First, it uses initial screening to identify suspicious URLs that genuinely require collaborative verification, reducing unnecessary resource consumption. Then, it overcomes the limitations of random selection by establishing a multi-dimensional device evaluation system. This system comprehensively considers the real-time resource status (remaining battery power, load, network latency) and historical performance (detection accuracy, trust score) of candidate collaborative devices, dynamically adjusting the weights of each dimension according to business scenario requirements to select target candidate collaborative devices. Through this method of selecting tasks on demand, allocating devices based on capacity, and adjusting strategies according to scenario, it not only solves the accuracy bottleneck of single localized detection but also achieves efficient utilization of collaborative device resources and deep adaptation to business scenarios, ultimately achieving a balance between detection accuracy, resource efficiency, and scenario adaptability.

[0059] In this application, the URL of the website to be detected is first obtained, and a risk score is calculated by analyzing its domain characteristics and structural information. A first risk threshold and a second risk threshold are set, with the first risk threshold being less than the second risk threshold. Collaborative detection is only initiated for suspicious URLs whose scores fall between the two thresholds. Subsequently, multi-dimensional parameters of candidate collaborative devices are collected, including real-time resource status and historical performance data. Based on specific business scenario requirements, dynamic weights are assigned to each parameter. For example, in high-security scenarios, the weights for detection accuracy and trust score are increased, while in high-efficiency scenarios, network latency and load conditions are emphasized. The candidate scores for each device are calculated in combination with these weights. At the same time, devices that do not meet the requirements can be filtered out through preset screening conditions, and the device with the highest score among the remaining devices is selected as the target candidate collaborative device. After forwarding the suspicious URL to the target candidate collaborative device for deep verification, the detection results fed back by the device are received to perform the final judgment. In addition, the system dynamically adjusts the parameter weights according to changes in environmental status and removes devices that consistently fail to meet the standards through exit conditions, ensuring the efficiency and reliability of collaborative detection.

[0060] To make the technical solution of this application clearer and easier to understand, the following describes a method for detecting phishing websites provided by an embodiment of this application, in conjunction with the accompanying drawings. Figure 1 As shown, this figure is a flowchart of a phishing website detection method provided in an embodiment of this application. The method further includes:

[0061] S201. The processing device obtains the Uniform Resource Locator (URL) of the website to be tested.

[0062] Obtaining the Uniform Resource Locator (URL) of the website to be detected by the processing device is the initial step in the phishing website detection process. It involves acquiring the target URL to be detected through various collection methods, providing a foundation for subsequent risk assessment and collaborative verification.

[0063] URLs can be obtained based on user behavior or rule-triggered methods. For example, when a user enters a URL in a browser or clicks a link, the terminal device can capture the URL in real time; intermediate network nodes can extract URLs contained in the network traffic they monitor; and security devices can scan a specific range of network requests according to preset rules to filter out the URLs that need to be detected.

[0064] The obtained URL must contain complete information, including the access protocol, domain name, path, parameters, and port. This information is the basis for subsequent analysis of the website's legitimacy.

[0065] After obtaining the URL, the processing device performs simple preprocessing, such as standardizing the format, removing redundant characters, unifying capitalization, filtering invalid addresses, and temporarily caching recently detected URLs to improve efficiency, ultimately providing clear and effective analysis objects for the subsequent risk scoring process.

[0066] In this embodiment, the accuracy of the detected targets is ensured from the source. Diverse data collection methods (user behavior capture, traffic monitoring, rule scanning, etc.) comprehensively cover potentially risky URLs, avoiding missed detections due to overlooking key targets. Complete acquisition of URL protocol, domain name, and path information provides a complete data foundation for subsequent feature extraction (such as domain age and random string path analysis) and risk scoring, reducing misjudgments due to missing information. Standardized processing and caching improve process efficiency; unified format ensures consistent URL parsing rules across different devices, and caching recent detection results avoids redundant calculations, especially shortening response time in high-time-sensitivity scenarios. Furthermore, preprocessing to filter invalid addresses reduces unnecessary resource consumption in subsequent collaborative detection, allowing the system to concentrate computing power on truly suspicious URLs.

[0067] S202. The processing device calculates the risk score of the website to be tested based on the URL.

[0068] The processing equipment calculates the risk score of a website to be detected based on its URL by analyzing the characteristics of the URL to quantitatively assess the likelihood that it is a phishing website. The specific process is as follows:

[0069] The processing device extracts multi-dimensional features from the acquired URLs as the basis for risk assessment. These features include: domain-related features, such as domain registration time, domain length, number of subdomains, and whether special characters are used; structural features, such as URL path complexity, whether sensitive keywords are included, and whether the port is a non-standard port; and protocol features, such as whether an insecure HTTP protocol is used.

[0070] The processing device inputs the extracted features into a preset risk scoring model, such as a machine learning-based classification model or a rule engine, and outputs a quantitative risk score through the model algorithm. The higher the score, the higher the risk.

[0071] High-risk scores trigger direct blocking, low-risk scores allow by default, while medium-risk scores initiate a collaborative detection process, thereby achieving tiered processing and balancing detection accuracy and efficiency.

[0072] From a risk differentiation perspective, through comprehensive analysis of multi-dimensional features (domain registration time, path complexity, protocol security, etc.), risk scoring can accurately quantify the suspiciousness of the website under test, avoiding misjudgments caused by relying on only a single feature. For example, a newly registered short domain name may not seem high risk on its own, but when combined with non-standard ports and sensitive keywords, the scoring model can identify its superimposed risks, improving the ability to identify complex phishing methods.

[0073] From the perspective of process optimization, the quantitative risk scoring realizes the hierarchical nature of detection strategies: high-risk URLs are directly blocked to quickly intercept obvious threats, low-risk URLs are allowed by default to reduce unnecessary resource consumption, and medium-risk URLs trigger collaborative detection to balance accuracy and efficiency. This hierarchical processing method allows the system to dynamically allocate computing power according to the risk level.

[0074] From the perspective of collaborative detection support, risk scoring clarifies the direction of subsequent processes. For example, a medium risk score (0.5-0.9) provides triggering conditions for task migration and cross-device verification, ensuring that collaborative detection between edge terminals and smart devices is more targeted, avoiding resource waste caused by blindly allocating tasks, and ultimately improving the response speed of the entire distributed detection system.

[0075] S203. When the risk score is greater than the first risk threshold and less than the second risk threshold, obtain the remaining power, load, network latency, detection accuracy and trust score of each candidate collaborative device.

[0076] The first and second risk thresholds are critical values ​​used by the processing device to classify URL risk levels, with the first risk threshold being lower than the second risk threshold. For example, the first risk threshold is set to 0.5, and the second risk threshold is set to 0.9. Specifically, a risk score less than or equal to 0.5 is classified as low risk, a risk score between 0.5 and 0.9 is classified as medium risk, and a risk score greater than or equal to 0.9 is classified as high risk.

[0077] Candidate collaborative devices refer to terminals or nodes with collaborative detection capabilities, such as smart terminals and edge devices, which can participate in the verification of suspicious URLs and help improve detection accuracy.

[0078] Remaining battery power is the current percentage of battery power remaining in the candidate collaborative device, reflecting the device's endurance for performing collaborative tasks. Low battery power may cause task interruption.

[0079] Load status refers to the current resource usage of candidate collaborative devices, such as CPU utilization and memory utilization, reflecting the computing power redundancy of the devices. Excessive load will reduce detection efficiency.

[0080] Network latency is the communication delay between candidate cooperating devices and processing devices, such as the time it takes for data transmission, which affects the real-time performance of cooperative detection.

[0081] Detection accuracy is the percentage of correct results achieved by candidate collaborative devices in completing detection tasks throughout history. It reflects the detection capability of the devices, and devices with higher accuracy produce more reliable detection results.

[0082] Trust scores are dynamic metrics calculated based on a device's historical behavior to measure its trustworthiness. Devices with low scores may pose a malicious risk.

[0083] When the processing device calculates that the risk score of the URL to be detected falls between the first and second risk thresholds, classifying it as a medium-risk URL, further verification is required. The system will initiate a collaborative detection mode, querying candidate collaborative devices in the network to collect key status data for each device, including remaining battery power to ensure the device can complete the task; load status to avoid delays caused by device overload; network latency to ensure data transmission efficiency; detection accuracy to prioritize devices with strong judgment capabilities; and trust score to aggressively eliminate unreliable devices. This data will serve as the basis for subsequent screening of target candidate collaborative devices, ensuring that collaborative detection is both efficient and reliable.

[0084] From a precise screening perspective, by acquiring key indicators such as the remaining battery power and load status of candidate collaborative devices, comprehensive quantitative data is provided for subsequent device selection. For example, prioritizing devices with high detection accuracy and low network latency can directly improve the reliability and real-time performance of collaborative verification; while excluding devices with low trust scores or high loads can avoid detection biases caused by unreliable devices or task timeouts caused by insufficient resources, ensuring that the candidate collaborative devices participating in the collaboration truly possess the ability to assist in verification.

[0085] From a process adaptation perspective, initiating data collection only in medium-risk scenarios avoids resource waste caused by low-risk URLs that do not require collaboration, and differs from the direct blocking of high-risk URLs. By collecting device status data in a targeted manner, it achieves refined tiered processing. For example, when the URL risk score is between 0.5 and 0.9, it prevents missed detections and does not directly block the URL. Instead, it lays the foundation for the next step of screening collaborative devices by collecting device data, making the detection of medium-risk URLs both rigorous and efficient.

[0086] From a system collaboration perspective, the collection of this device status data also provides real-time reference for subsequent weight adjustments and task allocation. For example, when most candidate collaborative devices have low remaining power, the system can preemptively select devices with high power or adjust energy consumption weights to ensure battery life, allowing collaborative detection to remain adaptable in environments with dynamically changing resources and improving the entire detection system's ability to identify complex, medium-risk URLs.

[0087] S204. Based on the remaining power, load, network latency, detection accuracy, and trust score of each candidate collaborative device, determine the target candidate collaborative device from among the candidate collaborative devices.

[0088] The target candidate collaborative device is the device selected from all candidate collaborative devices that is most suitable for performing the current phishing website deep verification task.

[0089] By evaluating and selecting the most suitable equipment for the current testing task from multiple dimensions, we can ensure the testing effect and optimize resource utilization.

[0090] Specifically, the processing device first collects five parameters from all candidate collaborative devices: remaining battery power, load status, network latency, detection accuracy, and trust score. Through quantitative evaluation and scenario-based weight allocation, it calculates the comprehensive compatibility score for each device. Subsequently, the devices are sorted by score and combined with hard criteria to ultimately select the devices with the highest scores as target candidate collaborative devices.

[0091] In this embodiment, the problem of resource waste or unreliable results caused by random device selection can be avoided, ensuring that collaborative detection can be completed efficiently and output reliable results, while adapting to specific business scenario requirements and improving the accuracy of medium-risk URL determination.

[0092] Based on the remaining battery power, load status, network latency, detection accuracy, and trust score of each candidate collaborative device, a candidate score is calculated for each candidate collaborative device. Based on the candidate scores, the target candidate collaborative device is selected from among the candidate collaborative devices.

[0093] The candidate score is a comprehensive score obtained by quantitative calculation after considering the remaining power, load, network latency, detection accuracy, and trust score of the candidate collaborative devices. It is used to measure the suitability of the device for the current detection task. The higher the score, the more suitable the device is to perform the task.

[0094] Specifically, the processing equipment first standardizes the five parameters mentioned above, for example, by converting them into values ​​between 0 and 1, thus eliminating the dimensional differences between different indicators. The expression for standardizing the five parameters is as follows:

[0095] The remaining battery power is calculated as follows:

[0096]

[0097] in, Indicates the standardized remaining power. Represented as the first coefficient, , Indicates the remaining battery power. The remaining battery power threshold. .

[0098] The load conditions are calculated as follows:

[0099]

[0100] in, Indicates the standardized load condition. This indicates the maximum load value. , This indicates the load status.

[0101] Network latency is calculated as follows:

[0102]

[0103] in, Indicates standardized network latency. Indicates the network latency threshold. , This indicates network latency.

[0104] The detection accuracy is calculated as follows:

[0105]

[0106] in, Indicates the accuracy of the test. This represents historical accuracy, based on the average accuracy of the device's past N detection tasks. To predict accuracy, a lightweight prediction model (such as LSTM) is used to predict the possible accuracy of the current detection task.

[0107] Trust score is calculated as follows:

[0108]

[0109] or

[0110]

[0111]

[0112] in, Indicates standardized trust score, Indicates the initial trust score. For the updated trust score, This indicates the change in trust rating. This represents the reward impact coefficient. This represents the penalty impact coefficient. Indicates positive return value. Indicates the negative loss value. Indicates the attenuation coefficient. Indicates duration, Indicates trust rating, This represents the minimum trust score. , This represents the maximum trust score. .

[0113] Trust scores are calculated based on reward and punishment methods and a time decay factor. If all tasks are successfully completed, then... =1. If partially completed and with an accuracy rate greater than 80%, then =0.5. If data tampering or falsified results occur, then... =1. If all tasks fail or the task times out, then =0.3.

[0114] To avoid a surge in trust value due to a single success, The penalties must be greater than the rewards; the cost of preventing wrongdoing is too low. =0.1; =0.02 / hour, which means the decay is about 2% per hour.

[0115] The following are specific examples:

[0116] Assuming a device has an initial trust score... =0.7, if all tasks are completed successfully, then:

[0117] ,

[0118] If data tampering subsequently occurs, then:

[0119]

[0120] If you do not participate in the task for three consecutive days, then:

[0121]

[0122] When the value is below 0.5, the device will be automatically disabled, meaning that the device must not participate in the testing task.

[0123] Next, obtain the first weight corresponding to the remaining power and load status, the third weight corresponding to the network latency, the fourth weight corresponding to the detection accuracy, and the second weight corresponding to the trust score.

[0124] The first weight for remaining battery power and load status refers to the importance percentage assigned to the energy consumption dimension when evaluating candidate collaborative devices, combining remaining battery power and load status. Remaining battery power reflects the device's battery life, while load status reflects the device's resource occupancy status. Together, they measure the rationality of the energy consumption of the device in performing tasks. The higher the weight value, the greater the focus on device energy consumption in this scenario.

[0125] The third weight corresponding to network latency refers to the proportion of importance of network latency in the evaluation, that is, the third weight, which reflects the importance attached to the real-time performance of detection. The higher the weight, the more stringent the requirements of the scenario for communication efficiency.

[0126] The fourth weight corresponding to detection accuracy refers to the proportion of importance of detection accuracy in the evaluation, that is, the fourth weight, which reflects the degree of importance attached to the reliability of the detection results. The higher the weight, the more urgent the need for accurate identification of phishing websites in the scenario.

[0127] The second weight corresponding to the trust score refers to the proportion of importance of the trust score in the evaluation, that is, the second weight, which reflects the degree of importance attached to the trustworthiness of the device. The higher the weight, the more stringent the requirements of the scenario for device anti-tampering and task completion.

[0128] Specifically, remaining battery power and load status are combined into an energy consumption dimension, which, along with network latency, detection accuracy, and trust score, forms the four dimensions for evaluating device compatibility. The processing device will determine the first, third, fourth, and second weights for each of these four dimensions based on the core requirements of the current business scenario (such as high timeliness, high trust, high accuracy, and low battery scenarios). The sum of these weights is typically 1.

[0129] First, the device acquires the required information for the business scenario; based on the required information, the first weight corresponding to the remaining power and load status, the third weight corresponding to the network latency, the fourth weight corresponding to the detection accuracy, and the second weight corresponding to the trust score are determined.

[0130] The processing equipment collects real-time data such as network status, task type, and device resources to extract the core requirements of the scenario, laying the foundation for subsequent weight allocation based on the scenario and ensuring that the collaborative detection strategy is deeply matched with business objectives.

[0131] The processing device collects indicators such as network latency and data transmission time between devices in real time. If the network latency is detected to be consistently lower than the baseline value and the task type is marked as real-time response, such as power emergency dispatch command link or user instant operation request, it is determined to be a high-time-efficiency scenario. At the same time, combined with the task queue length, if the task requires the detection to be completed in a very short time (such as within 1 second), the processing device will prioritize the identification of it as a high-time-efficiency scenario with speed as the core.

[0132] The processing device analyzes the data types of the business associated with the URL to be detected. If it involves sensitive data such as power grid operation instructions, user privacy information (such as electricity account passwords), or power dispatch parameters, the processing device will determine it as a high-trust scenario.

[0133] The processing device collects the remaining battery percentage of all candidate collaborative devices every 10 minutes, summarizes the remaining battery data, and calculates the average battery level. If the average battery level is lower than the threshold, or more than 60% of the devices have batteries lower than the critical value, and the device type is a mobile terminal (such as inspection drones, smart safety helmets, which rely on battery power), then it is determined to be a low battery scenario.

[0134] During the initial edge screening stage, when the processing device extracts URL features using a pruned and optimized gradient boosting classifier, if it finds that a URL has new phishing features or matches the features of historical URLs with high false positive rates, it determines that the scenario requires high-precision detection. Combined with historical system data, if the missed detection / false positive of this type of URL has led to security incidents (such as the leakage of user information), the processing device will automatically mark it as a high-accuracy scenario.

[0135] In summary, the core needs of different scenarios determine the differentiated allocation of the four weights. The third weight, corresponding to network latency, reflects the real-time nature of communication between devices; lower latency means higher transmission efficiency. In high-time-sensitivity scenarios, the third weight is the highest, at 0.5, prioritizing low-latency devices; in scenarios where network outages or other non-network-dependent scenarios, the weight can be reduced to 0.

[0136] The fourth weight corresponding to detection accuracy reflects the correctness rate of the device's historical detections; higher accuracy means more reliable results. In high-accuracy scenarios, the fourth weight is the highest, at 0.5, prioritizing devices with high historical accuracy rates; in scenarios where speed is emphasized, the weight can be appropriately reduced.

[0137] The second weight corresponding to the trust score reflects the reliability of the device. Based on historical behavior, a higher score is awarded for no data tampering and high task completion rate. In high-trust scenarios, the second weight is the highest, at 0.4, to strictly screen devices with high trust scores; in non-sensitive scenarios, the weight can be appropriately reduced.

[0138] The initial weight settings are shown in the table below, depending on the different scenario types.

[0139] Table 1: Initial weight table.

[0140]

[0141] in, This indicates the first weight corresponding to the remaining battery power and the load status. The third weight represents the network latency. This represents the fourth weight corresponding to the detection accuracy. This represents the second weight corresponding to the trust score.

[0142] By assigning weights, the matching between scenario requirements and parameter importance is achieved, ensuring that the subsequent comprehensive score can truly reflect the device's adaptability to the current task and providing a reasonable quantitative standard for selecting target candidate collaborative devices.

[0143] Finally, based on the remaining power, load status, the first weight corresponding to the remaining power and load status, network latency, the third weight corresponding to the network latency, detection accuracy, the fourth weight corresponding to the detection accuracy, trust score, and the second weight corresponding to the trust score of each candidate collaborative device, the candidate score is calculated. The calculation expression is:

[0144]

[0145] in, Indicates the candidate score.

[0146] The table above shows the selection criteria for candidate collaborative devices based on the demand information.

[0147] The core requirement for high-time-sensitivity scenarios is that tasks need to be responded to quickly. For example, the detection of emergency power dispatch instructions places high demands on network communication efficiency and equipment processing speed.

[0148] The filtering criteria are the core triggering indicator and the auxiliary constraint indicators listed in the table above. Network latency. The latency must be less than or equal to 50ms to ensure smooth data transmission without noticeable lag; load conditions. The load should be less than or equal to 40%, and low-load devices should be able to quickly start the detection task to avoid delays caused by insufficient computing power; Trust scoring. Requires a value greater than or equal to 0.7, accepts devices with moderate trust levels, does not strictly limit historical behavior, and prioritizes speed.

[0149] The core requirement for high-accuracy scenarios is that the URL to be detected is a new type of phishing website or is associated with sensitive business (such as user electricity account login), and the detection accuracy must be guaranteed as a priority.

[0150] The filtering criterion is: historical accuracy. It needs to be greater than or equal to 0.8 and have a prediction accuracy rate. The accuracy needs to be greater than or equal to 0.8. Requires a remaining battery level of 92% or higher. It needs to be greater than or equal to Trust rating It needs to be greater than or equal to 0.8 to prevent the device from forging high accuracy results, and the device must have no history of data tampering.

[0151] The core requirement for high-trust scenarios is that the detection task involves power grid operation instructions and private data (such as employee account information), and it is necessary to strictly prevent malicious behavior of equipment or data fraud.

[0152] Filtering criteria: Trust score A value greater than or equal to 0.9 is required to directly exclude devices with historical records of tampering or timeouts; detection accuracy is also important. A value greater than or equal to 0.8 is required to ensure reliable results and avoid security incidents caused by misjudgment.

[0153] The core requirement for low-battery scenarios is that most of the candidate collaborative devices are mobile terminals (such as inspection drones and smart safety helmets), and their overall battery levels are low, so it is necessary to prioritize ensuring battery life.

[0154] Filter criteria: Remaining battery power It needs to be less than or equal to 30%, especially if... The third weight corresponding to network latency less than or equal to 20%. Adjusted to 0.6; Load conditions C It needs to be less than or equal to 70%.

[0155] Candidate collaborative devices are filtered using screening criteria to obtain the remaining sub-candidate collaborative devices.

[0156] After determining the scenario-based screening criteria, the processing device compares the real-time data of all candidate collaborative devices with the screening criteria one by one, eliminating devices that do not meet the criteria. The final set of retained devices is the sub-candidate collaborative device. The essence of this process is to select suitable devices from the candidate pool, ensuring that subsequent evaluation and task allocation are more focused on devices that meet the scenario requirements, thereby improving efficiency and reliability.

[0157] Filtering process for high-time-sensitivity scenarios:

[0158] network latency ≤50ms, load conditions ≤40%, Trust Score A score of ≥0.7 was used as the screening criterion, and each candidate collaborative device was verified individually.

[0159] If a certain inspection drone has a network latency of 45ms (≤50ms), a CPU load of 35% (≤40%), and a trust score of 0.75 (≥0.7), it meets all three conditions and is retained as a sub-candidate collaborative device. If a smart meter has a network latency of 60ms (>50ms), or a mobile terminal has a CPU load of 45% (>40%), it is directly eliminated because it does not meet the core conditions. The remaining sub-candidate collaborative devices all have the characteristics of low latency, low load, and medium trust, and can efficiently respond to real-time tasks such as emergency power dispatch instructions.

[0160] Filtering process for high-accuracy scenarios:

[0161] Based on detection accuracy ≥92% (historical accuracy) ≥0.8 and prediction accuracy ≥0.8), remaining battery power ≥50%, Trust Score Standard screening ≥0.8:

[0162] If a smart safety helmet has a historical accuracy rate of 0.82, a prediction accuracy rate of 0.85 (overall accuracy ≥ 92%), a remaining battery level of 60% (≥ 50%), and a trust score of 0.85 (≥ 0.8), and all three criteria are met, it will be included as a sub-candidate collaborative device. If a device has a historical accuracy rate of 0.78 (< 0.8) resulting in an overall accuracy rate of less than 92%, or a remaining battery level of 45% (< 50%), or a trust score of 0.75 (< 0.8), it will be excluded because it does not meet the criteria. All sub-candidate collaborative devices have high detection accuracy, sufficient battery power, and high reliability, and can accurately identify new phishing websites or ensure the reliability of sensitive business detection results.

[0163] Filtering process for high-trust scenarios:

[0164] According to trust rating ≥0.9, Detection accuracy Hard constraint filtering with a value ≥0.8:

[0165] If a drone has a trust score of 0.92 (≥0.9) and a detection accuracy of 0.85 (≥0.8), it meets the reliability requirements of high-trust scenarios and is retained as a sub-candidate collaborative device. If a device has a history of data tampering, a trust score of 0.88 (<0.9), or a detection accuracy of 0.75 (<0.8), it is eliminated due to security risks. All sub-candidate collaborative devices are reliable nodes with high trust and high accuracy, capable of securely handling sensitive tasks such as power grid operation commands and privacy data.

[0166] The filtering process for low-power scenarios:

[0167] Based on remaining battery power If a smart safety helmet has 25% (≤30%) battery remaining and a load of 60% (≤70%), it meets the requirements for battery life and resource usage in low-battery scenarios and is retained as a sub-candidate collaborative device. If an inspection robot has 35% (≥30%) battery remaining or a load of 80% (>70%), it is excluded if either condition is not met. The final selected sub-candidate collaborative devices are all mobile terminals that meet the low-battery and low-load conditions. These devices can ensure basic battery life in low-battery scenarios, avoiding interruptions to the detection task due to power outages, and can participate in collaborative detection with moderate resource usage, ensuring efficient task progress.

[0168] In summary, this filtering process, by strictly matching the scenario selection criteria, eliminates false candidates from the initial candidate collaborative devices, and the final sub-candidate collaborative devices are a high-quality candidate pool that is highly adapted to the current scenario requirements.

[0169] After filtering by screening criteria, the sub-candidate collaborative devices have the following characteristics: all sub-candidate collaborative devices meet the core requirements of the current scenario, such as devices in high-trust scenarios are reliable and devices in high-time-efficiency scenarios have low latency; devices that do not meet the criteria are eliminated, reducing the computational load of subsequent evaluation and improving system efficiency; the sub-candidate collaborative devices are the basis for subsequent selection of target candidate collaborative devices based on candidate scores, ensuring that the finally selected devices can efficiently complete the detection task.

[0170] Finally, based on the remaining power, load, network latency, detection accuracy, and trust score of the remaining sub-candidate collaborative devices after filtering, the target candidate collaborative device is determined from the remaining sub-candidate collaborative devices.

[0171] The selected candidate collaborative devices meet the basic requirements of the scenario, but further quantitative evaluation through multi-dimensional indicators is still needed to determine the target candidate collaborative device. The processing device will combine scenario requirements to perform weighted calculations on the remaining power, load, network latency, detection accuracy, and trust score of each candidate collaborative device, and finally select the device with the best overall performance as the target candidate collaborative device to ensure efficient and reliable task execution.

[0172] The table above also includes an indicator for exit criteria. Based on the demand information, the exit criteria for sub-candidate collaborative devices are determined.

[0173] Sub-candidate collaborative devices are adapted devices that have undergone initial screening, but their status (such as remaining battery power, trust score, network latency, etc.) may change before or during task execution. The exit condition is essentially a dynamic verification method. Based on scenario requirements, a bottom-line threshold is set for core indicators. When a device's indicators fall below the bottom line, it is determined that it is no longer suitable for the scenario and is forcibly removed from the sub-candidate collaborative device list.

[0174] Exit criteria for high-trust scenarios: Trust score Alternatively, the device may malfunction. If the device experiences data tampering (e.g., a smart terminal forging certificate verification results to pass phishing website detection), continuous task failures (e.g., failing to return detection results on time three times), or prolonged inactivity causing the trust score to drop from 0.9 to 0.75, it will be forced to exit. If the device exhibits abnormalities such as a broken communication encryption link or frequently sending contradictory data (e.g., an inspection drone sometimes reporting a URL as secure and sometimes marking it as risky), it will be forcibly exited even if the trust score is not lower than 0.8.

[0175] Exit conditions for high-time-sensitivity scenarios: network latency Or load conditions If the communication delay between the substation edge terminal and the smart safety helmet increases from 50ms to 120ms due to signal interference, or if the CPU load of the inspection robot jumps from 40% to 65% due to simultaneously handling data acquisition and detection tasks, the real-time response requirement will no longer be met, and the device will be removed from the sub-candidate collaborative device list.

[0176] Exit conditions for high-accuracy scenarios: detection accuracy Alternatively, the task may be simplified. When a device's accuracy in recognizing new AI-generated phishing pages drops from 0.85 to 0.78, or when bandwidth limitations prevent the device from executing script analysis due to only transmitting URL fragments, and the task is simplified to single feature matching, the device will be removed from the list of sub-candidate collaborative devices.

[0177] Exit conditions for low battery scenario: Remaining battery power For example, if an inspection drone's battery level remains at 60%, far exceeding the basic battery life required for the scenario, or if a smart meter is always fully charged because it is connected to mains power, these types of devices will be deactivated to prioritize ensuring the battery life of mobile terminals with 30%-50% battery level.

[0178] Filter out target sub-candidate cooperative devices that meet the exit conditions from among multiple sub-candidate cooperative devices.

[0179] In the distributed phishing website detection process, once the pool of sub-candidate collaborative devices is formed, the status of all devices in the pool will be continuously monitored and dynamically evaluated in real time. Based on the exit conditions preset for different business scenarios, target sub-candidate collaborative devices that no longer meet the requirements of the scenario will be identified and filtered out.

[0180] From the perspective of scenario adaptability, this process dynamically eliminates devices that do not meet the core requirements of the current scenario. For example, devices with a trust score below 0.8 in high-trust scenarios and devices with excessive latency in high-timeliness scenarios ensure that the target candidate collaborative devices are always highly matched with the scenario target. This avoids efficiency losses or potential risks caused by unqualified devices participating in the detection. For example, eliminating low-precision devices in high-accuracy scenarios can directly reduce the probability of missed detections and false judgments; filtering high-battery devices in low-battery scenarios can prioritize ensuring the battery life of mobile terminals and prevent resource misallocation.

[0181] Furthermore, real-time filtering of devices that meet the exit criteria can promptly avoid the chain reaction caused by device anomalies: for example, removing devices with communication anomalies in high-trust scenarios can prevent tampering or leakage during data transmission; removing high-load devices in high-time-efficiency scenarios can prevent them from slowing down the overall detection rhythm and causing task timeouts.

[0182] In this embodiment, a limited number of detection tasks can be centrally allocated to continuously qualified devices, reducing the consumption of computing and communication resources on redundant devices. For example, in low-power scenarios, the focus can be on devices with 30%-50% battery power, which can meet the detection requirements and avoid unnecessary power consumption by high-power devices, ultimately improving the stability of the entire distributed detection system.

[0183] S205. The processing device forwards the URL to the target candidate collaborative device.

[0184] The processing device encrypts suspicious URLs that need to be forwarded, such as through encryption methods using 5G / Bluetooth communication protocols, to prevent them from being hijacked or tampered with during transmission. This is especially important in high-trust scenarios, where encryption can ensure data security in sensitive URLs involving power grid operation commands.

[0185] Based on the communication capabilities of the target candidate collaborative devices, such as support for wireless communication methods like 5G and Bluetooth, the processing device selects the optimal transmission path to send the URL. For example, for devices that support 5G, such as inspection drones, the URL is forwarded via a high-speed 5G network to meet the real-time requirements of high-efficiency scenarios; for devices that only support Bluetooth, such as smart meters, short-range Bluetooth transmission is used to meet the local collaborative needs of low-power scenarios.

[0186] While forwarding the URL, the processing device will also include the core requirements of the detection task, such as performing multimodal feature analysis in high-accuracy scenarios and prioritizing the control of computing power consumption in low-power scenarios, to ensure that the target candidate collaborative device performs detection according to the scenario requirements.

[0187] In high-trust scenarios, when a processing device forwards a suspicious URL involving power grid operation instructions to a target candidate collaborative device, it will attach additional device authentication information to ensure that the URL is only received by authorized devices and prevent malicious devices from intercepting sensitive data.

[0188] In high-time-efficiency scenarios, the forwarding process emphasizes low latency. The processing device will prioritize target candidate cooperative devices with network latency <50ms and compress non-critical information attached to the URL to speed up the transmission.

[0189] In high-accuracy scenarios, the forwarded URL will contain more auxiliary information, helping the target candidate collaborative device to perform high-precision detection such as script parsing and certificate verification more efficiently.

[0190] In low-power scenarios, the processing device will forward the URL to the target candidate collaborative device with 30%-50% remaining power and limit the amount of data transmitted in a single transmission to avoid the device's battery life being affected by excessive communication power consumption.

[0191] This operation is a key bridge connecting device screening and in-depth detection. By accurately forwarding the URL to the target candidate collaborative device, the distributed division of labor for detection tasks is realized: the edge terminal is responsible for initial screening and scheduling, while the target candidate collaborative device is responsible for in-depth verification. This not only leverages the advantages of edge computing in terms of localization and low latency, but also makes up for the limitations of computing power or functionality of a single device through multi-device collaboration, providing multi-dimensional detection data for the determination of phishing websites.

[0192] S206. The processing device receives the detection results of the target candidate cooperative device for the URL of the website to be detected.

[0193] The results returned by the target candidate collaborative devices not only include a risk score for the URL to be detected (e.g., 0.95 indicates high risk), but also the basis for the detection. For example, a drone might return a screenshot similarity score of 0.7, while a smart helmet might return that malicious scripts have been detected.

[0194] The result transmission uses the same encryption method as URL forwarding, such as symmetric encryption. After receiving the data, the processing device will first verify the data integrity and device identity to ensure that it comes from the target candidate collaborative device and not a forged node. Especially in high-trust scenarios, it is necessary to strictly prevent the result from being tampered with.

[0195] If there are multiple target candidate collaborative devices, such as drones and smart safety helmets in high-trust scenarios, the processing device will receive the results from all devices to form a multi-dimensional dataset, providing a data foundation for judgment.

[0196] By aggregating the results from multiple target candidate devices, the processing equipment can both overcome the limitations of single-device detection and reduce the risk of misjudgment through comparison of multiple results. For example, in a high-trust scenario, after receiving the image matching result of a drone (0.7), the script analysis result of a smart safety helmet (0.99), and the certificate verification result (0.85), the processing equipment calculates a comprehensive risk score of 0.913 through weighted fusion, ultimately determining it to be a phishing website and blocking it. This demonstrates the core value of aggregating results from multiple devices for accurate decision-making.

[0197] Meanwhile, the processing device updates the trust score and detection accuracy of the device based on the received results. If the result of a device is consistent with the final judgment, the trust score increases by 0.05, providing a dynamic basis for device screening in subsequent scenarios and forming a self-optimization closed loop of the system.

[0198] The method also includes an environment-aware triggering mechanism, which triggers every [time period]. (Default 15 minutes) Or a weight reassessment will be triggered when the following key metrics changes exceed the threshold:

[0199] Overall network latency change rate:

[0200] ,

[0201] in, Current network latency (unit: milliseconds ms) The baseline network latency is the average latency over a period of time. The delay change rate threshold is used to trigger a weight re-evaluation when the delay change rate threshold exceeds 0.2, i.e., 20%.

[0202] System average accuracy rate of change:

[0203] ,

[0204] This represents the current system's average accuracy; for example, 0.95 means 95%. The baseline accuracy is the average accuracy over a past period. This is the accuracy change rate threshold. When the accuracy change rate threshold exceeds 0.1, i.e., 10%, a weight re-evaluation is triggered.

[0205] Rate of change in the number of available devices:

[0206] ,

[0207] The number of currently available devices (unit: units). The baseline number of devices is the average number of available devices over a past period. This is the threshold for the rate of change in the number of devices. When the rate of change in the number of devices exceeds 0.3, i.e., 30%, a weight reassessment is triggered.

[0208] The task failure rate has suddenly increased:

[0209] ,

[0210] The current task failure rate. The baseline failure rate is the average failure rate over a past period. The absolute difference threshold for the failure rate is used to trigger a weight reassessment when the absolute difference threshold for the failure rate increases by more than 0.15 or 15 percentage points.

[0211] The formula for calculating the current task failure rate is:

[0212]

[0213] in, This indicates the current number of failed tasks. This indicates the current total number of tasks.

[0214] From a timeliness perspective, the dual triggering mechanism—both periodic (default 15 minutes) and event-based (key indicator exceeding limits)—can continuously monitor system status and quickly capture sudden changes. For example, if network latency suddenly increases from a baseline of 100ms to 130ms (a change rate of 30% or more), it can effectively prevent such changes. When the failure rate reaches 20%, a weight reassessment is immediately triggered to prevent timeouts in high-timeliness scenarios due to continuously increasing latency; the task failure rate suddenly increases from 5% to 21% (difference 16% > 20%). When the failure rate reaches 15%, adjustments should be initiated promptly to prevent the cumulative impact of failed tasks on system reliability.

[0215] From an accuracy perspective, triggering adjustments based on quantified thresholds avoids the blind and frequent nature of weight adjustments. For example, when the system's average accuracy drops from 85% to 76% (a change rate of 10.5% > 10.5%), the system can adjust the weights accordingly. When the accuracy rate is less than 10%, by increasing the weight of detection accuracy and prioritizing the screening of high-accuracy equipment, the downward trend in accuracy can be quickly curbed; the number of available equipment increases from 20 to 30 (change rate > 50%). When the percentage is 30%, adjust the weights to broaden the screening scope and make full use of the new resources.

[0216] From the perspective of system resilience, this solution ensures that the weight adjustment is always deeply tied to the current environmental state, so as to ensure that the importance of core indicators is dynamically balanced according to the scenario: when the network is smooth, the latency weight is emphasized; when there is a shortage of equipment, some conditions are relaxed; and when the failure rate increases, the trust score weight is strengthened.

[0217] The processing device acquires the environmental state vector, expressed as:

[0218]

[0219] in, Indicates the first The environment state vector at time t, For average network latency, The system's average accuracy. The average device trust score ranges from 0 to 1. Average device energy consumption, such as the percentage of remaining battery power. The number of active devices, This represents the average task failure rate.

[0220] Adjust the first weight, third weight, fourth weight and second weight based on the environmental state vector and candidate scores.

[0221] The processing device first analyzes the characteristics of the environmental state vector to identify the core contradictions of the current system, such as... A sudden increase indicates network congestion. An increase indicates insufficient device reliability. At the same time, by combining the candidate score distribution, we can determine which indicators have the greatest impact on device adaptability. For example, devices with high trust scores among the candidate scores generally have higher scores, indicating that trust is more critical in the current scenario.

[0222] The expression for adjusting the weights is:

[0223]

[0224] in, For the first Time of the first The new values ​​for each weight, For the first Time of the first The value of each weight. For learning rate, ; It is the first The set of weight vectors at time t is the first set of weight vectors. The set of all weights at any given time (in vector form). For the first The environment state vector at any given time; The state-weight value function is approximated by a neural network. The machine learning framework used here is PARC, which is used to evaluate the state. The following uses weights The long-term benefits, that is, using the current moment The weight set below In state Allocate equipment and assess future long-term benefits; Value function Weights The gradient, i.e., the partial derivative, The real-time candidate scores for the current period; The average candidate score over the past M periods.

[0225] This method also includes a weight oscillation suppression mechanism to prevent system instability caused by frequent weight adjustments. The following restrictions are applied to weight adjustments:

[0226] For time window Limitations, equal weight within the time window ,For example =Adjustments can be made at most once every 30 minutes.

[0227] Limitations on the magnitude of changes: The magnitude of a single weight adjustment shall not exceed [a certain limit]. =0.1, where, This indicates the upper limit of a single weight adjustment.

[0228] Smooth transition method: Weight smoothing is performed using an exponential moving average. The expression is:

[0229]

[0230] in, These are the smoothed weight values. The old weight values ​​before adjustment. For the calculated new weight values, This is the smoothing coefficient (weighting factor). These are complementary smoothing coefficients.

[0231] From the perspective of system stability, the time window limit (the same weight can be adjusted at most once within 30 minutes) and the single magnitude limit (not exceeding 0.1) directly curb weight fluctuations caused by small fluctuations in environmental indicators. For example, when network latency fluctuates slightly around the threshold for a short period of time, the weight will not be repeatedly adjusted accordingly, ensuring the consistency of device screening standards and avoiding chaos in collaborative detection due to frequent weight changes.

[0232] From a smooth transition perspective, the exponential moving average method uses a weighted fusion of old and new weights to make weight adjustments transition from abrupt to gradual. For example, when the detection accuracy weight needs to be increased from 0.2 to 0.3, after smoothing, it may first transition to 0.23 and then gradually approach the target value. This not only responds to the adjustment needs but also avoids sudden switching of the device screening logic due to abrupt changes in weights, ensuring the smooth operation of core processes such as high-accuracy scenarios.

[0233] From a resource efficiency perspective, this solution reduces unnecessary weight calculations and device re-screening operations. Especially in scenarios with frequent fluctuations in environmental indicators, such as unstable network signals, it avoids the system consuming excessive computing power on weight adjustments, allowing resources to be more focused on the actual detection of phishing websites. By balancing dynamic adaptation and system stability, this solution enables weight adjustments to flexibly respond to environmental changes while maintaining the consistency of the detection strategy, providing a solid guarantee for the efficient and reliable operation of the entire distributed detection system.

[0234] Select the top-ranked candidate scores for the corresponding scenario based on the different scenarios. One device, of which The number of target candidate collaborative devices ultimately selected. This represents the total number of candidate collaborative devices. For example, in a high-trust scenario, the number of low-trust devices corresponds to the scenario... Devices with low values ​​are automatically eliminated, and the device accuracy and trust score are continuously updated after the task is completed.

[0235] Cross-device verification, through the selected... Each device performs multimodal deep feature verification on the received suspicious URLs, integrates image matching, script analysis and certificate verification results, outputs the final judgment and feeds it back to the edge computing terminal.

[0236] Based on the above description, this application has the following beneficial effects:

[0237] This application addresses the inaccuracy issues of traditional localized phishing website detection solutions by constructing a layered detection method that combines initial risk scoring and in-depth verification using collaborative devices, effectively improving the accuracy and adaptability of detection. Specifically, a preliminary judgment is made by calculating a risk score based on the URL. For suspicious URLs falling between the first and second risk thresholds, multi-dimensional status parameters (remaining battery power, load status, network latency, detection accuracy, and trust score) of candidate collaborative devices are introduced for comprehensive evaluation and screening. This ensures that detection tasks are assigned to target candidate collaborative devices, and the limitations of single localized detection are overcome through multi-device collaborative verification.

[0238] Meanwhile, by dynamically adjusting weights to adapt to the needs of different business scenarios, and by optimizing the collaborative device pool in combination with screening and exit conditions, detection efficiency is ensured and the reliability of results is improved. This enables more accurate identification of phishing websites, reduces false positives and false negatives, and provides stronger protection for users' personal information and property security.

[0239] The above text combined Figure 1 The method for detecting phishing websites provided in the embodiments of this application has been described in detail. The apparatus and equipment provided in the embodiments of this application will be described below with reference to the accompanying drawings.

[0240] like Figure 2 As shown in the figure, this is a schematic diagram of a phishing website detection device provided in an embodiment of this application. The device includes:

[0241] The acquisition module 301 is used to obtain the Uniform Resource Locator (URL) of the website to be tested;

[0242] Data processing module 302 is used to calculate the risk score of the website to be detected based on the URL; when the risk score is greater than a first risk threshold and less than a second risk threshold, it obtains the remaining power, load, network latency, detection accuracy, and trust score of each candidate collaborative device; the first risk threshold is less than the second risk threshold; and determines the target candidate collaborative device from among the candidate collaborative devices based on the remaining power, load, network latency, detection accuracy, and trust score of each candidate collaborative device.

[0243] The detection module 303 is used to forward the URL to the target candidate collaborative device and receive the detection results of the target candidate collaborative device for the URL of the website to be detected.

[0244] Optionally, the data processing module 302 is specifically used to calculate the candidate score of each candidate collaborative device based on the remaining power, load, network latency, detection accuracy and trust score of each candidate collaborative device; and to determine the target candidate collaborative device from among the candidate collaborative devices based on the candidate scores.

[0245] Optionally, the acquisition module 301 is specifically used to acquire the first weight corresponding to the remaining power and load status, the third weight corresponding to the network latency, the fourth weight corresponding to the detection accuracy, and the second weight corresponding to the trust score;

[0246] The data processing module 302 is specifically used to calculate the candidate score of each candidate collaborative device based on the remaining power, load status, first weight corresponding to the remaining power and load status, network latency, third weight corresponding to the network latency, detection accuracy, fourth weight corresponding to the detection accuracy, trust score, and second weight corresponding to the trust score of each candidate collaborative device.

[0247] Optionally, module 301 is used to obtain the requirement information of the business scenario;

[0248] The data processing module 302 is specifically used to determine, based on the demand information, a first weight corresponding to the remaining power and load status, a third weight corresponding to the network latency, a fourth weight corresponding to the detection accuracy, and a second weight corresponding to the trust score.

[0249] Optionally, the data processing module 302 is further configured to determine the screening criteria for the candidate collaborative devices based on the demand information; filter the candidate collaborative devices using the screening criteria to obtain the remaining sub-candidate collaborative devices after filtering; and determine the target candidate collaborative device from the candidate collaborative devices based on the remaining power, load, network latency, detection accuracy, and trust score of each candidate collaborative device, including:

[0250] Based on the remaining power, load, network latency, detection accuracy, and trust score of the remaining sub-candidate collaborative devices after filtering, the target candidate collaborative device is determined from the remaining sub-candidate collaborative devices.

[0251] Optionally, the data processing module 302 is further configured to determine the exit conditions of the sub-candidate collaborative devices based on the demand information; and filter out the target sub-candidate collaborative devices that meet the exit conditions from among the multiple sub-candidate collaborative devices.

[0252] Optionally, the acquisition module 301 is also used to acquire the environment state vector;

[0253] The data processing module 302 is further configured to adjust the first weight, the third weight, the fourth weight, and the second weight based on the environmental state vector and the candidate scores.

[0254] The phishing website detection device according to the embodiments of this application can correspondingly execute the method described in the embodiments of this application, and the other operations and / or functions of each module / unit of the phishing website detection device are respectively for implementing Figure 1 For the sake of brevity, the corresponding processes of each method in the illustrated embodiments will not be described in detail here.

[0255] This application also provides a computing device. For example... Figure 3 As shown in the figure, this is a schematic diagram of a computing device provided in an embodiment of this application. The computing device 700 includes a bus 701, a processor 702, a communication interface 703, and a memory 704. The processor 702, the memory 704, and the communication interface 703 communicate with each other via the bus 701.

[0256] The 701 bus can be a Peripheral Component Interconnect (PCI) bus or an Extended Industry Standard Architecture (EISA) bus, etc. Buses can be categorized as address buses, data buses, control buses, etc. For ease of representation, Figure 3 The bus is represented by a single thick line, but this does not mean that there is only one bus or one type of bus.

[0257] The processor 702 can be any one or more of the following processors: central processing unit (CPU), graphics processing unit (GPU), microprocessor (MP), or digital signal processor (DSP).

[0258] The communication interface 703 is used for external communication.

[0259] Memory 704 may include volatile memory, such as random access memory (RAM). Memory 704 may also include non-volatile memory, such as read-only memory (ROM), flash memory, hard disk drive (HDD), or solid state drive (SSD).

[0260] The memory 704 stores executable code, and the processor 702 executes the executable code to perform the aforementioned phishing website detection method.

[0261] Specifically, in achieving Figure 2 In the case of the illustrated embodiment, and Figure 2 When the modules or units of the phishing website detection device described in the embodiment are implemented by software, they execute... Figure 2 The software or program code required for the functions of each module / unit can be partially or wholly stored in memory 704. Processor 702 executes the program code corresponding to each unit stored in memory 704 to execute the aforementioned phishing website detection method.

[0262] This application also provides a computer-readable storage medium. The computer-readable storage medium can be any available medium capable of being stored by a computing device, or a data storage device such as a data center containing one or more available media. The available medium can be a magnetic medium (e.g., floppy disk, hard disk, magnetic tape), an optical medium (e.g., DVD), or a semiconductor medium (e.g., solid-state drive). The computer-readable storage medium includes instructions that instruct the computing device to execute the aforementioned phishing website detection method.

[0263] This application also provides a computer program product comprising one or more computer instructions. When the computer instructions are loaded and executed on a computing device, all or part of the processes or functions described in this application are generated.

[0264] The computer instructions may be stored in a computer-readable storage medium or transmitted from one computer-readable storage medium to another. For example, the computer instructions may be transmitted from one website, computer, or data center to another website, computer, or data center via wired (e.g., coaxial cable, fiber optic, digital subscriber line) or wireless (e.g., infrared, wireless, microwave, etc.) means.

[0265] When the computer program product is executed by a computer, the computer performs any of the aforementioned methods for detecting phishing websites. The computer program product can be a software installation package; when any of the aforementioned methods for detecting phishing websites is required, the computer program product can be downloaded and executed on the computer.

[0266] The descriptions of the processes or structures corresponding to the above figures each have their own emphasis. For parts of a process or structure that are not described in detail, please refer to the relevant descriptions of other processes or structures.

[0267] The above description is merely a specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any changes or substitutions within the technical scope disclosed in this application should be covered within the scope of protection of this application.

Claims

1. A method for detecting phishing websites, characterized in that, The method includes: Obtain the Uniform Resource Locator (URL) of the website to be tested; Calculate the risk score of the website to be tested based on the URL; If the risk score is greater than a first risk threshold and less than a second risk threshold, obtain the remaining battery power, load status, network latency, detection accuracy, and trust score of each candidate collaborative device; the first risk threshold is less than the second risk threshold. Based on the remaining power, load, network latency, detection accuracy, and trust score of each candidate collaborative device, the target candidate collaborative device is determined from among the candidate collaborative devices. Forward the URL to the target candidate collaborative device; Receive the detection results of the target candidate collaborative device for the URL of the website to be detected.

2. The method according to claim 1, characterized in that, The process of determining the target candidate collaborative device from among the candidate collaborative devices based on their remaining power, load status, network latency, detection accuracy, and trust score includes: Based on the remaining power, load, network latency, detection accuracy, and trust score of each candidate collaborative device, the candidate score of each candidate collaborative device is calculated. Based on the candidate scores, the target candidate collaborative device is determined from among the candidate collaborative devices.

3. The method according to claim 2, characterized in that, The candidate score for each candidate collaborative device is calculated based on its remaining battery power, load status, network latency, detection accuracy, and trust score, including: Obtain the first weight corresponding to the remaining power and load status, the third weight corresponding to the network latency, the fourth weight corresponding to the detection accuracy, and the second weight corresponding to the trust score; The candidate scores for each candidate collaborative device are calculated based on its remaining power, load status, first weight corresponding to the remaining power and load status, network latency, third weight corresponding to the network latency, detection accuracy, fourth weight corresponding to the detection accuracy, trust score, and second weight corresponding to the trust score.

4. The method according to claim 3, characterized in that, The process of obtaining the first weight corresponding to the remaining power and load status, the third weight corresponding to the network latency, the fourth weight corresponding to the detection accuracy, and the second weight corresponding to the trust score includes: Obtain the requirements information for the business scenario; Based on the demand information, determine the first weight corresponding to the remaining power and load status, the third weight corresponding to the network latency, the fourth weight corresponding to the detection accuracy, and the second weight corresponding to the trust score.

5. The method according to claim 4, characterized in that, The method further includes: Based on the aforementioned requirements information, the screening criteria for the candidate collaborative devices are determined; The candidate collaborative devices are filtered using the aforementioned screening criteria to obtain the remaining sub-candidate collaborative devices after filtering. The process of determining the target candidate collaborative device from among the candidate collaborative devices based on their remaining power, load status, network latency, detection accuracy, and trust score includes: Based on the remaining power, load, network latency, detection accuracy, and trust score of the remaining sub-candidate collaborative devices after filtering, the target candidate collaborative device is determined from the remaining sub-candidate collaborative devices.

6. The method according to claim 5, characterized in that, The method further includes: Based on the aforementioned demand information, determine the exit conditions for the sub-candidate collaborative devices; Filter out the target sub-candidate collaborative devices that meet the exit conditions from among multiple sub-candidate collaborative devices.

7. The method according to any one of claims 3-6, characterized in that, The method further includes: Obtain the environment state vector; The first weight, the third weight, the fourth weight, and the second weight are adjusted based on the environmental state vector and the candidate scores.

8. A phishing website detection device, characterized in that, The device includes: The acquisition module is used to obtain the Uniform Resource Locator (URL) of the website to be tested; The data processing module is used to calculate the risk score of the website to be detected based on the URL; when the risk score is greater than a first risk threshold and less than a second risk threshold, it obtains the remaining power, load, network latency, detection accuracy, and trust score of each candidate collaborative device; the first risk threshold is less than the second risk threshold; and determines the target candidate collaborative device from among the candidate collaborative devices based on the remaining power, load, network latency, detection accuracy, and trust score of each candidate collaborative device. The detection module is used to forward the URL to the target candidate collaborative device and receive the detection results of the target candidate collaborative device for the URL of the website to be detected.

9. A computing device, characterized in that, Including memory and processor; The memory stores one or more computer programs, the one or more computer programs including instructions; when the instructions are executed by the processor, the computing device performs the method as described in any one of claims 1 to 7.

10. A computer-readable storage medium, characterized in that, The computer-readable storage medium is used to store a computer program for performing the method as described in any one of claims 1 to 7.

Images