A secure isolation and integration method and device for Web application plug-ins

Abstract

The present invention discloses a method and device for secure isolation and integration of Web application plug-ins. It belongs to the technical field of Web operating systems. In a Web operating system, a third-party plug-in source code is input; the third-party plug-in source code is compiled into a wasm file through the wasm compilation module of the sandbox module, wherein the sandbox module is used to provide an isolated environment; the wasm file is converted into the C source code and header file corresponding to the third-party plug-in source code through the wasm2c conversion module of the sandbox module; the third-party plug-in source code is sandboxed and reconstructed; the plug-in library source code is written, and the C source code and header file corresponding to the third-party plug-in source code are called; the plug-in library source code is compiled into a plug-in library and run. The function of securely accessing the third-party plug-in source code in the form of a plug-in in a Web application is realized, which solves the problem that existing Web applications cannot securely use third-party plug-ins developed in system languages ​​such as C / C++, realizes isolated control of memory access to third-party plug-ins, and avoids security risks such as data leakage and terminal device loss of control caused by third-party plug-in vulnerabilities.

Description

Technical Field

[0001] The present invention relates to the technical field of Web operating systems, and in particular to a method and device for securely isolating and integrating Web application plug-ins. Background Art

[0002] In scenarios where access to underlying operating system functions is required, native code has more efficient memory management and operating efficiency. Third-party plug-ins such as audio and video codecs and font rendering are mostly developed using the C / C++ system language, and web applications cannot directly access these third-party plug-ins.

[0003] In the related art, methods such as NPAPI and PPAPI have been introduced successively, but the following improvements are still needed.

[0004] NPAPI: External programs act as plug-ins and work together with the browser to display web pages. Third-party plug-ins can be called through dynamic link libraries (DLLs). However, plug-ins have excessive permissions, posing certain security risks.

[0005] PPAPI: Runs in the sandbox environment of the Chromium browser and is implemented based on NPAPI. Its capabilities are provided by the browser, preventing plug-ins from accessing underlying system functions. This improves security by restricting plug-in permissions. Plug-ins cannot call system APIs, only the interfaces provided by PPAPI. When calling third-party plug-ins, ensure that they are compatible with PPAPI and can run properly in the Chromium browser. Because PPAPI places all external plug-ins in a sandbox, it results in high CPU and memory usage and is only supported by older versions of the Chrome browser. Compared to NPAPI, PPAPI has high development costs and runs slowly, making it unsuitable for Linux-based web operating systems.

[0006] WebAssembly, also known as Wasm, compiles code from high-performance programming languages ​​like C, C++, and Rust into low-level WebAssembly bytecode. This binary format loads and parses quickly, enabling instant startup and execution, making it easy to run projects in the browser at near-native speeds, effectively minimizing the impact of software failures. WebAssembly isolates Wasm modules from the rest of the browser through a sandbox environment, ensuring that their execution does not harm the browser or user device, preventing malicious code from attacking and abusing the system. WebAssembly's linear memory model provides secure memory access mechanisms that prevent common memory safety issues such as buffer overflows, effectively reducing the occurrence of software failures. However, WebAssembly module development is costly, requiring the entire project to be migrated to the WebAssembly ecosystem. For many projects that are not Wasm-compatible, the cost of self-migration is extremely high. Summary of the Invention

[0007] In view of the above problems in the prior art, the present invention provides a method and apparatus for securely isolating and integrating Web application plug-ins, so as to solve the problem that the Web application cannot directly access third-party plug-ins.

[0008] In one aspect, a method for securely isolating and integrating a Web application plug-in is provided, which is applied to a Web operating system. The method includes:

[0009] In the Web operating system, input the third-party plug-in source code;

[0010] Compile the third-party plug-in source code into a wasm file through a wasm compilation module of a sandbox module, wherein the sandbox module is used to provide an isolated environment;

[0011] The wasm file is converted by the wasm2c conversion module of the sandbox module to obtain the C source code and header file corresponding to the third-party plug-in source code;

[0012] Sandboxing and reconstructing the third-party plug-in source code;

[0013] Write the plug-in library source code and call the C source code and header files corresponding to the third-party plug-in source code;

[0014] Compile the plug-in library source code into a plug-in library and run it.

