A reverse tracing method based on V8 call stack

Abstract

The application discloses a kind of reverse tracing methods based on V8 call stack, realize the real-time tracking and accurate attribution of the behavior of illegal write cookie in real webpage, can know each cookie field is by which script or function participated in illegal write, also know which third party or first party website should be responsible for this illegal behavior.The tracing framework can run on real website, through the innovative DFG construction logic, greatly improve the accuracy of data dependence tracking and the stability of reverse tracing.Make DFG can truly reflect dynamic data flow relationship, provide reliable data flow graph DFG for subsequent reverse tracking, avoid the incomplete or interruption of tracing result caused by DFG defect, further support the accurate extraction of illegal cookie data source.Through the attribute setter monitoring innovation of V8 engine layer, realize the comprehensive capture of illegal cookie assignment operation, provide complete initial data support for the tracing chain.

Description

TECHNICAL FIELD

[0001] The present application relates to the field of computer systems based on specific computing models, in particular, a reverse tracing method based on V8 call stack. BACKGROUND

[0002] The General Data Protection Regulation (GDPR) and the European Union's ePrivacy Directive require that, except for absolutely necessary cookies, websites must obtain explicit, informed consent from users before setting cookies for other analytical or advertising purposes. However, the actual implementation is far from meeting the compliance requirements - many websites still set tracking cookies or share user data without authorization. In addition, websites will also face serious reputation risks once exposed for cookie misuse or data breaches, further highlighting the importance of GDPR compliance.

[0003] In recent years, researchers have developed a variety of automated tools to detect whether a website sets cookies before user consent. CSChecker mainly focuses on detecting GDPR and CCPA cookie banner compliance issues, and CSChecker uses a simplified tracing method: checking the call stack when the violation occurs and identifying the script at the bottom of the call stack as the source of the violation. However, the authors of this method admit that the accuracy of this tracing method is lacking. Although this technology has made significant progress in identifying non-compliant websites, it can only point out that "a website has violated the regulations", but cannot further identify which script or third-party component caused the violation. The lack of this ability has important practical significance: if an illegal cookie is implanted by a third-party script without the website's knowledge, the website operator may still be held responsible and fined. Without the ability to identify the source script of the violation, website operators cannot fix the problem, and regulators cannot accurately hold people accountable. To fill this gap, this paper proposes applying data flow analysis techniques to cookie tracing - by tracking the source of each non-compliant cookie, locating the script or component it belongs to, and accurately identifying the true source of the violation.

[0004] The prior art has the following technical problems:

[0005] 1. Although these JavaScript data flow analysis techniques (including static and dynamic data flow analysis techniques) lay the foundation for browser-side privacy and security analysis, there is no method specifically designed to solve the problem of cookie violation tracking and responsibility attribution. Existing data flow analysis techniques can at most determine whether a website is in violation, but cannot point out which script triggered the violation write.

[0006] 2. A method of visually tracing the data source of a cookie that violates the law is (the data source of the cookie refers to the source string of the location of the initial definition of each field that makes up the cookie): build a complete inter-process data flow graph for all cookie-writing JavaScript functions in the website in the real world, and then traverse the entire complete inter-process data flow graph to enable each cookie to be traced back to the source of its constituent data. Complex inter-script dependencies can be captured through dynamic in-browser data flow analysis. However, a real-world website usually contains hundreds or even thousands of scripts. Building and maintaining a DFG for all these scripts will incur high runtime overhead, and such a construction method will cause the average page load time of a real web page to be much longer than 10 minutes, which is impractical and not suitable for real-world websites.

[0007] 3. Another method of tracing the data source of a cookie that violates the law is: theoretically, the tracing of a cookie can also be achieved through taint analysis, which labels all variable initialization locations as different taint sources and performs taint propagation, and observes a set of labels at the cookie writing location. However, a real-world website usually contains hundreds or even thousands of scripts, and usually contains thousands of JavaScript functions, resulting in too much overhead for taint propagation, and is also not suitable for real web pages.

[0008] 4. The existing DFG construction technology has two problems: first, using AST nodes as nodes is susceptible to variable aliasing, which can lead to misjudgment of data dependency relationships; second, it does not limit the establishment of directed edges between "the same runtime object addresses", and it is easy to cause a dead loop when traversing the data flow graph.

