Script injection method and device and terminal

Abstract

The invention discloses a script injection method and device and a terminal. In response to a security monitoring request triggered for a target rendering process in the browser, obtaining an original script to be injected into the target rendering process from a host process of the browser; encoding the original script according to a readable encoding format corresponding to the browser to obtain an encoding script corresponding to the original script; and sending the coding script to a target rendering process through a data sending function of the host process, so that the target rendering process receives the coding script and performs anti-coding to obtain an original script. According to the method, the original script obtained from the browser host process is coded according to the coding format corresponding to the browser to obtain the coded script, so that the script compatibility can be improved, and execution errors caused by format mismatching are reduced. Then the coding script is sent to the rendering process through the data sending function of the host process, and it can be ensured that the coding script is accurately injected into the rendering process in time by means of the high efficiency and stability of an internal communication mechanism of a browser.

Description

TECHNICAL FIELD

[0001] The present application relates to the field of network security, and in particular to a script injection method, device and terminal. BACKGROUND

[0002] Script injection technology is to insert one or more pieces of script code into a target system to perform specific tasks or operations. In the field of browser security protection, script injection technology is usually used to analyze web page content, detect and prevent potential malicious behavior. Once a threat is detected, the browser or security software will take immediate action to intercept and block, thereby protecting the browser from attack. However, due to the particularity of different browsers in security mechanisms, underlying designs, etc., the existing security protection of browsers through script injection technology still has the problems of inconvenient operation, low stability, etc., and cannot provide continuous and stable security protection for browsers in all cases. SUMMARY

[0003] The present application provides a script injection method, device and terminal to solve the above-mentioned problems of inconvenient operation, low stability, etc. in the security protection of browsers through script injection technology.

[0004] In a first aspect, an embodiment of the present application provides a script injection method, which comprises:

[0005] In response to a security monitoring request triggered for a target rendering process in a browser, obtaining an original script to be injected into the target rendering process from a main process of the browser;

[0006] Encoding the original script according to a readable encoding format corresponding to the browser to obtain an encoded script corresponding to the original script;

[0007] Sending the encoded script to the target rendering process through a data sending function of the main process, so that the target rendering process receives the encoded script and performs reverse encoding to obtain the original script.

[0008] In a second aspect, an embodiment of the present application provides a script injection device, which comprises:

[0009] An original script obtaining module configured to obtain an original script to be injected into a target rendering process from a main process of a browser in response to a security monitoring request triggered for the target rendering process in the browser;

[0010] An encoded script obtaining module configured to encode the original script according to a readable encoding format corresponding to the browser to obtain an encoded script corresponding to the original script;

[0011] The script sending module is configured to send the encoded script to the target rendering process through a data sending function of the main process, so that the target rendering process receives the encoded script and decodes the encoded script to obtain the original script.

[0012] In a third aspect, the embodiments of the present application provide a computer storage medium, which stores a plurality of instructions, and the instructions are suitable for being loaded by a processor and performing the steps of the method.

[0013] In a fourth aspect, the embodiments of the present application provide a terminal, which comprises a memory, a processor, and a computer program stored in the memory and capable of running on the processor, and the computer program is suitable for being loaded by the processor and performing the steps of the method.

[0014] The technical solutions provided by some embodiments of the present application have at least the following beneficial effects:

[0015] The script injection method provided by the present application comprises the following steps: in response to a security monitoring request triggered for a target rendering process in a browser, obtaining an original script to be injected into the target rendering process from a main process of the browser; encoding the original script according to a readable encoding format corresponding to the browser to obtain an encoded script corresponding to the original script; and sending the encoded script to the target rendering process through a data sending function of the main process, so that the target rendering process receives the encoded script and decodes the encoded script to obtain the original script. When security monitoring of the target rendering process is needed, the original script to be injected is first obtained from the main process of the browser, which ensures that the script injection behavior is performed under the security monitoring framework inside the browser, effectively preventing unauthorized execution of malicious scripts. Then, the original script is encoded according to the readable encoding format corresponding to the browser, which can convert the original script into a format that can be efficiently understood and executed by the browser kernel, and the encoded script data can be securely transmitted between the main process and the target rendering process to ensure that the script is correctly executed in the target rendering process. Next, the encoded script is securely and efficiently transmitted to the target rendering process through the data sending function of the main process. This process fully utilizes the efficiency and stability of the internal communication mechanism of the browser, ensuring that the encoded script can be injected into the target rendering process in a timely and accurate manner without relying on specific plug-ins or user operations. The present application can realize an automatic script injection process and real-time protection without affecting the browser by defining the original script and the data sending function in the main process of the browser. BRIEF DESCRIPTION OF DRAWINGS

[0016] In order to more clearly illustrate the technical solutions in the embodiments of the present application or the prior art, the following will briefly introduce the drawings needed to be used in the embodiments or prior art description. Obviously, the drawings in the following description only represent some of the embodiments of the present application, and all other drawings obtained by those skilled in the art without creative effort based on these drawings also belong to the protection scope of the present application.

[0017] Figure 1 An exemplary system architecture diagram of a script injection method provided by an embodiment of the present application;

[0018] Figure 2 A flowchart of a script injection method provided by an embodiment of the present application;

[0019] Figure 3 A flowchart of a script injection method provided by an embodiment of the present application;

[0020] Figure 4 A specific implementation flowchart of a script injection method provided by an embodiment of the present application;

[0021] Figure 5 A flowchart of a script injection method provided by an embodiment of the present application;

[0022] Figure 6 A structural block diagram of a script injection device provided by an embodiment of the present application;

[0023] Figure 7 A structural diagram of a terminal provided by an embodiment of the present application. DETAILED DESCRIPTION

[0024] In order to make the features and advantages of the present application more obvious and easy to understand, the following will combine the drawings in the embodiments of the present application to clearly and completely describe the technical solutions in the embodiments of the present application. Obviously, the described embodiments only represent some of the embodiments of the present application, but not all the embodiments. Based on the embodiments in the present application, all other embodiments obtained by those skilled in the art without creative effort also belong to the protection scope of the present application.