[0015] Optionally, the sandboxing and reconstructing the third-party plug-in source code includes:

[0016] Compile the target header file of the third-party plug-in source code to adapt to the yhsbx sandbox, wherein the target header file includes a structure definition header file, a sandbox class definition header file, and a sandbox entry header file;

[0017] In the process of writing the structure definition header file, the structure definition of the Struct structure of the third-party plug-in source code is performed using macros according to rules;

[0018] In the process of writing the sandbox class definition header file, call the function that defines the yhsbx sandbox base class for the third-party plug-in and pass in the class name parameter;

[0019] In the process of writing the sandbox entry header file, the structure definition header file, the sandbox class definition header file and the sandboxed third-party plug-in source code entry header file are introduced. The sandboxed third-party plug-in source code entry header file refers to the sandbox header file and the header file corresponding to the third-party plug-in source code converted by the wasm2c conversion module of the sandbox module.

[0020] Optionally, writing the plug-in library source code and calling the C source code and header file corresponding to the third-party plug-in source code include:

[0021] Import the sandbox entry header file and the sandbox class definition header file;

[0022] When writing plugin library source code, create a sandbox during plugin instance initialization by encapsulating the module;

[0023] At the code location where the third-party plug-in source code is needed, use the yhsbx_allocate() memory management interface to apply for memory in the shared memory area of ​​the sandbox;

[0024] Using a secure function call interface to call a function in the third-party plug-in source code;

[0025] In response to the memory not being needed, the memory is released through the yhsbx_free() memory management interface, and the sandbox is destroyed during the plug-in instance unloading phase.

[0026] Optionally, compiling the plug-in library source code into a plug-in library and running the plug-in library includes:

[0027] Compile the plugin library source code into a plugin library using CMake;

[0028] The application layer of the web application runs the plug-in library through HTML elements.

[0029] Optionally, the compilation refers to the process of building all source codes into a dynamic library, where all source codes include the C source code and header files corresponding to the third-party plug-in source code, the sandbox entry header file, and the plug-in library source code;

[0030] The operation refers to the process of loading the plug-in library by the Web application, which includes loading the plug-in library through the HTML element, loading and initializing the plug-in library in the JavaScript code, and completing the access to the third-party plug-in with the help of the sandbox code contained in the plug-in library.

[0031] Optionally, at the code location where the third-party plug-in source code is needed, using the yhsbx_allocate() memory management interface to allocate memory in the shared memory area of ​​the sandbox, including:

[0032] Default values ​​given by the yhsbx sandbox;

[0033] After calling the memory management interface yhsbx_allocate(), an area is allocated in the shared memory area of ​​the sandbox according to the default value;

[0034] When data is used, the yhsbx sandbox automatically calculates the memory size required for the data and dynamically adjusts the allocated area size to complete the memory application.

[0035] In another aspect, a secure isolation and integration device for a Web application plug-in is provided, which is applied to a Web operating system and includes:

[0036] A code input module, used to input third-party plug-in source code into the Web operating system;

[0037] A compilation module, configured to compile the third-party plug-in source code into a wasm file through a wasm compilation module of a sandbox module, wherein the sandbox module is configured to provide an isolated environment;

[0038] A conversion module, configured to convert the wasm file through the wasm2c conversion module of the sandbox module to obtain the C source code and header file corresponding to the third-party plug-in source code;

[0039] A code reconstruction module, used to perform sandbox reconstruction on the source code of the third-party plug-in;

[0040] A plug-in writing module is used to write the plug-in library source code and call the C source code and header files corresponding to the third-party plug-in source code;

[0041] The plug-in running module is used to compile the plug-in library source code into a plug-in library and run it.

[0042] On the other hand, a computer-readable storage medium is provided, in which a computer program is stored. The computer program is loaded and executed by a processor to implement the secure isolation and integration method of the Web application plug-in as described above.

[0043] The present invention has at least the following beneficial effects.

