WebWorker-based multi-thread collaborative taint analysis method and taint protection architecture
By migrating browser taint analysis to an independent thread pool and using the main thread and worker threads to execute collaboratively, the performance loss and security imbalance caused by resource contention in browser taint analysis methods are resolved, achieving efficient security protection and improved stability.
Patent Information
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2025-10-30
- Publication Date
- 2026-03-24
AI Technical Summary
Existing browser taint analysis methods rely on the main thread for execution, which leads to severe resource contention when dealing with complex pages and high-frequency user interactions. This affects page rendering frame rate and interaction response, making it difficult to ensure user experience and security protection in scenarios with high real-time requirements.
We adopt a WebWorker-based multi-threaded collaborative taint analysis method, which migrates the core computation module of taint analysis to an independent thread pool. By cooperating between the main thread and the worker thread, we achieve data isolation and interaction, reduce the performance consumption of the main thread, and optimize resource allocation through dynamic load balancing and incremental synchronization mechanisms.
It improves the stability and security of browser pages, balancing security protection and operational efficiency, and achieves a high-performance, low-latency user experience. It also supports customizing Worker thread priorities and dynamically adjusting taint tracking granularity according to business scenario requirements.
Smart Images

Figure CN121723480A_ABST
Abstract
Description
Technical Field
[0001] This invention relates to the technical field of network security protection, and in particular to a multi-threaded collaborative taint analysis method based on WebWorker. Background Technology
[0002] Currently, as web applications evolve towards greater complexity and interactivity, the importance of front-end security protection is becoming increasingly prominent. Browser taint analysis, as a key technology for detecting network risks such as XSS and data leakage, directly determines the practical value of front-end security protection through its operational efficiency.
[0003] Existing browser taint detection methods typically rely on the browser's main thread to execute taint tracking and analysis logic. However, the main thread, as the core carrier of all web applications, needs to handle tasks such as DOM rendering, event handling, and script execution, requiring sustained high-efficiency real-time responsiveness. Taint analysis, on the other hand, is computationally intensive and often competes for resources with other main thread tasks. When dealing with complex pages with massive DOM nodes or high-frequency user interaction scenarios, the main thread is continuously consumed by taint analysis tasks, leading to decreased page rendering frame rates and interaction response delays exceeding the 100ms threshold, severely impacting user experience. Furthermore, the single-threaded JavaScript model used for taint analysis limits its effectiveness. If time-consuming operations occur during taint analysis, they can easily trigger main thread blocking, potentially causing taint analysis interruptions, page freezes, or even crashes, compromising browser stability. This imbalance between performance degradation and security protection makes it difficult to implement the aforementioned technologies in web scenarios with high real-time requirements, such as finance and healthcare, failing to meet the user experience's need for "zero-perceptible security protection." Summary of the Invention
[0004] To address the issue of performance degradation and security imbalance caused by resource contention between browser taint analysis and other tasks on the main thread in existing technologies, this invention provides a multi-threaded collaborative taint analysis method based on WebWorker. This method migrates the core computation module of taint analysis to an independent thread pool for execution. By using Worker threads to collaboratively execute taint analysis with the main thread, data isolation and interaction are achieved, reducing the performance consumption of the main thread, improving the stability of browser page operation, and balancing security strength and operational efficiency.
[0005] Firstly, the above-mentioned inventive objective of this application is achieved through the following technical solution: A multi-threaded collaborative taint analysis method based on WebWorker, wherein the method performs taint analysis through collaborative interaction between a main thread and multiple worker threads, the method comprising: The main thread periodically obtains the waiting queue length of all Worker threads and determines whether each Worker thread is in an idle state where it can process new tasks based on the waiting queue length. Based on the idle status, the unprocessed logs are sent to the idle Worker thread for task breakdown and priority marking. All marked pending tasks are then added to the Worker waiting queue. Based on the priority marking results, all tasks in the Worker waiting queue are reordered by priority, and the target task with the highest priority is selected for taint propagation analysis to obtain taint analysis data. The Worker waiting queue is updated with the taint analysis data, and the updated Worker waiting queue status is fed back to the main thread for the next round of task allocation, thus obtaining multi-threaded collaborative scheduling data.
[0006] In a preferred embodiment, this application can be further configured as follows: the process of reordering all tasks in the Worker waiting queue according to the priority marking result, selecting the target task with the highest priority for taint propagation analysis, and obtaining the taint propagation analysis data specifically includes: The main thread periodically sends incremental update data of the taint status table to all worker threads, and creates a copy of the taint status table in the worker thread and updates it periodically. Obtain suspected taint data from the target task to be processed, and compare the suspected taint data with the updated taint status table copy item by item. Based on the comparison results, determine whether there is tainted data in the target task to be processed; If so, obtain the data stream path of the tainted data that matches the comparison, analyze whether the endpoint of the data stream path is a sensitive DOM location, and block DOM operations at the sensitive DOM location. If not, then the corresponding DOM operation is marked as safe.
[0007] In a preferred embodiment, this application can be further configured as follows: if so, then the data stream path of the matched tainted data is obtained, and it is analyzed whether the endpoint of the data stream path is a sensitive DOM location, and the DOM operation blocking process for the DOM operation at the sensitive DOM location is specifically included in the following steps: Obtain the effective status of the DOM operation, and perform numerical replacement or interruption processing on the target value of the DOM operation according to the effective status to generate DOM blocking data; Obtain the taint markers of the data flow path and mark the data objects in the taint status table copy of the Worker queue to obtain the taint propagation path data; Based on the operation time, the DOM blocking data and the taint propagation path data are packaged into attack event data, and the packaged attack event data is synchronized to the main thread security log.
[0008] In a preferred embodiment, this application can be further configured as follows: Based on the priority marking result, all tasks in the Worker waiting queue are reordered according to their priority, and the target task with the highest priority is selected for taint propagation analysis to obtain taint analysis data; the method further includes: The Worker waiting queue synchronizes the taint analysis results to the main thread, and the main thread updates the status of the DOM operation log by obtaining the corresponding DOM operation based on the taint analysis results. Based on the state update results, the DOM operation is added as a new node to the main thread DOM tree, and the DOM operation is bound to an API hook function for dynamic monitoring.
[0009] In a preferred embodiment, this application can be further configured as follows: updating the Worker waiting queue based on the taint analysis data, and feeding back the updated Worker waiting queue status to the main thread for the next round of task allocation, thereby obtaining multi-threaded collaborative scheduling data, specifically includes: Based on the taint analysis data, the target task to be processed is removed from the Worker waiting queue, and the next optimal task to be processed is selected according to the priority sorting result, and the Worker waiting queue is updated. The idle status of the Worker waiting queue after the task update is obtained, and the status of the Worker waiting queue is fed back to the main thread for the next round of task allocation, thus obtaining multi-threaded collaborative scheduling data.
[0010] In a preferred embodiment, this application can be further configured as follows: the main thread periodically obtains the waiting queue length of all Worker threads, and determines whether each Worker thread is in an idle state where it can process new tasks based on the waiting queue length, specifically including: The main thread periodically obtains the waiting queue length of all Worker threads and determines whether the waiting queue length exceeds the preset maximum processing queue threshold. If so, the priority of the current Worker thread is reduced, and other Worker threads are sorted according to the length of the waiting queue. The idle state of the Worker thread is determined according to the priority sorting result. Select the worker thread with the best idle state to assign new tasks, and monitor the change in the waiting queue length of the current worker thread that exceeds the maximum processing queue threshold. When the waiting queue length of the current Worker thread is less than the preset minimum processing queue threshold, the current Worker thread is reordered by priority.
[0011] In a preferred embodiment, this application can be further configured as follows: before the main thread periodically obtains the waiting queue lengths of all Worker threads and determines whether each Worker thread is in an idle state ready to handle new tasks based on the waiting queue lengths, the application further includes: Obtain web input data from the browser, and classify and label the web input data according to the data source, including user input source, external data source and sensitive storage source.
[0012] Secondly, the above-mentioned inventive objective of this application is achieved through the following technical solutions: A WebWorker-based multi-threaded collaborative taint protection architecture, wherein the system is applied to the aforementioned WebWorker-based multi-threaded collaborative taint analysis method, and the architecture includes: The initialization configuration module is used to initialize the browser's core parameters, computing resource allocation mechanism, and data structures; The taint source identification and marking module is used to monitor and identify taint data sources in real time and mark taint data in the taint status table; The DOM operation monitoring and logging module is used to monitor sensitive DOM operations in the browser in real time and generate DOM operation logs. The Worker task scheduling module is used to receive DOM operation logs and manage the Worker task queue through multi-threaded collaboration and priority processing. The taint propagation analysis module is used to execute core analysis logic in the Worker thread. Based on the taint status table and DOM operation log, it analyzes the propagation path of tainted data in the DOM tree and determines whether there is an XSS operation. The taint removal and defense response module is used to execute corresponding defense measures in the main thread based on the analysis results of the taint propagation analysis module. The defense measures include blocking XSS operations, removing taint marks, and recording attack events. The state synchronization module is used to synchronize the state between the main thread and the worker thread through a preset incremental update mechanism and synchronization mechanism.
[0013] Thirdly, the above-mentioned objectives of this application are achieved through the following technical solutions: A computer device includes a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the computer program to implement the steps of the WebWorker-based multi-threaded collaborative taint analysis method described above.
[0014] Fourthly, the above-mentioned objectives of this application are achieved through the following technical solutions: A computer-readable storage medium storing a computer program that, when executed by a processor, implements the steps of the WebWorker-based multi-threaded collaborative taint analysis method described above.
[0015] In summary, this application includes at least one of the following beneficial technical effects: 1. This application alleviates the taint analysis pressure on the browser's main thread by using multi-threaded Workers. Through the Worker multi-threaded collaboration mechanism, a parallel processing architecture is constructed where "the main thread focuses on interaction, and multiple Worker threads perform independent analysis." This breaks through the performance bottleneck caused by resource contention when processing multiple tasks in a traditional single-threaded environment. By migrating the core computational logic of taint analysis to an independent Worker thread pool for independent computation, the task processing pressure on the main thread is reduced. The Worker thread pool adopts a dynamic load balancing strategy, which automatically adjusts the number of active Workers based on the current main thread load and the complexity of the analysis task. This achieves the goal of multi-threaded collaboration, where lightweight tasks are processed quickly by a single Worker thread and complex tasks are processed in parallel by multiple Worker threads. Through the binary data channel between the main thread and Worker threads, a structured cloning algorithm is used to transmit analysis objects for precise allocation of computational resources. Compared with the traditional JSON serialization method, this reduces data transmission overhead and improves the browser's task processing performance, achieving a balance between security strength and performance. 2. This application uses an incremental synchronization mechanism for taint information to transmit only the changed data stream markers and periodically and dynamically update the taint status table appendix in multiple worker threads. This reduces the communication time between the main thread and multiple worker threads to the microsecond level. By isolating and running multiple worker threads in parallel, the stability of data transmission is improved. Furthermore, by isolating worker threads, even if there are exceptions such as script errors or memory overflows, only a single worker thread will be affected, ensuring that the main thread and other analysis tasks are not affected. 3. This application supports customizing Worker thread priorities and dynamically adjusting taint tracking granularity according to business scenario requirements by dynamically configuring taint analysis strategies. It also provides a real-time performance monitoring interface and dynamically optimizes resource allocation based on page characteristics to achieve a precise balance between security protection and operational performance. This results in a "high-performance, low-latency, highly reliable, and controllable" multi-threaded collaborative taint protection architecture, which improves browser taint analysis performance and security protection while enhancing user experience. Attached Figure Description
[0016] To more clearly illustrate the specific embodiments of the present invention or the technical solutions in the prior art, the accompanying drawings used in the description of the specific embodiments or the prior art will be briefly introduced below. In all the drawings, similar elements or parts are generally identified by similar reference numerals. In the drawings, the elements or parts are not necessarily drawn to scale.
[0017] Figure 1 This is a flowchart illustrating the implementation of the WebWorker-based multi-threaded collaborative taint analysis method in this embodiment.
[0018] Figure 2 This is a flowchart illustrating the implementation of step S10 of the multi-threaded collaborative taint analysis method in this embodiment.
[0019] Figure 3 This is a flowchart illustrating the multi-threaded collaborative taint analysis method used in this embodiment for taint propagation analysis.
[0020] Figure 4 This is a flowchart illustrating the process of blocking DOM operations using the multi-threaded collaborative taint analysis method in this embodiment.
[0021] Figure 5 This is a schematic diagram illustrating the process of log updating and monitoring using the multi-threaded collaborative taint analysis method in this embodiment.
[0022] Figure 6 This is a flowchart illustrating the implementation of step S40 of the multi-threaded collaborative taint analysis method in this embodiment.
[0023] Figure 7 This is a structural block diagram of the multi-threaded collaborative taint protection architecture based on WebWorker in this embodiment.
[0024] Figure 8 This is a schematic diagram of the internal structure of a computer device used to implement a multi-threaded collaborative taint analysis method. Detailed Implementation
[0025] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some, not all, of the embodiments of the present invention. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.
[0026] It should be understood that, when used in this specification and the appended claims, the terms "comprising" and "including" indicate the presence of the described features, integrals, steps, operations, elements and / or components, but do not exclude the presence or addition of one or more other features, integrals, steps, operations, elements, components and / or collections thereof.
[0027] It should also be understood that the terminology used in this specification is for the purpose of describing particular embodiments only and is not intended to limit the invention. As used in this specification and the appended claims, the singular forms “a,” “an,” and “the” are intended to include the plural forms unless the context clearly indicates otherwise.
[0028] It should also be further understood that the term "and / or" as used in this specification and the appended claims refers to any combination of one or more of the associated listed items and all possible combinations, and includes such combinations.
[0029] In one embodiment, such as Figure 1 As shown, this application discloses a multi-threaded collaborative taint analysis method based on WebWorker. This method performs taint analysis through collaborative interaction between a main thread and multiple worker threads, specifically including the following steps: S10: The main thread periodically obtains the waiting queue length of all Worker threads and determines whether each Worker thread is in an idle state where it can process new tasks based on the waiting queue length.
[0030] Specifically, such as Figure 2 As shown, step S10 includes: S101: The main thread periodically obtains the waiting queue length of all Worker threads and determines whether the waiting queue length exceeds the preset maximum processing queue threshold.
[0031] Specifically, the main thread obtains the length of the waiting queue through the queue status periodically returned by the Worker thread. In this embodiment, the maximum processing queue threshold is set to 20. That is, if the number of tasks in the waiting queue is greater than or equal to 20, it means that the current waiting queue length exceeds the maximum processing queue threshold, and it is necessary to pause the submission of new tasks to avoid the Worker thread memory overflow.
[0032] S102: If so, reduce the priority of the current Worker thread, sort other Worker threads according to the length of the waiting queue, and determine the idle state of the Worker thread according to the priority sorting result.
[0033] Specifically, when the maximum processing queue threshold is exceeded, the priority of the current Worker thread is reduced, and other Worker threads that have not exceeded the maximum processing queue threshold are sorted by priority according to the length of the waiting queue. The shorter the waiting queue length, the higher the priority. The idle state of the Worker thread is determined according to the priority sorting result. The higher the priority, the more idle the thread.
[0034] S103: Select the Worker thread with the best idle state to assign a new task, and monitor the change in the waiting queue length of the current Worker thread that exceeds the maximum processing queue threshold.
[0035] Specifically, the worker thread with the best idle state (i.e., the fewest number of tasks being processed) is selected for new task allocation, and the waiting queue length of the current worker thread that exceeds the maximum processing queue threshold is monitored based on the queue status periodically returned by the worker thread.
[0036] S104: When the waiting queue length of the current Worker thread is less than the preset minimum processing queue threshold, the priority of the current Worker thread is reordered.
[0037] Specifically, when the waiting queue length of the current Worker thread is less than the preset minimum processing queue threshold (in this embodiment, the minimum processing queue threshold is 10), that is, when the number of waiting processing tasks allocated to the current Worker thread is less than 10, the priority of the current Worker is reordered according to the current waiting queue length.
[0038] In this embodiment, before the main thread periodically obtains the waiting queue length of all Worker threads and determines whether each Worker thread is in an idle state ready to handle new tasks based on the waiting queue length, the method further includes: Obtain web input data from the browser and classify and label the web input data according to the data source, which includes user input sources, external data sources, and sensitive storage sources.
[0039] Specifically, this involves obtaining web input data from the browser, including user input source tags for all... <input> , <textarea>、< / textarea> <select>The element is bound to an input event listener. When the user inputs content via keyboard or paste, the input value (element.value) is immediately obtained and marked as true in the taint status table, indicating a taint. This is intercepted by calling a function via window.prompt() / window.confirm(), or by overriding a function, and the return value is stored in the taint status table and marked as true.
[0040] For external data source marking, the following are included: intercepting the onload event of XMLHttpRequest / fetch requests. When the request returns data (responseText / response), the data object is stored in the taint status table and marked as true. If the request URL is not in the predefined "trusted domain whitelist", the data object is forcibly marked; intercepting the onmessage event of WebSocket and marking event.data as true; listening to <script>、、<link>等标签的load事件,若其src属性值为外部域名则标记为true。
[0041] 对于敏感存储源标记包括:拦截localStorage.setItem() / sessionStorage.setItem(),对存入的值标记为true;拦截document.cookie的读取操作,对返回的cookie字符串标记为true。
[0042] S20:根据空闲状态判断结果,将未处理日志发送至空闲Worker线程中进行任务拆解处理并进行优先级标记,将标记后的所有待处理任务加入Worker等待队列。
[0043] 具体的,根据空闲状态判断结果,主线程将未处理日志发送至空闲Worker线程中,本实施例中设置的发送至单个Worker线程的最大未处理日志数量为10条,通过Worker.postMessage({ type: "task", logs: 日志列表})发送给Worker线程,Worker线程接收到主线程的未处理日志数据后,以每条日志为一个独立任务进行任务拆解,并基于任务风险等级进行优先级标记,将标记后的待处理任务加入Worker等待队列中。
[0044] 本实施例中,涉及innerHTML、outerHTML、on*事件属性的DOM操作标记为直接关联XSS触发点的高优先级任务;将普通属性(如href、src)且不含javascript协议的操作标记为低优先级任务。
[0045] S30:根据优先级标记结果,对Worker等待队列中的所有任务进行优先级重排序处理,选取优先级最优的目标待处理任务进行污点传播分析,得到污点分析数据。
[0046] 具体的,根据优先级标记结果,对Worker等待队列中的所有任务进行优先级重新排序处理,按照优先级顺序由高到低排序,同优先级则按照时间戳排序,并选取优先级最优的待处理任务作为目标待处理任务,对目标待处理任务进行污点传播分析,得到污点分析数据。
[0047] 如图3所示,本实施例中的污点传播分析过程包括:S301:主线程定期向所有Worker线程发送污点状态表的增量更新数据,在Worker线程中创建污点状态表副本并进行定期更新。
[0048] 具体的,Worker线程创建时在主线程处获取污点状态表快照并创建污点状态表副本,主线程每2秒向所有Worker线程发送污点状态表的增量更新数据,包括新增或者删除污点数据,确保Worker线程中的污点状态表副本处于最新状态。
[0049] S302:获取目标待处理任务中的疑似污点数据,将疑似污点数据与更新后的污点状态表副本进行逐项污点数据比对。
[0050] 具体的,获取目标待处理任务中的疑似污点数据,包括涉及污点数据、相关联或者相似的数据,结合主线程同步更新后的污点状态表副本进行逐项污点数据比对。
[0051] S303:根据比对结果判断目标待处理任务中是否存在污点数据。
[0052] 具体的,根据比对结果判断目标待处理任务中是否存在污点数据,若所有数据比对结果中均未出现污点数据则说明目标待处理任务中不存在污点数据,若比对结果中出现一个污点数据则说明目标待处理任务中存在污点数据。
[0053] S304:若是,则获取比对一致的污点数据的数据流路径,并分析数据流路径的终点是否为敏感DOM位置,并对敏感DOM位置的DOM操作进行阻断处理。
[0054] 具体的,当存在污点数据时,则获取比对一致的污点数据的数据流路径,分析数据流路径的终点是否为敏感DOM位置,即判断DOM操作是否为XSS操作,判定过程包括:若操作类型为setAttribute且属性为onclick、onload等事件处理器 → 判定"危险”(isDangerous = true);若操作类型为innerHTML赋值且数据含<script>、javascript:等关键字 → 判定"危险”(isDangerous = true);其他情况(如设置href属性且数据不含javascript:)→ 判定"安全”(isDangerous = false)。
[0055] 需要说明的是,本实施例中的XSS操作表示XSS攻击相关的DOM操作。
[0056] 如图4所示,本实施例中的DOM操作阻断过程,包括:S3041:获取DOM操作的生效状态,按照生效状态对DOM操作的目标值进行数值替换或者中断操作处理,生成DOM阻断数据。
[0057] 具体的,主线程监听Worker线程返回的result消息,根据操作ID找到对应的DOM操作日志,从而获取DOM操作的生效状态,当DOM操作生效时,则对innerHTML赋值,强制清空值并替换为过滤后的安全内容,当DOM操作未生效时,则直接强制中断DOM操作,从而得到DOM阻断数据。
[0058] S3042:获取数据流路径的污点标记,并在Worker队列的污点状态表副本中进行数据对象标记,得到污点传播路径数据。
[0059] 具体的,获取数据流路径的污点标记,在Worker队列的污点状态表副本中将数据流路径上标记的所有数据对象标记为false,避免重复分析统一数据的后续传播,得到污点传播路径数据。
[0060] S3043:按照操作时间,将DOM阻断数据和污点传播路径数据进行攻击事件数据打包处理,并将打包后的攻击事件数据同步至主线程安全日志中。
[0061] 具体的,按照操作时间,将DOM阻断数据和污点传播路径数据进行数据打包,得到攻击事件数据,并同步至主线程安全日志中,便于开发者进行调试和参数配置。
[0062] S305:若否,则对相应的DOM操作进行安全标记。
[0063] 具体,若数据为非污点,标记相应的DOM操作为"安全”(isDangerous = false)。
[0064] 如图5所示,本实施例中的步骤S30还包括:S306:Worker等待队列将污点分析结果同步至主线程中,主线程根据污点分析结果获取对应的DOM操作对主线程的DOM操作日志进行状态更新。
[0065] 具体的,Worker等待队列将污点分析结果同步至主线程中,主线程接收污点分析结果并将对应的DOM操作同步更新至主线程的DOM操作日志中,如"已分析操作ID表”中,对相应的日志标记为"已处理”,避免重复分析。
[0066] S307:根据状态更新结果,将DOM操作作为新节点添加至主线程DOM树,并对DOM操作进行API钩子函数绑定处理,对DOM操作进行动态监控。
[0067] 具体的,根据DOM操作日志的状态更新结果,通过函数钩子重写敏感DOM操作API如Element.prototype.innerHTML、Element.prototype.setAttribute等敏感DOM操作,并将DOM操作作为新节点添加到主线程DOM树中,使用MutationObserver监听DOM树的变化,当新节点被添加时,自动为其绑定API钩子,确保动态生成的新节点也被监控。
[0068] S40:根据污点分析数据对Worker等待队列进行任务更新,并将更新后的Worker等待队列状态反馈至主线程进行下一轮任务分配,得到多线程协同调度数据。
[0069] 具体的,如图6所示,步骤S40包括:S401:根据污点分析数据,将目标待处理任务从Worker等待队列中移除,并按照优先级排序结果选取下一个最优待处理任务,对Worker等待队列进行任务更新。
[0070] 具体的,当接收到污点分析数据时说明当前任务分析已完成,将目标待处理任务从Worker等待队列中移除,以释放内存,按照优先级排序结果,选取Worker等待队列中优先级最高的待处理任务作为下一个最优待处理任务,对Worker等待队列进行任务更新。
[0071] S402:获取任务更新后的Worker等待队列的空闲状态,并将Worker等待队列状态反馈至主线程进行下一轮任务分配,得到多线程协同调度数据。
[0072] 具体的,获取任务更新后的Worker等待队列的空闲状态,并将Worker等待队列状态反馈至主线程进行下一轮任务分配,得到闭环的多线程协同调度数据,本实施例中的Worker线程每处理3条任务就通过postMessage({ type: "queueStatus", length: 待处理队列长度})向主线程反馈队列状态。
[0073] 本实施例中,在多线程协同污点分析方法进行数据处理前,先对主线程和Worker线程进行初始化,包括读取污点源清单、读取敏感DOM操作清单、污点分析线程资源配置和数据结构初始化等。
[0074] 读取污点源清单具体包括:加载需标记为"污点”的数据源类型,包括:用户输入元素(<input>、<textarea>、contenteditable元素);外部数据(XMLHttpRequest / fetch返回值、WebSocket消息、localStorage数据);敏感内置对象(document.cookie、window.name)。
[0075] 读取敏感DOM操作清单具体包括:加载可能触发XSS的高风险操作,包括:element.innerHTML / outerHTML赋值、element.setAttribute("onclick", ...)、document.write()、eval() / new Function()调用。
[0076] 污点分析线程资源配置具体包括:初始化多个污点分析专用Web Worker线程,用于处理污点分析任务;设置Worker与主线程的通信队列(基于Array+postMessage实现),队列长度上限设置为100,以避免内存溢出。
[0077] 数据结构初始化具体包括:创建2个核心映射表并存储在主线程内存中,其一为污点状态表(WeakMap类型): 键为数据对象(字符串、DOM节点属性值),值为布尔值(true表示污点,false表示清洁)。利用WeakMap特性避免阻塞垃圾回收;其二为DOM操作日志表(Array类型): 记录待分析的DOM操作,每条日志含字段:操作ID(自增整数)、操作类型、目标节点(DOM元素引用)、涉及数据(操作中使用的值)、时间戳(操作发生时间)。
[0078] 应理解,上述实施例中各步骤的序号的大小并不意味着执行顺序的先后,各过程的执行顺序应以其功能和内在逻辑确定,而不应对本申请实施例的实施过程构成任何限定。
[0079] 在一实施例中,提供一种基于WebWorker的多线程协同污点防护架构,该基于WebWorker的多线程协同污点防护架构与上述实施例中基于WebWorker的多线程协同污点分析方法一一对应。如图7所示,该基于WebWorker的多线程协同污点防护架构包括初始化配置模块、污点源识别与标记模块、DOM操作监控与记录模块、Worker任务调度模块、污点传播分析模块、污点清除与防御响应模块和状态同步模块。各功能模块详细说明如下:初始化配置模块,用于对浏览器的核心参数、算力资源分配机制和数据结构进行初始化。
[0080] 污点源识别与标记模块,用于实时监控并识别污点数据源,并在污点状态表中进行污点数据标记。
[0081] DOM操作监控与记录模块,用于实时监控浏览器中的敏感DOM操作,生成DOM操作日志。
[0082] Worker任务调度模块,用于接收DOM操作日志,通过多线程协同和优先级处理对Worker任务队列进行管理。
[0083] 污点传播分析模块,用于在Worker线程中执行核心分析逻辑,根据污点状态表和DOM操作日志,分析污点数据在DOM树中的传播路径,判断是否存在XSS操作。
[0084] 污点清除与防御响应模块,用于根据污点传播分析模块的分析结果,在主线程中执行相应的防御措施,其中,防御措施包括阻止XSS操作、清除污点标记、记录攻击事件。
[0085] 状态同步模块,用于通过预设的增量更新机制和同步机制在主线程与Worker线程之间进行状态同步。
[0086] 关于基于WebWorker的多线程协同污点防护架构的具体限定可以参见上文中对于基于WebWorker的多线程协同污点分析方法的限定,在此不再赘述。上述基于WebWorker的多线程协同污点防护架构中的各个模块可全部或部分通过软件、硬件及其组合来实现。上述各模块可以硬件形式内嵌于或独立于计算机设备中的处理器中,也可以以软件形式存储于计算机设备中的存储器中,以便于处理器调用执行以上各个模块对应的操作。
[0087] 在一个实施例中,提供了一种计算机设备,该计算机设备可以是服务器,其内部结构图可以如图8所示。该计算机设备包括通过系统总线连接的处理器、存储器、网络接口和数据库。其中,该计算机设备的处理器用于提供计算和控制能力。该计算机设备的存储器包括非易失性存储介质、内存储器。该非易失性存储介质存储有操作系统、计算机程序和数据库。该内存储器为非易失性存储介质中的操作系统和计算机程序的运行提供环境。该计算机设备的数据库用于存储主线程与多个Worker线程之间的多线程协同污点分析数据。该计算机设备的网络接口用于与外部的终端通过网络连接通信。该计算机程序被处理器执行时以实现一种基于WebWorker的多线程协同污点分析方法。
[0088] 在一个实施例中,提供了一种计算机可读存储介质,其上存储有计算机程序,计算机程序被处理器执行时实现一种基于WebWorker的多线程协同污点分析方法的步骤。
[0089] 本领域普通技术人员可以意识到,结合本文中所公开的实施例描述的各示例的单元,能够以电子硬件、计算机软件或者二者的结合来实现,为了清楚地说明硬件和软件的可互换性,在上述说明中已经按照功能一般性地描述了各示例的组成。这些功能究竟以硬件还是软件方式来执行,取决于技术方案的特定应用和设计约束条件。专业技术人员可以对每个特定的应用来使用不同方法来实现所描述的功能,但是这种实现不应认为超出本发明的范围。
[0090] 在本发明所提供的实施例中,应该理解到,单元的划分,仅仅为一种逻辑功能划分,实际实现时可以有另外的划分方式,例如多个单元可结合为一个单元,一个单元可拆分为多个单元,或一些特征可以忽略等。
[0091] 另外,在本发明各个实施例中的各功能单元可以集成在一个处理单元中,也可以是各个单元单独物理存在,也可以两个或两个以上单元集成在一个单元中。上述集成的单元既可以采用硬件的形式实现,也可以采用软件功能单元的形式实现。
[0092] 所述集成的单元如果以软件功能单元的形式实现并作为独立的产品销售或使用时,可以存储在一个计算机可读取存储介质中。基于这样的理解,本发明的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的全部或部分可以以软件产品的形式体现出来,该计算机软件产品存储在一个存储介质中,包括若干指令用以使得一台计算机设备(可为个人计算机、服务器或者网络设备等)执行本发明各个实施例所述方法的全部或部分步骤。而前述的存储介质包括:U盘、只读存储器(ROM,Read-0nlyMemory)、随机存取存储器(RAM,RandomAccessMemory)、移动硬盘、磁碟或者光盘等各种可以存储程序代码的介质。
[0093] 最后应说明的是:以上各实施例仅用以说明本发明的技术方案,而非对其限制;尽管参照前述各实施例对本发明进行了详细的说明,本领域的普通技术人员应当理解:其依然可以对前述各实施例所记载的技术方案进行修改,或者对其中部分或者全部技术特征进行等同替换;而这些修改或者替换,并不使相应技术方案的本质脱离本发明各实施例技术方案的范围,其均应涵盖在本发明的权利要求和说明书的范围当中。< / script> < / select>
Claims
1. A multi-threaded collaborative taint analysis method based on WebWorker, characterized in that, The method performs taint analysis through collaborative interaction between a main thread and multiple worker threads. The method includes: The main thread periodically obtains the waiting queue length of all Worker threads and determines whether each Worker thread is in an idle state where it can process new tasks based on the waiting queue length. Based on the idle status, the unprocessed logs are sent to the idle Worker thread for task breakdown and priority marking. All marked pending tasks are then added to the Worker waiting queue. Based on the priority marking results, all tasks in the Worker waiting queue are reordered by priority, and the target task with the highest priority is selected for taint propagation analysis to obtain taint analysis data. The Worker waiting queue is updated with the taint analysis data, and the updated Worker waiting queue status is fed back to the main thread for the next round of task allocation, thus obtaining multi-threaded collaborative scheduling data.
2. The multi-threaded collaborative taint analysis method based on WebWorker according to claim 1, characterized in that, The process of reordering all tasks in the Worker waiting queue based on the priority marking results, selecting the target task with the highest priority for taint propagation analysis, and obtaining the taint propagation analysis data specifically includes: The main thread periodically sends incremental update data of the taint status table to all worker threads, and creates a copy of the taint status table in the worker thread and updates it periodically. Obtain suspected taint data from the target task to be processed, and compare the suspected taint data with the updated taint status table copy item by item. Based on the comparison results, determine whether there is tainted data in the target task to be processed; If so, obtain the data stream path of the tainted data that matches the comparison, analyze whether the endpoint of the data stream path is a sensitive DOM location, and block DOM operations at the sensitive DOM location. If not, then the corresponding DOM operation is marked as safe.
3. The multi-threaded collaborative taint analysis method based on WebWorker according to claim 2, characterized in that, If so, then the data stream path of the matched tainted data is obtained, and it is analyzed whether the endpoint of the data stream path is a sensitive DOM location. The DOM operation blocking process for DOM operations at the sensitive DOM location specifically includes: Obtain the effective status of the DOM operation, and perform numerical replacement or interruption processing on the target value of the DOM operation according to the effective status to generate DOM blocking data; Obtain the taint markers of the data flow path and mark the data objects in the taint status table copy of the Worker queue to obtain the taint propagation path data; Based on the operation time, the DOM blocking data and the taint propagation path data are packaged into attack event data, and the packaged attack event data is synchronized to the main thread security log.
4. The multi-threaded collaborative taint analysis method based on WebWorker according to claim 2, characterized in that, The step of reordering all tasks in the Worker waiting queue according to the priority marking results, selecting the target task with the highest priority for taint propagation analysis, and obtaining taint analysis data also includes: The Worker waiting queue synchronizes the taint analysis results to the main thread, and the main thread updates the status of the DOM operation log by obtaining the corresponding DOM operation based on the taint analysis results. Based on the state update results, the DOM operation is added as a new node to the main thread DOM tree, and the DOM operation is bound to an API hook function for dynamic monitoring.
5. The multi-threaded collaborative taint analysis method based on WebWorker according to claim 1, characterized in that, The process of updating the Worker waiting queue based on the taint analysis data and feeding back the updated Worker waiting queue status to the main thread for the next round of task allocation, thereby obtaining multi-threaded collaborative scheduling data, specifically includes: Based on the taint analysis data, the target task to be processed is removed from the Worker waiting queue, and the next optimal task to be processed is selected according to the priority sorting result, and the Worker waiting queue is updated. The idle status of the Worker waiting queue after the task update is obtained, and the status of the Worker waiting queue is fed back to the main thread for the next round of task allocation, thus obtaining multi-threaded collaborative scheduling data.
6. The multi-threaded collaborative taint analysis method based on WebWorker according to claim 1, characterized in that, The main thread periodically retrieves the waiting queue length of all Worker threads and determines whether each Worker thread is in an idle state ready to process new tasks based on the waiting queue length. Specifically, this includes: The main thread periodically obtains the waiting queue length of all Worker threads and determines whether the waiting queue length exceeds the preset maximum processing queue threshold. If so, the priority of the current Worker thread is reduced, and other Worker threads are sorted according to the length of the waiting queue. The idle state of the Worker thread is determined according to the priority sorting result. Select the worker thread with the best idle state to assign new tasks, and monitor the change in the waiting queue length of the current worker thread that exceeds the maximum processing queue threshold. When the waiting queue length of the current Worker thread is less than the preset minimum processing queue threshold, the current Worker thread is reordered by priority.
7. The multi-threaded collaborative taint analysis method based on WebWorker according to claim 1, characterized in that, Before the main thread periodically obtains the waiting queue length of all Worker threads and determines whether each Worker thread is in an idle state ready to process new tasks based on the waiting queue length, the method further includes: Obtain web input data from the browser, and classify and label the web input data according to the data source, including user input source, external data source and sensitive storage source.
8. A multi-threaded collaborative taint protection architecture based on WebWorker, characterized in that, The system is applied to the WebWorker-based multi-threaded collaborative taint analysis method according to any one of claims 1-7, and the architecture includes: The initialization configuration module is used to initialize the browser's core parameters, computing resource allocation mechanism, and data structures; The taint source identification and marking module is used to monitor and identify taint data sources in real time and mark taint data in the taint status table; The DOM operation monitoring and logging module is used to monitor sensitive DOM operations in the browser in real time and generate DOM operation logs. The Worker task scheduling module is used to receive DOM operation logs and manage the Worker task queue through multi-threaded collaboration and priority processing. The taint propagation analysis module is used to execute core analysis logic in the Worker thread. Based on the taint status table and DOM operation log, it analyzes the propagation path of tainted data in the DOM tree and determines whether there is an XSS operation. The taint removal and defense response module is used to execute corresponding defense measures in the main thread based on the analysis results of the taint propagation analysis module. The defense measures include blocking XSS operations, removing taint marks, and recording attack events. The state synchronization module is used to synchronize the state between the main thread and the worker thread through a preset incremental update mechanism and synchronization mechanism.
9. A computer device comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that, When the processor executes the computer program, it implements the steps of the WebWorker-based multi-threaded collaborative taint analysis method as described in any one of claims 1 to 7.
10. A computer-readable storage medium storing a computer program, characterized in that, When the computer program is executed by a processor, it implements the steps of the WebWorker-based multi-threaded collaborative taint analysis method as described in any one of claims 1 to 7.