[0025] The following description refers to the accompanying drawings. Unless otherwise indicated, same or similar elements in different drawings have the same or similar reference numbers. The implementations described in the following exemplary embodiments do not represent all implementations consistent with the present application. Instead, they are merely examples of apparatuses and methods consistent with some aspects of the present application as detailed in the appended claims.

[0026] In the field of browser security, script injection technology is widely used in the deep analysis of web page content, aiming to detect and effectively prevent potential malicious behavior. When a browser accesses a web page, script injection technology inserts detection scripts (such as JavaScript scripts) in real time through script execution interfaces or browser extensions during the loading process of the web page. These scripts monitor Uniform Resource Locator (URL), resource requests, page content, and other key information in the web page and perform real-time analysis. Through the analysis of this information, scripts can identify potential security threats such as hidden malicious code, phishing attacks attempting to steal user information, etc. Once these threats are detected, the browser or security software will take immediate action to block and prevent them, thereby protecting the browser from attacks.

[0027] However, due to the particularity of different browsers in security mechanisms, underlying designs, etc., some specific kernel browsers currently do not directly provide script execution interfaces (such as Google Chrome, Microsoft Edge, and other browsers based on the Chromium kernel). This means that traditional security protection techniques cannot fully monitor and intercept browser behavior through direct interface calls, making it difficult for security software to provide complete browser security protection. In addition, script injection through browser extensions (such as Chrome extensions) also relies on user manual installation and is easily deleted or interfered with by malicious software, making it difficult for extensions to provide continuous and stable security protection.

[0028] Therefore, the embodiments of the present application provide a script injection method to solve the above-mentioned problems of inconvenient operation, poor stability, etc. in script injection through script execution interfaces or browser extensions.

[0029] Please refer to Figure 1 , Figure 1 An exemplary system architecture diagram of a script injection method provided by the embodiments of the present application.

[0030] As shown in Figure 1 , the system architecture can include a terminal 101, a network 102, and a server 103. The network 102 is used to provide a communication link medium between the terminal 101 and the server 103. The network 102 can include various types of wired communication links or wireless communication links, such as: wired communication links including optical fiber, twisted pair or coaxial cable, wireless communication links including Bluetooth communication links, Wireless-Fidelity (Wi-Fi) communication links or microwave communication links, etc.

[0031] The terminal 101 can interact with the server 103 through the network 102 to receive or send messages from or to the server 103, or the terminal 101 can interact with the server 103 through the network 102 to receive messages or data sent by other users to the server 103. For example, the server 103 stores a script update package, when the browser on the terminal 101 needs to update or inject a new script, it sends a script update request to the server 103, and the server 103 responds to the request and sends the script update package to the terminal 101, and the terminal 101 receives the script and then encodes and injects the script into the target rendering process.

[0032] The terminal 101 can be hardware or software. When the terminal 101 is hardware, it can be various electronic devices, including but not limited to smart phones, tablet computers, laptop computers, desktop computers, etc. When the terminal 101 is software, it can be installed in the above-mentioned electronic devices, and can be implemented as multiple software or software modules (for example, to provide distributed services), or as a single software or software module, which is not specifically limited here.

[0033] In the embodiments of the present application, the terminal 101 first acquires the original script to be injected into the target rendering process from the main process of the browser in response to the security monitoring request triggered for the target rendering process in the browser; then the terminal 101 encodes the original script according to the readable encoding format corresponding to the browser to obtain the encoded script corresponding to the original script; finally, the terminal 101 sends the encoded script to the target rendering process through the data sending function of the main process, so that the target rendering process receives the encoded script and decodes it to obtain the original script.

[0034] The server 103 can be a service server providing various services. It should be noted that the server 103 can be hardware or software. When the server 103 is hardware, it can be implemented as a distributed server cluster composed of multiple servers, or as a single server. When the server 103 is software, it can be implemented as multiple software or software modules (for example, to provide distributed services), or as a single software or software module, which is not specifically limited here.

[0035] Alternatively, the system architecture can also not include the server 103, in other words, the server 103 can be an optional device in the embodiments of the present specification, that is, the method provided in the embodiments of the present specification can be applied to a system structure including only the terminal 101, and the embodiments of the present application do not limit this.

[0036] It should be understood that Figure 1The number of terminals, networks and servers in the system is only illustrative, and can be any number of terminals, networks and servers according to the needs of implementation.

[0037] Please refer to Figure 2 , Figure 2 A flowchart of a script injection method provided by an embodiment of the present application. The execution subject of the embodiment of the present application can be a terminal that executes the script injection, can be a processor in the terminal that executes the script injection method, or can be a script injection service in the terminal that executes the script injection method. For the convenience of description, the specific execution process of the script injection method is introduced below by taking the execution subject as the processor in the terminal.

[0038] As shown in Figure 2 , the script injection method can at least include:

[0039] S202, in response to a security monitoring request triggered for a target rendering process in a browser, obtaining an original script to be injected into the target rendering process from a main process of the browser.

[0040] Optionally, the browser is the main entrance for users to access the Internet, and may face various malicious attacks from the network, such as code injection, cross-site scripting attack, phishing attack, etc., so the browser can be protected by injecting a security protection module into the browser. The security protection module can integrate various security policies, such as access control, data encryption, vulnerability scanning, etc., by executing these policies uniformly in the security protection module, it can monitor and defend against various attacks that may occur in the browser in real time, and protect the personal information and data security of the user.

[0041] Optionally, since the browser is usually composed of multiple processes, including a main process (usually responsible for the user interface, bookmark management, extension program, etc.), a rendering process (responsible for the rendering and script execution of web page content), etc., and the main process is the core component of the browser, responsible for managing and coordinating the running of other processes, such as starting and closing the browser, managing the display of the user interface, processing network requests, storing and managing history records, etc., therefore the security protection module can be injected into the main process of the browser. By uniformly managing and executing the security policy through the main process, it can monitor all data streams in and out of the main process in real time, including network requests, user inputs, script codes, etc., and can also avoid the dispersion of security policies in multiple rendering processes or other components, resulting in increased management complexity and vulnerability risk.