[0044] In this method, in the Web operating system, the third-party plug-in source code is input; the third-party plug-in source code is compiled into a wasm file through the wasm compilation module of the sandbox module, wherein the sandbox module is used to provide an isolated environment; the wasm file is converted into the C source code and header file corresponding to the third-party plug-in source code through the wasm2c conversion module of the sandbox module; the third-party plug-in source code is sandboxed and reconstructed; the plug-in library source code is written, and the C source code and header file corresponding to the third-party plug-in source code are called; the plug-in library source code is compiled into a plug-in library and run. The function of securely accessing the third-party plug-in source code in the form of a plug-in is realized in Web applications, solving the problem that existing Web applications cannot securely use third-party plug-ins developed in system languages ​​such as C / C++, and realizing isolated control of memory access to third-party plug-ins, avoiding security risks such as data leakage and terminal device loss of control caused by third-party plug-in vulnerabilities. BRIEF DESCRIPTION OF THE DRAWINGS

[0045] Figure 1 A flowchart of a secure isolation and integration method for a Web application plug-in is provided;

[0046] Figure 2 A schematic diagram of an operating system for a secure isolation and integration method of a Web application plug-in is provided;

[0047] Figure 3 Provides a data flow diagram between third-party plug-in source code and plug-in library. DETAILED DESCRIPTION

[0048] In order to make the objectives, technical solutions and advantages of this application clearer, the implementation methods of this application will be further described in detail below with reference to the accompanying drawings.

[0049] In this document, "plurality" refers to two or more. "And / or" describes a relationship between associated objects, indicating that three possible relationships exist. For example, "A and / or B" can mean: A exists alone, A and B exist simultaneously, or B exists alone. The character " / " generally indicates an "or" relationship between the associated objects.

[0050] It should be noted that the implementation environment of each embodiment of the present application includes a computer device and a background server, and the execution end of the security isolation and integration method of the unrestricted Web application plug-in can be a computer device or a background server corresponding to the computer device.

[0051] Taking a computer device as an example, the computer device, through the assistance of a storage medium or a cloud server, has the ability to generate the C source code and header files corresponding to the third-party plug-in source code. Under instructions or autonomous execution conditions, the computer device sandboxes and reconstructs the third-party plug-in source code. It then calls the C source code and header files corresponding to the third-party plug-in source code to write the plug-in library source code, and compiles and runs the plug-in library source code within the computer device. The computer device can be a terminal device with computing capabilities, such as a portable notebook, tablet computer, or mobile phone, without limitation.

[0052] Taking the background server as an example, the background server can be a single server, a server cluster consisting of multiple servers, a virtual cloud storage, or a cloud computing center. In any of the server clusters, virtual cloud storage, or cloud computing centers, additional features can be added based on the content of the embodiments of the present application, and the embodiments of the present application are not limited thereto. The following embodiments are illustrated using computer devices as an example.

[0053] Example 1

[0054] like Figure 1 As shown, the present invention provides a method for secure isolation and integration of Web application plug-ins, which is applied to a Web operating system and includes the following contents.

[0055] Step 101: In the Web operating system, input the third-party plug-in source code.

[0056] It should be noted that all "xx" in the text represent the names of third-party plug-in source codes.

[0057] Step 102: compile the third-party plug-in source code into a wasm file through the wasm compilation module of the sandbox module, wherein the sandbox module is used to provide an isolated environment.

[0058] In an embodiment of the present application, the yhsbx sandbox executor in the computer device compiles the third-party plug-in source code into a wasm file through the wasm compilation module of the sandbox module, and the compiled wasm file is represented as a yhsbx_xx.wasm file.

[0059] Among them, the yhsbx sandbox executor refers to the sandbox in the computer device operating system of this method, which mainly provides an isolated environment through the sandbox module to prevent users from modifying the application software and affecting the security of the operating system.

[0060] Step 103: Convert the wasm file through the wasm2c conversion module of the sandbox module to obtain the C source code and header file corresponding to the third-party plug-in source code.

[0061] Correspondingly, the wasm2c conversion module of the sandbox module is used to complete the conversion of the yhsbx_xx.wasm file to the yhsbx_xx.wasm.h and yhsbx_xx.wasm.c files. That is, the yhsbx_xx.wasm.h file is the converted header file, and the yhsbx_xx.wasm.c file is the converted C source code.

[0062] Step 104: sandbox the third-party plug-in source code.

[0063] In a possible implementation, step 104 includes the following sub-steps.