[0009] 5. Cookie assignment operation monitoring is not comprehensive: the existing technology does not achieve comprehensive monitoring by hooking the property setter method of Object in the V8 engine, and can only detect direct assignment scenarios such as "document.cookie = xxx", and cannot cover alias access or indirect assignment scenarios such as "var d = document; d.cookie = xxx" and "document ['cookie'] = xxx". SUMMARY

[0010] The present application is directed to: 1. The existing data flow analysis technology can only determine whether a website is in violation at most, and cannot point out which script triggered the violation write. There is no method to specifically solve the tracking and responsibility attribution problem of cookie violation; 2. The second and third methods in the above existing technical problems can trace the source of each field of the cookie, but are not suitable for real web pages, and are not technical problems existing in the technology specifically for cookie tracing. A reverse tracing framework based on V8 call stack is proposed, which realizes real-time tracking and accurate attribution of violation behavior in real web pages, and provides strong responsibility identification ability and repair basis for supervisors and developers. The specific content will be described in detail below.

[0011] The present application is realized by the following technical solutions:

[0012] The present application discloses a reverse tracing method based on V8 call stack, comprising:

[0013] Use the GDPR violation cookie detection tool to detect whether the website writes cookies without authorization of the user;

[0014] Load the website containing the violation cookie;

[0015] Establish an object mapping table between the abstract syntax tree AST node information and the runtime object address when the JavaScript script of the website runs;

[0016] Monitor the property setter method of Object in the V8 engine, and when the assignment operation for document.cookie is detected, capture the current JavaScript call stack;

[0017] Traverse the AST of each function in the call stack from the top of the stack to identify the data dependency relationship;

[0018] Map the AST node to the runtime object address using the object mapping table and construct a data flow graph DFG for each function;

[0019] Reverse trace all DFGs and extract the tracing results.

[0020] As a further improvement, the application monitors the property setter method of the Object in the V8 engine, and when detecting the assignment operation for document.cookie, the current JavaScript call stack is captured, specifically: hooking the property setter method of the Object in the V8 engine, when detecting the property assignment operation, checking whether the constructor of the assignment recipient object is HTMLDocument and whether the property name being assigned is cookie; if the above conditions are met, it is determined that the assignment operation is for document.cookie, and the current JavaScript call stack is immediately captured and the DFG construction step is activated.

[0021] As a further improvement, the application uses an object mapping table to map the AST node to the runtime object address and constructs a data flow graph DFG for each function, specifically:

[0022] The directed edge of the DFG is generated based on the assignment statement LHS = RHS in the function AST: by traversing all AST nodes of the right side expression RHS of the assignment statement, the object mapping table is used to map these AST nodes and the left side expression LHS to the corresponding runtime object address, and then the directed edge from LHS to RHS is established between the runtime object addresses of LHS and RHS nodes, and no directed edge is established between the same runtime object addresses in the construction process to avoid dead loops when backtracking.

[0023] As a further improvement, the application backtracks all DFGs and extracts the trace results, specifically:

[0024] A search list is maintained, and initially the runtime object address corresponding to the document.cookie write value is added to the search list;

[0025] The traversal order of the DFG is opposite to the execution order of the functions in the call stack, the DFG corresponding to the top function is traversed first, that is, the DFG corresponding to the function that performs the document.cookie assignment, and then the subsequent function DFG in the stack bottom direction is traversed;

[0026] In each DFG, find all predecessor nodes of the nodes that already exist in the search list, add all predecessor nodes to the search list, until there are no new predecessor nodes to add in the current DFG, and the search list is not deleted in the update process. The node has been found;

[0027] After traversing all DFGs, nodes with predecessor nodes are filtered in the search list, and nodes of type literal are retained. These nodes are the initial source strings that make up the fields of the cookie, serving as the source tracing result of the cookie data. The source tracing result is used to identify the responsible party for the illegal cookie.

[0028] As a further improvement, the search list described in this invention does not delete nodes that have already been searched during the update process. Specifically, for invalid assignment statements such as c = c || {}, only the nodes corresponding to {} are retained during reverse tracing. Combined with node type filtering, the interference of invalid nodes on the tracing results can be eliminated.

[0029] As a further improvement, the tracing results described in this invention are used to identify the responsible party for the illegal cookie, specifically by using the runtime object address corresponding to the literal node.