[0042] Optionally, when opening a webpage or the like in the browser, the target rendering process corresponding to the webpage to be processed loads and executes the resources required by the webpage. In this process, malicious code may be included, which is used to steal user information, destroy the browser system, and the like. Therefore, by loading and executing the detection script in the target rendering process in real time, the resource request, page content, and the like in the webpage can be analyzed in real time, and potential security threats can be identified.

[0043] Optionally, since the main process is the control center of the browser, it is responsible for managing the creation, destruction, and communication of all rendering processes, and the detection script can be dynamically generated according to user operations or page context. Therefore, it is usually necessary to load and execute in real time when the user interacts with the page. The main process can monitor user input and changes in page state in real time, so the main process can be selected as the center of script management, and all scripts that need to be injected into the target rendering process can be managed centrally. Specifically, a script injection method is set in the security protection module of the browser main process, the user operation and the change of the page state are monitored in real time by the main process, and when security monitoring of the target rendering process is needed, the corresponding detection script is dynamically obtained and sent to the target rendering process through Inter-Process Communication (IPC) in the browser and executed, thereby ensuring the stability and security of the target rendering process.

[0044] Optionally, in order to protect the security of user data and the normal display of webpage content, the security protection module of the browser main process will perform real-time security monitoring. Specifically, when it is monitored that the target rendering process (for example, a tab page in the browser) performs certain operations (such as loading a new page), a security monitoring request for the target rendering process will be triggered in the security protection module of the browser main process. At this time, it is necessary to obtain the corresponding detection script and execute it in the target rendering process.

[0045] Optionally, when the security monitoring request for the target rendering process is triggered, the method in the present application retrieves the original script to be injected, that is, the detection script that needs to be executed in the target rendering process, from the main process of the browser. These scripts can be predefined and stored on a local or remote server, or dynamically generated according to the context of the page. In the process of obtaining the original script, it is necessary to ensure that only authorized and verified scripts can be selected for injection, including but not limited to verification of the source of the script, hash verification of the content of the script, and the like, in order to prevent illegal injection of malicious scripts.

[0046] S204, encode the original script according to the readable encoding format corresponding to the browser to obtain an encoded script corresponding to the original script.

[0047] Alternatively, because different browsers may use different kernels and data parsing mechanisms, and the original script may contain various characters, comments, and format differences, these will increase the complexity of the browser kernel's parsing and execution of the original script. Furthermore, the original script may contain sensitive information such as passwords and keys. These original scripts need to be sent from the browser's main process to the target rendering process. During the data transmission process, direct exposure of the original script may put it at risk of being obtained or maliciously tampered with. Based on this, it is possible to consider encoding the original script in a browser-readable encoding format to achieve efficient and secure script transmission and injection.

[0048] Optionally, first identify the readable encoding format supported by the current browser (such as the Chromium Mojo IPC specification used by browsers based on the Chromium kernel), then use the original script (which may be JavaScript, CSS, or other browser-parseable scripting languages) as input and convert the original script into an encoded script through the corresponding encoding algorithm. After the encoding is completed, the encoded script can be optionally verified to ensure that no errors are introduced during the encoding process. In addition, according to actual needs, the encoded script can also be compressed to reduce the amount of transmitted data and increase transmission and loading speeds.

[0049] S206 : Send the encoded script to the target rendering process through the data sending function of the main process, so that the target rendering process receives the encoded script and performs de-encoding to obtain the original script.

[0050] Optionally, after obtaining the encoded script, it is necessary to transfer it from the main process to the target rendering process. This can be achieved through the browser's inter-process communication mechanism. Specifically, the data send function defined in the browser's main process is part of the browser's internal communication and data processing mechanism. It allows information to be exchanged between different processes, ensuring smooth data transmission between the main and rendering processes. For example, when a user performs an action on a browser page (such as clicking a button or entering text), the main process sends this action information to the corresponding target rendering process via the data send function for processing. Moreover, since the data send function is defined directly within the browser's main process, this built-in nature ensures seamless integration with other browser functions. The data transfer process is also transparent to the user, requiring no additional operations or configuration. This improves data transfer efficiency and stability while reducing user complexity. Based on this, it is possible to consider transferring the encoded script to the target rendering process via the data send function in the browser's main process. Using this function, the encapsulated data packet is sent to the target rendering process. During the transmission process, mechanisms such as flow control, error detection, and retransmission may be employed to improve transmission reliability and stability.

[0051] In the embodiment of the present application, a script injection method is provided. In response to a security monitoring request triggered for a target rendering process in a browser, an original script to be injected into the target rendering process is obtained from a main process of the browser; the original script is encoded according to a readable encoding format corresponding to the browser to obtain an encoded script corresponding to the original script; and the encoded script is sent to the target rendering process through a data sending function of the main process, so that the target rendering process receives the encoded script and decodes the encoded script to obtain the original script. When security monitoring needs to be performed on the target rendering process, the original script to be injected is first obtained from the main process of the browser, which ensures that the script injection behavior is performed under the security monitoring framework of the browser, effectively preventing unauthorized execution of malicious scripts. Then, the original script is encoded according to the readable encoding format corresponding to the browser, which can convert the original script into a format that can be efficiently understood and executed by the browser kernel, and the encoded script data can be securely transmitted between the main process and the target rendering process to ensure that the script is correctly executed in the target rendering process. Next, the encoded script is securely and efficiently transmitted to the target rendering process through the data sending function of the main process. This process fully utilizes the efficiency and stability of the internal communication mechanism of the browser, ensuring that the encoded script can be injected into the target rendering process in a timely and accurate manner without relying on specific plug-ins or user operations. The present application can realize an automatic script injection process and real-time protection without affecting the browser by defining the original script and the data sending function in the main process of the browser.