[0064] S41, write the third-party plug-in source code to adapt to the target header file of the yhsbx sandbox, wherein the target header file includes a structure definition header file, a sandbox class definition header file and a sandbox entry header file.

[0065] Among them, the third-party plug-in source code libxx is sandboxed. First, three target header files are written for libxx to adapt to the yhsbx sandbox, namely the structure definition header file xx_yhsbx_structs.h, the sandbox class definition header file xx_yhsbx_types.h and the sandbox entry header file xx_yhsbx.h.

[0066] S42, in the process of writing the structure definition header file, use macros according to the rules to define the Struct structure of the third-party plug-in source code.

[0067] First, we write the structure definition header file xx_yhsbx_structs.h, which imports libxx / xx.h. We use macros to define all libxx structures according to the rules, making it easier for the type tagging system to tag libxx generic types. Third-party plugin source code may consist of more than one file, including multiple header files and C files. The " / " represents xx.h in the libxx folder, which is the access point for the entire source code.

[0068] The rule is to use #define yhsbx_fields_reflection_xx_class_structname(f,g,...)\f(memberType member,FIELD_NORMAL,##__VA_ARGS__)g() to map all members of the structure to the area accessible to the yhsbx sandbox, and use #define yhsbx_fields_reflection_xx_allClasses(f,...)\f(structname,xx,##__VAL_ARGS__) to map the entire structure to the area accessible to the yhsbx sandbox, where "xx" represents the name of the third-party plug-in source code and "structname" represents the name of the structure.

[0069] In addition, a program example is provided to illustrate the above content.

[0070]

[0071]

[0072] The structure definition header file contains content related to type conversion of all structure definitions in the third-party plug-in source code using macros. Type conversion refers to defining a member-safe access interface for the original structure in the third-party plug-in source code that can pass through the sandbox boundary.

[0073] S43, in the process of writing the sandbox class definition header file, calling the function of defining the yhsbx sandbox base class for the third-party plug-in, and passing in the class name parameter.

[0074] Next, we write the sandbox class definition header file xx_yhsbx_types.h. This file defines the base class of the yhsbx sandbox for libxx. We import yhsbx_types.h and call the function YHSBX_BASE_TYPES_FOR(libname) to define the base class of the yhsbx sandbox for third-party plugins, passing in the class name parameter. The libname parameter is required because xx is required and the yhsbx sandbox is implemented based on templates. This function binds the yhsbx-related classes to libxx. When used, the relevant functions provided by the yhsbx sandbox are indexed based on the class name of the third-party plugin source code, and the method of the plugin to be called is found in the source file generated by the wasm2c conversion module.

[0075] Among them, the sandbox class definition header file contains the yhsbx sandbox basic class related content defined for the third-party plug-in source code and functional interfaces such as sandbox creation and destruction.

[0076] S44, in the process of writing the sandbox entry header file, introduce the structure definition header file, the sandbox class definition header file and the sandboxed third-party plug-in source code entry header file. The sandboxed third-party plug-in source code entry header file refers to the sandbox header file and the header file corresponding to the third-party plug-in source code converted by the wasm2c conversion module of the sandbox module.

[0077] The last thing to be written is the sandbox entry header file xx_yhsbx.h, which introduces the structure definition header file xx_yhsbx_structs.h, the sandbox class definition header file xx_yhsbx_types.h and the sandboxed third-party plug-in source code entry header file yhsbx_xx.wasm.h. The sandboxed third-party plug-in source code entry header file refers to the sandbox header file yhsbx.h and the header file yhsbx_xx.wasm.h corresponding to the third-party plug-in source code converted by the wasm2c conversion module of the sandbox module.

[0078] Step 105: Write the plug-in library source code and call the C source code and header file corresponding to the third-party plug-in source code.

[0079] In a possible implementation, step 105 includes the following sub-steps.

[0080] S51, introduce the sandbox entry header file and sandbox class definition header file.

[0081] Import the sandbox entry header file xx_yhsbx.h into the plugin header file, and import the sandbox class definition header file xx_yhsbx_types.h into the plugin source file. The following steps are all carried out by calling the API provided by the encapsulation module.

[0082] S52, when writing the plug-in library source code, a sandbox is created during the plug-in instance initialization phase by encapsulating the module.