[0030] The present invention has the following beneficial effects:

[0031] 1) This paper proposes a novel reverse tracing framework based on the V8 call stack, enabling real-time tracking and precise attribution of unauthorized cookie writing in real web pages. It identifies which scripts or functions were involved in the unauthorized writing of each cookie field, thus determining which third-party or first-party websites should be held responsible for such violations. Existing data stream analysis techniques for browser web pages can only detect which website wrote the unauthorized cookie, but cannot identify which scripts and functions were used to write it.

[0032] Existing data flow analysis techniques for browser web pages can only detect which website wrote the illegal cookie, but cannot identify which scripts and functions wrote the cookie. This study aims to achieve real-time tracking and precise attribution of illegal cookie writing behavior on real web pages. To verify the effectiveness of this source tracing analysis framework, 20 websites from the Tranco Top 100K list that illegally wrote cookies were randomly selected (the websites in the Tranco Top 100K list were detected using CSChecker; the reference is from existing solutions). Ten of these websites wrote non-compliant consent cookies, and the other 10 wrote non-compliant unnecessary cookies. The cookie writing operations on these websites originated from 15 different scripts to ensure the generality of the evaluation. The evaluation scope was limited to 20 cases because manually collecting all source strings of the target cookie value is very time-consuming. In real-world websites, JavaScript code is often poorly readable due to excessive compression and complex, deeply nested function calls. The following definition is used when evaluating this source tracing analysis framework: True Positive (TP) A True Positive (TP) represents a correctly identified cookie source. False negatives (FN) indicate the number of source strings missed by the source tracing analysis framework relative to all cookie source strings. Recall is calculated as: Recall = TP / (TP + FN). Based on manually collected cookie source data from 20 sites, the Recall rate was 73.2%. The results of manual analysis show that the proposed reverse tracing framework based on the V8 call stack has high accuracy in tracing cookies.

[0033] This tracing framework can run on real websites, overcoming the problem that methods 2 and 3 in the existing technology are too expensive to run on real web pages.

[0034] 2) Addressing the shortcomings of existing Data Flow Graph (DFG) construction, this invention significantly improves the accuracy of data dependency tracing and the stability of reverse tracing through innovative DFG construction logic. In the fourth issue of existing technologies, DFG construction relies on AST nodes and fails to restrict edges created from the same address, leading to misjudgments, infinite loops, and dependency omissions. This invention proposes three innovations in the DFG construction stage: First, it uses "runtime object addresses" as DFG nodes, linking AST nodes with dynamic addresses using an object mapping table, thus fundamentally solving the dependency misjudgment problem caused by variable aliases; second, it explicitly states "no directed edges are created between the same runtime object addresses," avoiding the risk of infinite loops during reverse tracing and ensuring the continuous stability of the tracing process. This innovative logic enables the DFG to truly reflect dynamic data flow relationships, providing a reliable data flow graph DFG for subsequent reverse tracing, avoiding incomplete or interrupted tracing results due to DFG defects, and further supporting the accurate extraction of the data source of illegal cookies.

[0035] 3) By innovating the property setter monitoring at the V8 engine layer, this invention achieves comprehensive capture of illegal cookie assignment operations, providing complete initial data support for the tracing chain. In the existing technology's problem 5, cookie assignment monitoring only covers direct assignment scenarios and cannot capture scenarios such as alias access (e.g., var d=document; d.cookie=data) and indirect property access (e.g., document["cookie"]=data), leading to some illegal operations being missed. This invention innovatively adopts a monitoring logic of "hooking the property setter method of Object in the V8 engine." Through "double judgment" (the constructor of the assignment receiver object is HTMLDocument, and the assigned property name is "cookie"), illegal assignment behavior is defined. Regardless of whether the script uses direct assignment, alias assignment, or indirect property access, as long as the assignment operation ultimately points to document.cookie, it can be accurately detected. Attached Figure Description

[0036] Figure 1 This is a flowchart of the algorithm of the present invention;

[0037] Figure 2 This is the data flow diagram of funcC in specific implementation use case 1;

[0038] Figure 3 This is the data flow diagram of funcB in specific implementation use case 1;

[0039] Figure 4 This is the data flow diagram of funcA in specific implementation use case 1;