[0052] Please refer to Figure 3 , Figure 3 A flowchart of a script injection method provided in the embodiment of the present application is shown.

[0053] As Figure 3 shown, the script injection method can at least include:

[0054] S302, when a user performs a preset operation on a target webpage in a browser is monitored, a security monitoring request is triggered for a target rendering process corresponding to the target webpage; the preset operation includes at least one of a webpage opening operation, a file downloading operation, and a page sharing operation.

[0055] Optionally, Figure 4 A specific implementation flowchart of a script injection method provided in the embodiment of the present application is shown. For the JavaScript script injection process of a browser based on a Chromium kernel (for example, a Google Chrome browser), for the convenience of understanding, the technical solutions in the embodiment of the present application are described by taking the Google Chrome browser as an example. As Figure 4As shown, when the security protection module in the main process of the Google Chrome browser detects that the user performs a preset operation on the target webpage, it will automatically trigger a security monitoring request for the target rendering process corresponding to the target webpage. The preset operation here includes but is not limited to the following: webpage opening operation, file download operation, page sharing operation. Exemplarily, when the user tries to open a new webpage by clicking a link, entering a URL, or other ways, the browser will judge that the operation is a webpage opening operation, and when the webpage opening operation meets the preset security monitoring condition, for example, the webpage comes from an untrusted site or contains known malicious code features, the corresponding security monitoring request will be triggered for the target rendering process corresponding to the webpage to be loaded.

[0056] S304, in response to the security monitoring request triggered for the target rendering process in the browser, obtaining the original script to be injected into the target rendering process from the main process of the browser; encoding the original script according to the readable encoding format corresponding to the browser to obtain the encoded script corresponding to the original script; the encoding mode is serialization processing, and the decoding mode is the corresponding deserialization processing of serialization processing.

[0057] Optionally, when it is detected that the target rendering process performs certain operations, a security monitoring request for the target rendering process will be triggered in the security protection module of the browser main process, and the original script in the main process is obtained, and then the original script is encoded according to the readable encoding format corresponding to the browser to obtain the encoded script corresponding to the original script. Specifically, for the process of triggering the security monitoring request and obtaining the encoded script in step S304, please refer to the detailed description in steps S202 and S204, which will not be repeated here.

[0058] Optionally, as Figure 4The specific implementation flow chart of a script injection method provided by an embodiment of the present application is shown. When the original script (JavaScript script) is encoded according to the readable encoding format (Chromium Mojo IPC specification) corresponding to the Google Chrome browser, the encoding method can adopt serialization processing. Specifically, the Google Chrome browser adopts the Chromium Mojo IPC specification to communicate between processes within the browser. This specification defines the rules for data serialization and deserialization to ensure the correct transmission and parsing of data between different processes. Based on this, in the main process of the Google Chrome browser, the JavaScript script is serialized in accordance with the Chromium Mojo IPC specification. This serialization process converts the JavaScript script into a format that is easy for the Chromium browser to understand, and contains all the information of the original JavaScript script. The serialized data (i.e., the encoded script) is not only easy to transmit between processes, but also can prevent the tampering and injection of malicious code to a certain extent, thereby improving the security of script injection.

[0059] S306. Fill the encoded script with the parameters of the data sending function of the main process and call the data sending function. The data sending function is set to send the parameters to the target rendering process when called; the target rendering process is also used to execute the original script after obtaining the original script, and return the obtained script execution result to the main process.

[0060] Optionally, after obtaining the encoded script, it is necessary to transfer the script from the main process of the browser to the target rendering process safely and efficiently, which can be achieved through the data sending function in the main process of the browser. Specifically, a data sending function specifically for cross-process communication is defined in the main process of the browser. This function is designed to receive one or more parameters. These parameters will be encapsulated into a specific data format when the function is called, and passed to the target rendering process through the inter-process communication mechanism inside the browser. Based on this, after determining the data sending function, the encoded script is encapsulated as a parameter of the function. After the encapsulation is completed, the main process calls the data sending function and passes the encapsulated encoded script as a parameter. At this point, the inter-process communication mechanism inside the browser will take over the data transmission task to ensure that the encoded script can reach the target rendering process accurately.

[0061] It's important to note that the security of the encoded script must be ensured during inter-process transmission. Therefore, the data sending function can use encryption, signatures, or checksums to prevent tampering or leakage of the encoded script during transmission. Furthermore, to enhance communication efficiency and reliability, the encoded script can be further compressed or segmented to accommodate varying network conditions and inter-process communication limitations.

[0062] Furthermore, the target rendering process has a corresponding receiving mechanism to monitor and receive messages from the main process. Once the encoded script is received, the target rendering process will also de-encode the encoded script according to the browser's readable encoding format, restore the encoded script to the original script, and then execute the script according to the predetermined logic. The script execution results (including success or failure, execution data, error codes or exception information, etc.) generated after execution will be encapsulated by the target rendering process into a specific data structure and returned to the main process through the communication mechanism agreed with the main process.

[0063] For example, Figure 4 As shown in the flowchart of a specific implementation of a script injection method provided by an embodiment of the present application, after the main process of the Google Chrome browser serializes the original JavaScript script, the encoded script is delivered through the Chrome! put() data sending function inside the Google Chrome browser. That is, the serialized data (encoded script) is filled as the parameter of the Chrome! put() function and called within the main process of the browser. At this time, the Chrome! put() function will pass the serialized data to the target rendering process of the browser. When the target rendering process receives the serialized data, it will deserialize it to obtain the original JavaScript script, execute the JavaScript script, and then return the script execution result to the main process.

[0064] S308 , monitoring whether a script execution result is received; when the script execution result is received, analyzing risk information of the target rendering process based on the script execution result.