[0083] During the plug-in instance initialization phase, an instance of the sandboxed third-party plug-in source code libxx is created as xxsbx through the new yhsbx_xx() method, and the yhsbx_create() method on the xxsbx object is called to create a sandbox.

[0084] S53, at the code location where the third-party plug-in source code is needed, use the yhsbx_allocate() memory management interface to apply for memory in the sandbox's shared memory area.

[0085] In a possible implementation, step S53 includes the following content.

[0086] Content 1: Give default values ​​through yhsbx sandbox.

[0087] Content 2: After calling the memory management interface yhsbx_allocate(), an area is allocated in the sandbox's shared memory area according to the default value.

[0088] Content 3: When data is used, the yhsbx sandbox automatically calculates the memory size required for the data and dynamically adjusts the allocated area size to complete the memory application.

[0089] At the code location where the third-party plug-in source code libxx is needed, for complex data types such as structures and arrays, first use the memory management interface yhsbx_allocate() on the xxsbx object to allocate memory in the sandbox memory shared area.

[0090] S54, using a secure function call interface to call a function in the third-party plug-in source code.

[0091] Then use the secure function call interface yhsbx_call_fun(func_name, tagged_value) to call the function of the third-party plug-in source code.

[0092] It should be noted that the memory management interface yhsbx_allocate() here does not require any parameters. The yhsbx sandbox will initially assign a default value. After calling the memory management interface yhsbx_allocate(), an area will be allocated in the shared memory area according to the default value. When the data is used, the yhsbx sandbox will automatically calculate the memory size required for the data and dynamically adjust the size of the allocated area. The func_name in the safe function call interface is the function name of the third-party plug-in you want to call, and tagged_value is the tagged pointer returned by calling the memory management interface. If you want the third-party plug-in to perform some operations in the sandbox while it is running, you can use the yhsbx_callback(func) interface to achieve this. func is the callback function exposed by the plug-in to the sandbox.

[0093] S55 , in response to the memory not being needed, the memory is released through the yhsbx_free() memory management interface, and the sandbox is destroyed during the plug-in instance uninstallation phase.

[0094] When the memory is no longer needed, the memory management interface yhsbx_free() on the xxsbx object is used to release the requested sandbox memory. During the plugin instance uninstallation phase, the callback operation is cleaned up through the yhsbx_uncallback() interface, and the sandbox is destroyed by calling yhsbx_destory() on the xxsbx object.

[0095] So far, the above S51 to S55 describe the process of how to use sandbox third-party plug-in source code when writing plug-in library source code, taking the yhsbx sandbox as an example.

[0096] Step 106: compile the plug-in library source code into the plug-in library and run it.

[0097] In a possible implementation, step 106 includes the following sub-steps.

[0098] S61, use CMake to compile the plugin library source code into a plugin library.

[0099] Compilation refers to the process of building all source code into a dynamic library. All source code includes the C source code and header files corresponding to the third-party plug-in source code, the sandbox entry header file, and the plug-in library source code.

[0100] The plugin library is compiled by using CMake to create the plugin library source code. The plugin library source code is in C language, and the plugin library is in the form of a so.

[0101] In a possible implementation, CMake is used when compiling the plug-in. When setting the source code path in CMakeLists.txt, the C file converted by the wasm2c conversion module must be included, which is yhsbx_xx.wasm.c in this case.

[0102] S62, the application layer of the web application runs the plug-in library through the HTML element.

[0103] Running refers to the process of loading a plug-in library by a web application. The process includes loading the plug-in library through HTML elements, loading and initializing the plug-in library in JavaScript code, and accessing third-party plug-ins with the help of sandboxed code contained in the plug-in library.

[0104] The application layer of the web application loads the compiled plug-in library source code through the HTML element embed or object, calls the plug-in initialization interface and communication interface in the JavaScript code, interacts with the plug-in library, and then accesses third-party plug-ins.

[0105] Therefore, the present invention provides a secure isolation and integration method for Web application plug-ins. The method is applied to a Web operating system to implement plug-in integration and sandbox third-party plug-in source code for access by Web applications. This solves the problem of being unable to securely call third-party plug-ins in Web systems, reduces the risk of using third-party plug-ins in applications, and improves the security of the entire operating system.

[0106] Example 2