[0040] Figure 5 This is the data flow diagram for Global in specific implementation use case 1. Detailed Implementation

[0041] The technical solution of the present invention will be further described below with reference to the accompanying drawings and specific implementation examples:

[0042] A reverse tracing framework based on the V8 call stack consists of four stages:

[0043] (1) During the runtime recording phase, the source analysis framework draws on the object mapping table in the Arcanum scheme (mapping AST node information to runtime object addresses) to establish the mapping relationship between AST node information and runtime object addresses.

[0044] (2) The source analysis framework monitors V8's assignment statements to properties, and captures the current call stack when it detects that an assignment to a cookie has occurred.

[0045] (3) The source analysis framework traverses each function in the call stack starting from the top of the stack, traverses the abstract syntax tree (AST) of each function, and determines the data dependency relationship through the edges between AST nodes (using data flow methods such as assignment and parameter passing as edges). With the help of the object mapping table mentioned in (1), the AST nodes are mapped to runtime object addresses, and the runtime object addresses are used as nodes of the data flow graph to construct the data flow graph (DFG) for each function in the call stack.

[0046] (4) In the reverse tracing (data source location) phase, the source tracing analysis framework maintains a search list. First, the framework adds the runtime object address corresponding to the cookie value to the search list. Then, it searches for the predecessor node in the DFG corresponding to the function at the top of the stack (the JavaScript function that writes the cookie and assigns `document.cookie`). All predecessor nodes are then used to update the search list. After traversing all DFGs, all nodes in the search list without predecessor nodes and of type literal (including object literals) are extracted as the source tracing results.

[0047] To explain (1) in detail: During the execution of a JavaScript script, the Chromium V8 engine (which is used in Chromium functions to compile and execute JavaScript code) first parses the JavaScript source code into an AST and allocates memory on the heap for each AST node. The AST, as a static structure, can be accessed through the call stack. The memory address of the variable (runtime object address) is only dynamically generated at runtime and is crucial for DFG construction (3) and data source location (4), which are runtime objects. To this end, the tracing analysis framework maintains an object mapping table at runtime, associating AST nodes with their corresponding runtime object addresses one by one, supporting subsequent node location and reverse tracing.

[0048] To explain (2) in detail: The only way JavaScript code can access cookies is through `document.cookie`. However, cookies can still be written in several ways. First, the script can create an alias for `document` and use that alias to define cookies, for example: `var d = document; d.cookie = data;`. Second, cookie properties can also be accessed in different ways, such as `document["cookie"]`. In V8, JavaScript variables are represented as instances of Object. Therefore, to comprehensively detect non-compliant cookie writing behavior, this profiling framework hooks the setter methods of Object properties. Then, it checks whether the constructor of the receiving object is `HTMLDocument` and whether its property name is equal to `cookie`. Upon detecting a target cookie being written, the profiling framework immediately captures the current JavaScript call stack and activates the DFG build phase.

[0049] A detailed explanation of (3) is as follows:

[0050] (3.1) Nodes in the Data Flow Graph. This sourcing analysis framework selects object addresses, rather than AST node information, as nodes. When establishing edge relationships, it looks up the object mapping table to obtain the runtime object memory address corresponding to each AST node and establishes directed edges between different memory addresses. This approach solves a major problem: in a data flow graph, edges represent data dependencies between objects. For example, the assignment statement `var a=b` creates an edge between `a` and `b`. Therefore, a direct way to identify data flow is to examine the AST structure, i.e., add edges after each assignment operation. However, since an object can be accessed using multiple aliases (and therefore different AST nodes), it is very difficult to trace data dependencies based solely on the AST. In contrast, memory addresses provide a unique identifier for each object, regardless of the variable name. Using memory addresses as nodes also naturally handles the AST node variations caused by aliases (e.g., multiple variables referencing the same object).

[0051] (3.2) Edges in the Data Flow Graph. Within a function, the primary data flow occurs through assignment statements. This sourcing analysis framework starts from the function's AST structure, searching for assignment statements like LHS = RHS, where LHS is the left-hand expression and RHS is the right-hand expression. It iterates through all AST nodes in the RHS of the right-hand expression and adds an edge between it and the left-hand expression. This edge is a directed edge from LHS to RHS, LHS->RHS. For example, when the statement ab = c + de appears, this sourcing analysis framework establishes three directed edges from ab to c, d, and e. It's important to note that the reverse sourcing method utilizes directed edges between object addresses. To avoid entering an infinite loop during reverse sourcing, this sourcing analysis framework does not add edges between identical memory addresses (i.e., it addresses variable aliasing issues).