[0065] Optionally, after sending the encoded script to the target renderer process, the main process will initiate a monitoring mechanism to wait and check whether it has received the script execution result returned by the target renderer process. This monitoring mechanism can be built based on the existing browser inter-process communication mechanism. For example, the main process can set a callback function or event listener. When the target renderer process sends the script execution result through the agreed communication method, the function or listener will be triggered.

[0066] Optionally, once the script execution result is received by the listening mechanism, the main process immediately analyzes the risk information of the target rendering process based on the script execution result. This can include: verifying the validity of the script execution result to check whether the execution result conforms to the expected format and data type, ensuring the accuracy and reliability of the result; or extracting key risk indicators to extract key information that may indicate security risks from the script execution result, such as risk type, risk code, etc.; and according to the extracted risk indicators, combining the preset risk assessment model or rule library, the security risk currently faced by the target rendering process is evaluated, and the risk degree is determined, etc.

[0067] In the embodiments of the present application, a script injection method is provided, which can prevent potential risk attacks in time by listening to the operations made by the user on the target webpage and triggering corresponding security monitoring requests when the user performs key operations, thereby protecting the user's data and privacy security; by filling the encoded script as a parameter of the data sending function of the main process and calling the function, the data sending function can be safely and efficiently sent to the target rendering process when called, which fully utilizes the efficiency and stability of the browser internal communication mechanism, ensuring that the timeliness and accuracy of the encoded script injection into the target rendering process can be achieved without relying on specific plug-ins or user operations; by returning the script execution result to the main process after the target rendering process executes the original script, and listening to the reception of this result, when the main process receives the script execution result, the risk information of the target rendering process can be analyzed based on the result, ensuring that the security status of the target rendering process can be monitored and evaluated in real time, and potential security risks can be quickly identified, and corresponding measures can be taken to prevent and respond.

[0068] Please refer to Figure 5 , Figure 5 A flowchart of a script injection method provided by the embodiments of the present application is shown.

[0069] As Figure 5 shown, the script injection method can at least include:

[0070] S502, obtaining the debugging information file generated by the browser; obtaining the first address information corresponding to the data sending function in the main process and the second address information corresponding to the data receiving function in the main process from the debugging information file; storing the first address information and the second address information.

[0071] Optionally, in the script injection process, it is crucial to accurately control the sending and receiving of scripts, and if the address information of some key functions (such as data sending functions and data receiving functions) can be obtained and stored in advance, these functions can be directly called when needed without the need for complex lookup or parsing processes, thereby improving the accuracy and efficiency of script injection. At the same time, the browser will generate a debugging information file during the compilation process, which is used to store program debugging information, including source code file name, variable name, function name, corresponding line number, address and other key information. Based on this, the first address information corresponding to the data sending function and the second address information corresponding to the data receiving function can be obtained from the debugging information file in advance. These address information are the actual positions of the functions in the memory, and these address information are pre-stored so as to facilitate subsequent rapid determination and calling of related functions according to the stored address information in the script injection process.

[0072] Optionally, Figure 4 A specific implementation flowchart of a script injection method provided by the embodiment of the application is provided, wherein for the JavaScript script injection process of the browser based on the Chromium kernel (such as the Google Chrome browser), for the convenience of understanding, the technical solutions in the embodiment of the application are all described by taking the Google Chrome browser as an example. As shown in Figure 4 The debugging information file generated by the Google Chrome browser is a program database file (PDB), the data sending function is the Chrome!put() function, and the data receiving function is the Chrome!IPC::ˋanonymous namespace'::ChannelAssociatedGroupController::Accept() function, so the address information corresponding to the two functions is first obtained from the PDB debugging information file and pre-stored.

[0073] S504, in response to the security monitoring request triggered for the target rendering process in the browser, obtaining the original script of the target rendering process to be injected from the main process of the browser; encoding the original script according to the corresponding readable encoding format of the browser to obtain the encoded script corresponding to the original script.

[0074] Optionally, for step S504, please refer to the detailed description in steps S202 and S204, which will not be repeated here.

[0075] S506, send the encoded script to the target rendering process through a data sending function of the main process; the target rendering process is further configured to execute the original script after obtaining the original script, and fill the script execution result as a parameter into a data receiving function of the main process.

[0076] Optionally, after obtaining the encoded script, the script needs to be transmitted from the main process to the target rendering process, which can be realized through the inter-process communication mechanism of the browser. Specifically, for the process of sending the encoded script to the target rendering process in step S506, refer to the detailed description in step S206, which will not be repeated here.

[0077] Optionally, once the encoded script is received, the target rendering process will also perform a decoding operation on the encoded script according to the corresponding readable encoding format of the browser, restore the encoded script to the original script, and then execute the script according to the predetermined logic. The script execution result generated after execution will be encapsulated into a specific data structure by the target rendering process, and returned to the main process through the communication mechanism agreed with the main process, which can be realized through a data sending function in the main process of the browser. Specifically, the main process of the browser also defines a data receiving function specially used for cross-process communication, which is designed to receive one or more parameters returned by the target rendering process. When the target rendering process ends the execution of the original script, the corresponding script execution result is obtained, and the execution result is encapsulated into a parameter format. The script execution result is directly filled into the data receiving function in the main process as a parameter, so as to realize the reception of the script execution result returned by the target rendering process in the main process.

[0078] Exemplarily, as shown in the specific implementation flowchart of the script injection method provided by the embodiment of the application, Figure 4 the data receiving function in the main process of the Google Chrome browser is a Chrome! IPC::'anonymous namespace'::ChannelAssociatedGroupController::Accept() function, and after the target rendering process obtains the script execution result, the script execution result is filled into the function as a parameter, so as to transmit the script execution result to the main process of the browser.

[0079] S508, listen to whether the data receiving function receives a parameter; when the data receiving function receives a parameter, perform parameter analysis on the data receiving function to obtain the script execution result.