[0107] Figure 2The system is an operating system for the secure isolation and integration method of Web application plug-ins of the present invention, which is used to implement the above method. The system is applied in the environment where the Web operating system runs, including a sandbox operating environment for third-party plug-in source code and a Web application multi-language programming framework.

[0108] The multi-language programming framework for web applications includes application modules and plug-in modules. The plug-in module provides an API to the application module and is called by the application module. The sandbox runtime environment for third-party plug-in source code consists of a sandbox module and an encapsulation module. The sandbox module provides a wasm-based isolation mechanism. The wasm compilation module compiles the third-party plug-in source code into wasm bytecode, achieving memory isolation between the sandboxed third-party plug-in source code and the application (specifically, the C++ plug-in library). The sandbox module's wasm2c conversion module then converts the wasm file into a C file to facilitate plug-in calls. The encapsulation module provides the multi-language programming framework for web applications with an API for calling the sandboxed third-party plug-in source code.

[0109] like Figure 3 As shown, a data flow diagram between a third-party plug-in source code and a plug-in library is provided. The present invention opens up a memory sharing area in the sandbox module to solve the problem that the sandbox code cannot access the memory of the application (specifically referring to the plug-in library here) due to the memory isolation effect. With the memory sharing area, the developer can explicitly allocate memory that can be accessed by both the application (specifically referring to the plug-in library here) and the sandbox. For digital types, it is only necessary to copy the value to the sandbox module memory. For complex data types such as structures and arrays, it is necessary to use the yhsbx_allocate() interface to allocate memory in the memory sharing area, and copy the application data to this memory area. The interface returns a marked pointer that can be used by both the application and the sandbox. After the memory is used up, the yhsbx_free() interface is used to release the memory applied for in the memory sharing area.

[0110] Since the source code of third-party plug-ins in the sandbox may be under the control of attackers, in order to ensure that the application code (specifically the plug-in library here) does not use unsafe values ​​from the sandbox, the present invention designs a type tagging system, which tags all such values ​​from the sandbox. The type tagging system uses templates to implement generic tagged <t>Type, which makes all data coming out of the sandbox tagged from the beginning, by using tagged <t>Constructors automatically tag data by wrapping it in a constructor. When using the yhsbx API, parameters and return values ​​must be tagged. This ensures that data entering the sandbox from the plugin library is of only two types: numeric and tagged. For example, tagged pointers distinguish pointers to application (specifically, the plugin library) memory from pointers to sandbox memory at the type level, facilitating the automatic execution of important security requirements and checks.

[0111] The execution results of functions in the sandboxed third-party plug-in source code used in the plug-in library must be copied to the application's (specifically the plug-in library) memory. This keeps the data away from attackers and ensures that the sandbox code cannot modify the data. Since it is unsafe to use the data without verification, the data needs to be verified to unpack it. The specific method is to pass a closure verification function to the security verification module. The verifier in the security verification module will first convert the data from the tagged <t>The data type is converted to an unmarked T type that can be used in the plug-in library. The converted data is then copied to the application (specifically the plug-in library) memory. The security verification module runs the passed closure verification function to verify the conversion result data, so that the result data can be safely used in the plug-in library. The security verification module can identify all locations where data check code must be added. If code checks are not added in places where security verification is required, an error will be reported during code compilation. Considering efficiency and performance issues, verification of marked data is only performed when necessary. For example, when adding or reallocating data, or when writing data to create a pointer that has already been checked, no security check will be performed. This can eliminate unnecessary impacts and modifications to the rendering process and ensure the security of the rendering process.

[0112] Example 3

[0113] In addition, the present application also provides a secure isolation and integration device for a Web application plug-in, which is applied to a Web operating system, and the device includes:

[0114] A code input module, used to input third-party plug-in source code into the Web operating system;

[0115] A compilation module, configured to compile the third-party plug-in source code into a wasm file through a wasm compilation module of a sandbox module, wherein the sandbox module is configured to provide an isolated environment;

[0116] A conversion module, configured to convert the wasm file through the wasm2c conversion module of the sandbox module to obtain the C source code and header file corresponding to the third-party plug-in source code;

[0117] A code reconstruction module, used to perform sandbox reconstruction on the source code of the third-party plug-in;