[0052] A detailed explanation of (4) is as follows:

[0053] The source tracing analysis framework embeds the task of building the DFG into the process of the V8 engine processing the assignment statement, and monitors whether the assignment operation is completed in real time. When the source tracing analysis framework finds that the assignment operation is completed and the assigned object is document.cookie, it means that the source tracing analysis framework has completed the runtime recording, started the task of building the DFG, and triggered reverse tracing. In the reverse tracing process, the source tracing analysis framework establishes and maintains a search list and traverses all the DFGs obtained in (3). The order of traversing the DFGs is opposite to the direction of the function execution call chain (hence the name reverse tracing). First, the source tracing analysis framework adds the address of the cookie's write value to the search list. Then, it traverses all edges in the DFG corresponding to the function at the top of the stack and finds the predecessor node of the cookie's write value address (i.e., the edge with the cookie's write value address as the endpoint). Then, it adds these predecessor nodes as new nodes to the search list and continues to search for the predecessor nodes of all new nodes in the current DFG. Until all nodes in the search list have been searched in the current DFG or their predecessor nodes cannot be found in the current DFG, it enters the DFG of the next function. The search process described above within a single DFG_i is referred to as "updating the search list with DFG_i". After updating the search list with all DFGs, the search list stores the final source tracing result, which is the final source tracing. During the search list update process, this source tracing analysis framework does not delete nodes that have been searched. In the reverse tracing process, for statements like c = c || {}, when the right-hand c is not empty, the left and right c will share a memory address. Since this source tracing analysis framework does not establish edges between the same memory addresses, it can only establish an edge {} -> c. Thus, the true source of c will be lost during reverse tracing. To avoid similar invalid assignment statements compromising the accuracy of source tracing, nodes that have been searched are retained in the search list. Furthermore, when finally extracting the string source, these searched nodes can be filtered by node type (if the node type is literal, including object literal, it is the source of the final string to be extracted), preventing misjudgments.

[0054] The following is a JavaScript example code for implementing use case 1:

[0055] .function funcA(a) {

[0056] var b = a + "123";

[0057] funcB(b);

[0058] }

[0059] function funcB(b) {

[0060] var c = b + "456";

[0061] funcC(c);

[0062] }

[0063] function funcC(c) {

[0064] var x = c + "789";

[0065] document.cookie = x;

[0066] }

[0067] function funcD() { ...

[0069] }

[0070] function funcE() { ...

[0072] }

[0073] var a = "CookieName=";

[0074] funcA(a);

[0075] For example, in specific implementation use case 1, explain what the cookie data source is (the source string where the initial definition of each field that makes up the cookie is located): according to Figure 1The execution logic of this implementation use case is as follows: The process described is: "Real website JavaScript source code → Runtime recording → Detecting cookie writing → Capturing V8 call stack → Constructing data flow graphs of functions in the stack → Tracing back through the data flow graph → Cookie source tracing results". In the JavaScript example code of specific implementation use case 1, "CookieName=" in `var a = "CookieName=" is the cookie data source, "123" in `var b = a + "123" is the cookie data source, "456" in `var c = b + "456" is also the cookie data source, and "789" in `var x = c + "789" is also the cookie data source. During the runtime recording phase, the mapping relationship between the AST node information of each variable and the runtime address is recorded in the object mapping table. The system monitors whether cookies are written during code execution. When `document.cookie` is detected being written to `funcC`, the V8 call stack is captured. At this point, the functions in the call stack are Global->funcA->funcB->funcC (showing the functions from bottom to top of the stack, representing the call relationships between functions; note that the data flow graph is constructed in the order of functions from top to bottom). Starting from the top of the stack, each function in the call stack is traversed. The data flow graph for `funcC` is constructed first, then for `funcB`, then for `funcA`, and finally for the Global scope (the outermost Global scope is also treated as a function and placed on the call stack). Data flow graphs for functions `funcD` and `funcE`, which are unrelated to writing the cookie, are not constructed. A search list is maintained, initially containing only `document.cookie`. Starting from the function `funcC` that writes the cookie, the data flow graph of `funcC` is traversed (e.g.,...). Figure 2 All edges (as shown) are added to the search list along with the predecessor nodes of document.cookie (variables x, c, and "789" in funcC). The search list is then updated so that its contents are: document.cookie, variable x in funcC, variable c in funcC, and "789". Then the data flow graph of funcB is traversed again (as shown). Figure 3For all edges in the search list (as shown), add the predecessor node of each node in the search list (the predecessor nodes of variable c in funcC are b and "456" in function funcB) as new nodes to the search list, update the search list so that the current content of the search list is: document.cookie, variable x in funcC, variable c in funcC, "789", variable b in funcB, "456". Then traverse the data flow graph of funcA (as shown). Figure 4 For all edges in the search list (as shown), add the predecessor node of each node in the search list (the predecessor node of variable b in funcB is variable a and "123" in function funcA) as a new node to the search list, update the search list, and the current content of the search list is: document.cookie, variable x in funcC, variable c in funcC, "789", variable b in funcB, "456", variable a in function funcA, and "123". Finally, traverse the data flow graph of the Global scope (as shown). Figure 5 As shown in the diagram, the predecessor node of variable a in function funcA is "CookieName=", which is added to the search list. The search list now contains: document.cookie, variable x in funcC, variable c in funcC, "789", variable b in funcB, "456", variable a in function funcA, "123", and "CookieName=". Finally, when extracting the string source, the search list is filtered by node type (if the node type is literal, including object literal, it represents the source of the final string to be extracted). The sources of all cookie strings are extracted as "789", "456", "123", and "CookieName=".

[0076] The following is the core code used to write the invalid cookie in a real website in specific implementation use case 2:

[0077] / / id.json file provides cookie values

[0078] cXJsonpCB1({"httpStatus":200,

[0079] "response":{"userId":"cx%3A2ulhcqiwlzx431xc5hqkse46g1%3A3njkwv040eb5m",

[0080] "newUser":true}})

[0081] / / The core code of cx.js, the script that writes an invalid cookie named cX_G.

[0082] no(s + "&callback={{callback}}", (function(t) {

[0083] try {

[0084] var n = t.response;

[0085] e.library.m_isNewUser = n.newUser,

[0086] so(n.userId),

[0087] Kn(o) && o(t)

[0088] }

[0089] }))

[0090] function so(t) {

[0091] Wi("cX_G", t, e.library.m_maxCookieExpires, " / ", qi())

[0092] .}

[0093] function Wi(t, n, r, i, o, a, c) {

[0094] e.library._consent.cookie.set(t, n, {

[0095] expires: r || void 0,

[0096] path: i,

[0097] domain: o,

[0098] secure: (a || e.library.m_usesSecureCookies) &&e.env.isSecureProtocol,

[0099] samesite: a && e.env.canSetSameSite && "lax"

[0100] }, c || 1024)

[0101] }

[0102] set: function(e, t, n, r) {

[0103] l.set(e, null !== (i = o.data) && void 0 !== i ? i : t, n, r)

[0104] }

[0105] t = function(t, n, r, i) {

[0106] document.cookie = e(t, n, r);

[0107] }

[0108] As shown in Specific Implementation Use Case 2, the core code of a reverse attribution example on a real website is provided. CSChecker detects that the website has illegally written an unnecessary cookie. The content of this cookie is "cX_G=cx%3A2ulhcqiwlzx431xc5hqkse46g1%3A3njkwv040eb5m; expires=Sat, 29 Aug 2026 07:06:16 GMT; path= / ; secure". The `no` function in the script `cx.js`, which writes the illegal cookie named `cX_G`, retrieves the user ID (`userId`) from the JSON file providing the cookie value via a callback. Subsequently, this user ID is passed as a parameter to the `t` function through a function call. Ultimately, the script `cx.js`, which writes the illegal cookie named `cX_G`, writes the `userId` into the cookie value within the `t` function without the user's authorization—this behavior violates the General Data Protection Regulation (GDPR). By tracing back to the source, it was found that only the cookie value came from "userId":"cx%3A2ulhcqiwlzx431xc5hqkse46g1%3A3njkwv040eb5m" in the id.json file; all other fields came from the script cx.js, which wrote an illegal cookie named cX_G. The cookie name came from the string constant "cX_G" in the so function call Wi in the script cx.js.

[0109] Those skilled in the art will understand that the above description is merely a single example of the invention and is not intended to limit the invention. Although the invention has been described in detail with reference to the foregoing examples, those skilled in the art can still modify the technical solutions described in the foregoing examples or make equivalent substitutions for some of the technical features. All modifications and equivalent substitutions made within the spirit and principles of the invention should be included within the scope of protection of the invention.

Claims

1. A reverse tracing method based on the V8 call stack, characterized in that, include: Use GDPR violation cookie detection tools to check whether websites write cookies without the user's authorization; Loading websites containing illegal cookies; An object mapping table is created between the Abstract Syntax Tree (AST) node information and the runtime object addresses during the JavaScript execution of the website. Monitor the setter methods of Object properties in the V8 engine, and capture the current JavaScript call stack when an assignment operation to document.cookie is detected; Traverse the AST of each function in the call stack, starting from the top of the stack, to identify data dependencies; Use an object mapping table to map AST nodes to runtime object addresses and build a data flow graph (DFG) for each function. Traverse all DFGs in reverse and extract the source tracing results.

2. The reverse tracing method based on the V8 call stack according to claim 1, characterized in that, The monitoring of the setter methods of the Object property in the V8 engine captures the current JavaScript call stack when an assignment operation for document.cookie is detected. Specifically, it hooks the setter methods of the Object property in the V8 engine. When an assignment operation is detected, it checks whether the constructor of the assignment receiver object is HTMLDocument and whether the name of the assigned property is cookie. If the above conditions are met, it is determined to be an assignment operation for document.cookie, and the current JavaScript call stack is immediately captured and the DFG build step is activated.

3. The reverse tracing method based on the V8 call stack according to claim 2, characterized in that, The process of using an object mapping table to map AST nodes to runtime object addresses and constructing a data flow graph (DFG) for each function is as follows: The directed edges of DFG are generated based on the assignment statement LHS = RHS in the function AST: by traversing all AST nodes of the expression RHS on the right side of the assignment statement, and using the object mapping table, these AST nodes and the expression LHS on the left side are mapped to the corresponding runtime object addresses respectively. Then, directed edges from LHS to RHS are established between the runtime object addresses of each node of LHS and RHS. During the construction process, directed edges are not established between the same runtime object addresses to avoid infinite loops when tracing backward.

4. The reverse tracing method based on the V8 call stack according to claim 1, characterized in that, The reverse tracing process involves traversing all DFGs and extracting the source tracing results, specifically as follows: Maintain a search list, initially adding the runtime object address corresponding to the document.cookie value to the search list; The order of traversing the DFG is the reverse of the execution order of functions in the call stack. First, the DFG corresponding to the function at the top of the stack, that is, the DFG corresponding to the function that executes the document.cookie assignment, is traversed, and then the DFGs of subsequent functions in the direction of the bottom of the stack are traversed in turn. In each DFG, find the predecessor nodes of all nodes that already exist in the search list, and add all predecessor nodes to the search list until there are no new predecessor nodes to add in the current DFG. The search list does not delete nodes that have been searched during the update process. After traversing all DFGs, nodes with predecessor nodes are filtered in the search list, and nodes of type literal are retained. These nodes are the initial source strings that make up the fields of the cookie, serving as the source tracing result of the cookie data. The source tracing result is used to identify the responsible party for the illegal cookie.

5. The reverse tracing method based on the V8 call stack according to claim 4, characterized in that, The search list does not delete nodes that have already been searched during the update process. Specifically, for invalid assignment statements such as c = c || {}, only the nodes corresponding to {} are retained during reverse tracing. Combined with node type filtering, the interference of invalid nodes on the tracing results can be eliminated.

6. The reverse tracing method based on the V8 call stack according to claim 5, characterized in that, The source tracing results are used to identify the responsible party for the illegal cookie. Specifically, by using the runtime object address corresponding to the literal node and combining the association between the AST node and the script, the script or function that generated the cookie field is located, and the responsibility of the first-party or third-party component for the illegal cookie writing behavior is clarified.

Images