[0080] Optionally, after sending the encoded script to the target rendering process, the main process starts a listening mechanism to wait for and check whether the script execution result returned by the target rendering process is received. Specifically, when the address information of the data receiving function is determined according to the browser's debugging information file, the Inline Hook technology can be used to listen to the data receiving function, and the script execution is determined by whether the data receiving function receives parameters. Once the data receiving function receives parameters, it is parsed to extract the script execution result.

[0081] S510, when receiving the script execution result, judging the risk type and risk degree of the target rendering process according to the script execution result; based on the risk type and risk degree, making corresponding security protection behaviors according to the preset processing logic.

[0082] Optionally, after the main process receives the script execution result of the target rendering process, a preset risk analysis algorithm or model can be used to determine the risk type and risk degree of the target rendering process. The risk type may include malicious code execution, data leakage, resource abuse, etc.; the risk degree is evaluated according to the severity of the execution result, the influence range, the repair difficulty, etc. After the risk analysis is completed, the browser will execute the corresponding security protection behavior in the preset processing logic according to the determined risk type and risk degree. For example, if unauthorized sensitive data access or information leakage risk behavior is detected, the database or application involved in the leakage may be automatically isolated, and the network connection related to the leaked data is cut off to prevent the data leakage range from further expanding. At the same time, the relevant information of the leakage event is recorded in detail, including the leakage time, the type of leaked data, the leakage source and the leakage way, etc., for subsequent analysis and tracing; if high-risk behavior of malicious code execution is detected, the target rendering process may be immediately isolated and the administrator or user is notified.

[0083] In the embodiment of the present application, a script injection method is provided. The address information corresponding to the data sending function and the data receiving function in the main process of the browser is obtained and stored in advance from the debugging information file of the browser, so that the address information stored can be directly used to locate and operate the data sending function and the data receiving function in the subsequent script injection process, without the need for tedious debugging and searching again, thereby improving the script injection efficiency while ensuring the accuracy of operation; when the target rendering process executes the original script to obtain a script execution result, the execution result is filled as a parameter into the data receiving function of the main process, so that the main process can obtain the script execution result in real time by listening to and analyzing the parameter of the data receiving function, thereby facilitating the subsequent corresponding security protection behavior of the target rendering process according to the script execution result; the risk type and risk degree of the target rendering process are accurately analyzed based on the script execution result, so that the browser can make more accurate and targeted security protection behavior, further improving the accuracy of browser security protection.

[0084] Please refer to Figure 6 , Figure 6 The structure block diagram of a script injection device provided in the embodiment of the present application is shown.

[0085] As shown in Figure 6 , the script injection device 600 comprises:

[0086] The original script obtaining module 610 is configured to obtain an original script to be injected into the target rendering process from the main process of the browser in response to a security monitoring request triggered for the target rendering process in the browser.

[0087] The encoded script obtaining module 620 is configured to encode the original script according to a readable encoding format corresponding to the browser, to obtain an encoded script corresponding to the original script.

[0088] The script sending module 630 is configured to send the encoded script to the target rendering process through the data sending function of the main process, so that the target rendering process receives the encoded script and performs reverse encoding to obtain the original script.

[0089] Optionally, the script sending module 630 is further configured to fill the encoded script as a parameter of the data sending function of the main process and call the data sending function, and the data sending function is set to send the parameter to the target rendering process when called.

[0090] Optionally, the target rendering process is further configured to execute the obtained original script and return the obtained script execution result to the main process; the script injection apparatus 600 further comprises an execution result monitoring module configured to monitor whether the script execution result is received after the script sending module 630 sends the encoded script to the target rendering process through the data sending function of the main process; and analyze risk information of the target rendering process based on the script execution result when the script execution result is received.

[0091] Optionally, the target rendering process is further configured to fill the script execution result as a parameter to the data receiving function of the main process when returning the obtained script execution result to the main process; the execution result monitoring module is further configured to monitor whether the data receiving function receives the parameter; and perform parameter analysis on the data receiving function to obtain the script execution result when the data receiving function receives the parameter.

[0092] Optionally, the execution result monitoring module is further configured to determine a risk type and a risk degree of the target rendering process according to the script execution result; and the script injection apparatus 600 further comprises a risk processing module configured to perform corresponding security protection behavior according to a preset processing logic based on the risk type and the risk degree.

[0093] Optionally, the script injection apparatus 600 further comprises a monitoring request triggering module configured to trigger a security monitoring request for a target rendering process in the browser when a preset operation of a user on a target webpage in the browser is monitored before the original script acquisition module 610 acquires the original script to be injected into the target rendering process in response to the security monitoring request triggered for the target rendering process in the browser; and the preset operation comprises at least one of a webpage opening operation, a file downloading operation, and a page sharing operation.

[0094] Optionally, the encoding manner is serialization processing, and the decoding manner is reverse serialization processing corresponding to the serialization processing.

[0095] Optionally, the script injection apparatus 600 further comprises a function address storage module configured to acquire a debugging information file generated by the browser; acquire first address information corresponding to a data sending function in the main process and second address information corresponding to a data receiving function in the main process from the debugging information file; and store the first address information and the second address information.

[0096] In the embodiment of the present application, a script injection device is provided, wherein an original script acquisition module is configured to acquire an original script to be injected into a target rendering process of a browser in response to a security monitoring request triggered for the target rendering process from a main process of the browser; an encoded script acquisition module is configured to encode the original script according to a readable encoding format corresponding to the browser to obtain an encoded script corresponding to the original script; and a script sending module is configured to send the encoded script to the target rendering process through a data sending function of the main process, so that the target rendering process receives the encoded script and decodes the encoded script to obtain the original script. When security monitoring needs to be performed on the target rendering process, the original script acquisition module first acquires the original script to be injected from the main process of the browser, which ensures that the script injection behavior is performed under the security monitoring framework of the browser, effectively preventing unauthorized execution of malicious scripts. Then, the encoded script acquisition module encodes the original script according to the readable encoding format corresponding to the browser, which can convert the original script into a format that can be efficiently understood and executed by the browser kernel, and the encoded script data can be securely transmitted between the main process and the target rendering process to ensure that the script is correctly executed in the target rendering process. Next, the script sending module securely and efficiently transmits the encoded script to the target rendering process through the data sending function of the main process, which fully utilizes the efficiency and stability of the internal communication mechanism of the browser, ensuring that the encoded script can be injected into the target rendering process in a timely and accurate manner without relying on specific plug-ins or user operations. The present application can realize an automatic script injection process and real-time protection without affecting the browser by defining the original script and the data sending function in the main process of the browser.