[0118] A plug-in writing module is used to write the plug-in library source code and call the C source code and header files corresponding to the third-party plug-in source code;

[0119] The plug-in running module is used to compile the plug-in library source code into a plug-in library and run it.

[0120] Optionally, the code reconstruction module includes:

[0121] The first reconstruction unit is used to write a target header file for the third-party plug-in source code to adapt to the yhsbx sandbox, wherein the target header file includes a structure definition header file, a sandbox class definition header file, and a sandbox entry header file;

[0122] The second reconstruction unit is used to use macros to perform structural definition on the Struct structure of the third-party plug-in source code according to rules during the process of compiling the structure definition header file;

[0123] The third reconstruction unit is used to call the function of defining the yhsbx sandbox base class for the third-party plug-in and pass in the class name parameter during the process of writing the sandbox class definition header file;

[0124] The fourth reconstruction unit is used to introduce the structure definition header file, the sandbox class definition header file and the sandboxed third-party plug-in source code entry header file in the process of writing the sandbox entry header file. The sandboxed third-party plug-in source code entry header file refers to the sandbox header file and the header file corresponding to the third-party plug-in source code converted by the wasm2c conversion module of the sandbox module.

[0125] Optionally, the plug-in writing module includes:

[0126] A first writing unit is used to introduce the sandbox entry header file and the sandbox class definition header file;

[0127] The second writing unit is used to create a sandbox during the plug-in instance initialization phase by encapsulating the module when writing the plug-in library source code;

[0128] The third writing unit is configured to use the yhsbx_allocate() memory management interface to allocate memory in the shared memory area of ​​the sandbox at a code location where the third-party plug-in source code is required;

[0129] A fourth writing unit is configured to call a function in the third-party plug-in source code using a secure function calling interface;

[0130] The fifth writing unit is configured to release the memory through the yhsbx_free() memory management interface in response to the memory not being needed, and destroy the sandbox during the plug-in instance uninstallation phase.

[0131] Optionally, the plug-in running module includes:

[0132] The first running unit is configured to compile the plug-in library source code into a plug-in library using CMake;

[0133] The second running unit is used for the application layer of the Web application to run the plug-in library through the HTML element.

[0134] Optionally, the compilation refers to the process of building all source codes into a dynamic library, where all source codes include the C source code and header files corresponding to the third-party plug-in source code, the sandbox entry header file, and the plug-in library source code;

[0135] The operation refers to the process of loading the plug-in library by the Web application, which includes loading the plug-in library through the HTML element, loading and initializing the plug-in library in the JavaScript code, and completing the access to the third-party plug-in with the help of the sandbox code contained in the plug-in library.

[0136] Optionally, the third writing unit is further used to give a default value through the yhsbx sandbox; after calling the memory management interface yhsbx_allocate(), allocate an area in the shared memory area of ​​the sandbox according to the default value; when the data is used, the yhsbx sandbox automatically calculates the memory size required for the data and dynamically adjusts the allocated area size to complete the memory application.

[0137] An embodiment of the present application further provides a computer-readable medium storing at least one instruction, wherein the at least one instruction is loaded and executed by the processor to implement the secure isolation and integration method of the Web application plug-in as described in the above embodiments.

[0138] The above description is merely an optional embodiment of the present application and is not intended to limit the present application. Any modifications, equivalent replacements, improvements, etc. made within the spirit and principles of the present application shall be included in the scope of protection of the present application.< / t> < / t> < / t>

Claims

1. A secure isolation and integration method for a Web application plug-in, characterized in that: Applied to a Web operating system, the method includes: In the Web operating system, input the third-party plug-in source code; Compile the third-party plug-in source code into a wasm file through a wasm compilation module of a sandbox module, wherein the sandbox module is used to provide an isolated environment; The wasm file is converted by the wasm2c conversion module of the sandbox module to obtain the C source code and header file corresponding to the third-party plug-in source code; Sandboxing and reconstructing the third-party plug-in source code; Write the plug-in library source code and call the C source code and header files corresponding to the third-party plug-in source code; Compile the plug-in library source code into a plug-in library and run it; The sandboxing and reconstructing of the third-party plug-in source code includes: Compile the target header file of the third-party plug-in source code to adapt to the yhsbx sandbox, wherein the target header file includes a structure definition header file, a sandbox class definition header file, and a sandbox entry header file; In the process of writing the structure definition header file, the structure definition of the Struct structure of the third-party plug-in source code is performed using macros according to rules; In the process of writing the sandbox class definition header file, call the function that defines the yhsbx sandbox base class for the third-party plug-in and pass in the class name parameter; In the process of writing the sandbox entry header file, the structure definition header file, the sandbox class definition header file and the sandboxed third-party plug-in source code entry header file are introduced. The sandboxed third-party plug-in source code entry header file refers to the sandbox header file and the header file corresponding to the third-party plug-in source code converted by the wasm2c conversion module of the sandbox module.

2. The method according to claim 1, characterized in that The writing of the plug-in library source code and calling the C source code and header files corresponding to the third-party plug-in source code include: Import the sandbox entry header file and the sandbox class definition header file; When writing plugin library source code, create a sandbox during plugin instance initialization by encapsulating the module; At the code location where the third-party plug-in source code is needed, use the yhsbx_allocate memory management interface to apply for memory in the shared memory area of ​​the sandbox; Using a secure function call interface to call a function in the third-party plug-in source code; In response to the memory not being needed, the memory is released through the yhsbx_free memory management interface, and the sandbox is destroyed during the plug-in instance unloading phase.

3. The method according to claim 1, characterized in that Compiling the plug-in library source code into a plug-in library and running the plug-in library includes: Compile the plugin library source code into a plugin library using CMake; The application layer of the web application runs the plug-in library through HTML elements.

4. The method according to claim 3, characterized in that Compilation refers to the process of building all source codes into a dynamic library, including the C source code and header files corresponding to the third-party plug-in source code, the sandbox entry header file and the plug-in library source code; The operation refers to the process of loading the plug-in library by the Web application, which includes loading the plug-in library through the HTML element, loading and initializing the plug-in library in the JavaScript code, and completing the access to the third-party plug-in with the help of the sandbox code contained in the plug-in library.

5. The method according to claim 2, characterized in that At the code location where the third-party plug-in source code is needed, the yhsbx_allocate memory management interface is used to apply for memory in the shared memory area of ​​the sandbox, including: Default values ​​given by the yhsbx sandbox; After calling the memory management interface yhsbx_allocate, an area is allocated in the shared memory area of ​​the sandbox according to the default value; When data is used, the yhsbx sandbox automatically calculates the memory size required for the data and dynamically adjusts the allocated area size to complete the memory application.

6. A secure isolation and integration device for a Web application plug-in, characterized in that: Applied to a Web operating system, the device includes: A code input module, used to input third-party plug-in source code into the Web operating system; A compilation module, configured to compile the third-party plug-in source code into a wasm file through a wasm compilation module of a sandbox module, wherein the sandbox module is configured to provide an isolated environment; A conversion module, configured to convert the wasm file through the wasm2c conversion module of the sandbox module to obtain the C source code and header file corresponding to the third-party plug-in source code; A code reconstruction module, used to perform sandbox reconstruction on the source code of the third-party plug-in; A plug-in writing module is used to write the plug-in library source code and call the C source code and header files corresponding to the third-party plug-in source code; A plug-in running module, used to compile the plug-in library source code into a plug-in library and run it; The code reconstruction module is further used to write the target header file of the third-party plug-in source code adapted to the yhsbx sandbox, wherein the target header file includes a structure definition header file, a sandbox class definition header file and a sandbox entry header file; In the process of writing the structure definition header file, the structure definition of the Struct structure of the third-party plug-in source code is performed using macros according to rules; In the process of writing the sandbox class definition header file, call the function that defines the yhsbx sandbox base class for the third-party plug-in and pass in the class name parameter; In the process of writing the sandbox entry header file, the structure definition header file, the sandbox class definition header file and the sandboxed third-party plug-in source code entry header file are introduced. The sandboxed third-party plug-in source code entry header file refers to the sandbox header file and the header file corresponding to the third-party plug-in source code converted by the wasm2c conversion module of the sandbox module.

7. A computer-readable storage medium, characterized in that The computer-readable storage medium stores a computer program, which is loaded and executed by a processor to implement the secure isolation and integration method for Web application plug-ins according to any one of claims 1 to 5.

Images