[0097] The embodiment of the present application further provides a computer storage medium, which can store a plurality of instructions, and the instructions are suitable for being loaded and executed by a processor to perform the steps of the method in any one of the above embodiments.

[0098] Please refer to Figure 7 , Figure 7 A structure schematic diagram of a terminal is provided in the embodiment of the present application. As shown in Figure 7 , the terminal 700 can include at least one terminal processor 701, at least one network interface 704, a user interface 703, a memory 705, and at least one communication bus 702.

[0099] The communication bus 702 is configured to realize the connection and communication between the components.

[0100] The user interface 703 can include a display screen (Display) and a camera (Camera), and the optional user interface 703 can further include a standard wired interface and a wireless interface.

[0101] The network interface 704 can optionally include a standard wired interface, a wireless interface (e.g., a WI-FI interface).

[0102] The terminal processor 701 can include one or more processing cores. The terminal processor 701 connects various parts within the terminal 700 via various interfaces and lines, and performs various functions of the terminal 700 and processes data by running or executing instructions, programs, code sets, or instruction sets stored in the memory 705, and calling data stored in the memory 705. The terminal processor 701 can be implemented in at least one of a hardware form of a digital signal processing (DSP), a field-programmable gate array (FPGA), and a programmable logic array (PLA). The terminal processor 701 can be integrated with a combination of one or more of a central processing unit (CPU), a graphics processing unit (GPU), and a modem. The CPU is mainly responsible for processing an operating system, a user interface, and an application program, etc.; the GPU is responsible for rendering and drawing content to be displayed on a display screen; and the modem is responsible for processing wireless communication. It can be understood that the above-mentioned modem can also not be integrated into the terminal processor 701, but can be implemented by a separate chip.

[0103] The memory 705 can include a random access memory (RAM) and a read-only memory (ROM). The memory 705 can include a non-transitory computer-readable storage medium. The memory 705 can be used to store instructions, programs, codes, code sets, or instruction sets. The memory 705 can include a program storage area and a data storage area. The program storage area can store instructions for implementing an operating system, instructions for at least one function (such as a touch function, a sound playing function, an image playing function, etc.), instructions for implementing the above-mentioned various method embodiments, etc.; the data storage area can store data involved in the above-mentioned various method embodiments, etc. The memory 705 can optionally be at least one storage device located away from the terminal processor 701. As shown in the figure, the memory 705 as a computer storage medium can include an operating system, a network communication module, a user interface module, and a script injection program. Figure 7 As shown in the figure, the memory 705 as a computer storage medium can include an operating system, a network communication module, a user interface module, and a script injection program.

[0104] In Figure 7 In the terminal 700 shown, the user interface 703 is mainly used to provide an interface for the user to input, and obtain data input by the user; and the terminal processor 701 can be used to call a script injection program stored in the memory 705, and specifically perform the following operations:

[0105] In response to a security monitoring request triggered for a target rendering process in a browser, obtain an original script to be injected into the target rendering process from a main process of the browser;

[0106] Encode the original script in a readable encoding format corresponding to the browser to obtain an encoded script corresponding to the original script;

[0107] Send the encoded script to the target rendering process through a data sending function of the main process, so that the target rendering process receives the encoded script and decodes it to obtain the original script.

[0108] In some embodiments, when the terminal processor 701 performs the step of sending the encoded script to the target rendering process through the data sending function of the main process, it specifically performs the following steps: fills the encoded script as a parameter of the data sending function of the main process and calls the data sending function, and the data sending function is set to send the parameter to the target rendering process when called.

[0109] In some embodiments, the target rendering process is also used to execute the original script after obtaining the original script, and return the obtained script execution result to the main process; after the terminal processor 701 performs the step of sending the encoded script to the target rendering process through the data sending function of the main process, it specifically performs the following steps: listens whether the script execution result is received; when the script execution result is received, analyzes the risk information of the target rendering process based on the script execution result.

[0110] In some embodiments, the target rendering process is also used to return the script execution result to the main process when the script execution result is obtained, and fill the script execution result as a parameter to a data receiving function of the main process; when the terminal processor 701 performs the step of listening whether the script execution result is received, it specifically performs the following steps: listens whether the data receiving function receives the parameter; when the data receiving function receives the parameter, performs parameter analysis on the data receiving function to obtain the script execution result.

[0111] In some embodiments, when the terminal processor 701 performs the step of analyzing the risk information of the target rendering process based on the script execution result, it specifically performs the following steps: determines the risk type and risk degree of the target rendering process according to the script execution result; and the terminal processor 701 specifically performs the following steps: based on the risk type and risk degree, makes corresponding security protection behaviors according to a preset processing logic.

[0112] In some embodiments, the terminal processor 701 further specifically performs the following steps before executing the step of obtaining the original script to be injected into the target rendering process in response to the security monitoring request triggered for the target rendering process in the browser: triggering the security monitoring request for the target rendering process corresponding to the target webpage in the browser when it is monitored that the user performs a preset operation on the target webpage in the browser; the preset operation includes at least one of a webpage opening operation, a file downloading operation, and a page sharing operation.

[0113] In some embodiments, the encoding manner is serialization processing, and the decoding manner is deserialization processing corresponding to the serialization processing.

[0114] In some embodiments, the terminal processor 701 further specifically performs the following steps: obtaining a debugging information file generated by the browser; obtaining, from the debugging information file, first address information corresponding to a data sending function in the main process and second address information corresponding to a data receiving function in the main process; and storing the first address information and the second address information.

[0115] In several embodiments provided in the present application, it should be understood that the disclosed apparatus and method can be implemented by other manners. For example, the apparatus embodiment described above is only illustrative, for example, the division of the module is only a logical function division, and actual implementation can have another division manner, for example, a plurality of modules or components can be combined or integrated into another system, or some features can be ignored or not executed. In addition, the coupling or direct coupling or communication connection between the displayed or discussed modules can be indirect coupling or communication connection through some interfaces, apparatuses or modules, which can be electrical, mechanical or other forms.

[0116] The module described as a separate component can be or can not be physically separated, and the component displayed as a module can be or can not be a physical module, that is, it can be located in one place, or it can be distributed to a plurality of network modules. According to actual needs, part or all of the modules can be selected to achieve the purpose of the embodiment scheme.

[0117] In the above embodiments, all or part of the embodiments can be implemented by software, hardware, firmware or any combination thereof. When implemented by software, all or part of the embodiments can be implemented in the form of a computer program product. The above computer program product includes one or more computer instructions. When the above computer program instructions are loaded and executed on a computer, all or part of the processes or functions described above according to the embodiments of the present disclosure are generated. The computer can be a general-purpose computer, a special-purpose computer, a computer network or other programmable device. The computer instructions can be stored in a computer-readable storage medium or transmitted by the computer-readable storage medium. The computer instructions can be transmitted from one website, computer, server or data center to another website, computer, server or data center by wire (such as coaxial cable, optical fiber, digital subscriber line (DSL)) or wireless (such as infrared, wireless, microwave, etc.). The computer-readable storage medium can be any available medium that can be accessed by a computer or a data storage device such as a server, data center, etc. that includes one or more available media sets. The available media can be a magnetic medium (for example, a floppy disk, a hard disk, a magnetic tape), an optical medium (for example, a digital versatile disc (DVD)), or a semiconductor medium (for example, a solid state disk (SSD)) and the like.

[0118] It should be noted that for the foregoing method embodiments, in order to facilitate description, they are all described as a combination of a series of actions, but those skilled in the art should know that the present application is not limited by the order of the described actions, because according to the present application, certain steps can be performed in other orders or simultaneously. Secondly, those skilled in the art should know that the embodiments described in the specification are all preferred embodiments, and the actions and modules involved are not necessarily essential to the present application.

[0119] In the above embodiments, the description of each embodiment has its own emphasis, and the parts not described in detail in a certain embodiment can be referred to the related description of other embodiments.

[0120] The above is the description of the script injection method, device and terminal provided by the present application. For those skilled in the art, according to the idea of the embodiments of the present application, there will be changes in specific implementation and application range. In summary, the content of the specification should not be understood as a limitation of the present application.

Claims

1. A script injection method, characterized in that: The method comprises: In response to a security monitoring request triggered for a target rendering process in a browser, obtaining an original script to be injected into the target rendering process from a main process of the browser; Encode the original script according to the readable encoding format corresponding to the browser to obtain an encoded script corresponding to the original script; The encoded script is sent to the target rendering process through the data sending function of the main process, so that the target rendering process receives the encoded script and performs de-encoding to obtain the original script.

2. The method according to claim 1, characterized in that The sending of the encoding script to the target rendering process through the data sending function of the main process includes: The encoded script is filled as a parameter of a data sending function of the main process and the data sending function is called. The data sending function is configured to send the parameters to the target rendering process when called.

3. The method according to claim 1, characterized in that The target rendering process is further configured to execute the original script after obtaining the original script, and return the obtained script execution result to the main process; After sending the encoded script to the target rendering process through the data sending function of the main process, the method further includes: Monitor whether the script execution result is received; When the script execution result is received, risk information of the target rendering process is analyzed based on the script execution result.

4. The method according to claim 3, characterized in that The target rendering process is further configured to, when returning the obtained script execution result to the main process, fill the script execution result as a parameter into the data receiving function of the main process; The monitoring of whether the script execution result is received includes: Monitor whether the data receiving function receives parameters; When the data receiving function receives the parameters, the parameters of the data receiving function are parsed to obtain the script execution result.

5. The method according to claim 3, characterized in that Analyzing the risk information of the target rendering process based on the script execution result includes: Determining the risk type and risk level of the target rendering process based on the script execution result; The method further comprises: Based on the risk type and risk level, corresponding safety protection actions are taken according to preset processing logic.

6. The method according to claim 1, characterized in that Before obtaining the original script to be injected into the target rendering process in response to the security monitoring request triggered for the target rendering process in the browser, the method further includes: When it is detected that the user performs a preset operation on the target webpage in the browser, a security monitoring request is triggered to the target rendering process corresponding to the target webpage; The preset operation includes at least one of a web page opening operation, a file downloading operation, and a page sharing operation.

7. The method according to claim 1, characterized in that The encoding method is serialization processing, and the de-encoding method is de-serialization processing corresponding to the serialization processing.

8. The method according to claim 1, characterized in that The method further comprises: Obtaining a debugging information file generated by the browser; Acquire first address information corresponding to a data sending function in the main process and second address information corresponding to a data receiving function in the main process from the debugging information file; The first address information and the second address information are stored.

9. A script injection device, characterized in that: The device comprises: An original script acquisition module, configured to, in response to a security monitoring request triggered for a target rendering process in a browser, acquire an original script to be injected into the target rendering process from the main process of the browser; An encoding script acquisition module is used to encode the original script according to the readable encoding format corresponding to the browser to obtain an encoding script corresponding to the original script; The script sending module is used to send the encoded script to the target rendering process through the data sending function of the main process, so that the target rendering process receives the encoded script and performs de-encoding to obtain the original script.

10. A terminal, characterized in that: include: A processor and a memory; wherein the memory stores a computer program, and the computer program is suitable for being loaded by the processor and executing the method steps according to any one of claims 1 to 8.

Images