A vulnerability detection method based on mini-program framework

Abstract

The present invention belongs to the field of vulnerability detection and testing technology, specifically a vulnerability detection method based on a mini-program framework. The vulnerabilities described in the present invention are of two types: cloud-side software component loading vulnerabilities and end-side application API access control vulnerabilities; for the former, fuzz testing technology is used to mutate some fields in the link that starts the mini-program, and then the corresponding APP is started through the intent mechanism in Android and the corresponding software components are loaded in its corresponding mini-program, and the loading results are used to determine whether this type of vulnerability exists; for the latter, dynamic testing technology is used to control a single variable in each test, and the call results of the same sensitive API in different experimental environments are observed to determine whether this type of vulnerability exists. The present invention can automatically and quickly detect two types of vulnerabilities in the (class) mini-program framework in the APP, discover its defects in security policy, and thus block malicious attacks from attackers.

Description

Technical Field

[0001] The present invention belongs to the technical field of vulnerability detection and testing, and specifically relates to a vulnerability detection method based on a mini-program framework. Background Art

[0002] Mobile applications, with their rich functionality, have brought immense convenience to people's work and daily lives. To better serve existing users and attract new ones, popular apps like WeChat and Alipay have transformed themselves into super apps, attracting third-party developers to offer the richest possible content and functionality. Sub-applications developed by other parties running within these super apps are called "mini-programs." This ecosystem of mini-program frameworks is incredibly popular. For example, WeChat boasts 3.8 million mini-programs, surpassing the 3.04 million Android apps in the Google Play Store.

[0003] There are three different models for mobile application development today: native applications (pure native development), web applications, and hybrid applications (mixed development). Native applications use apps developed using native Android. Their advantages include the best application performance and user experience, but their disadvantages are also relatively obvious, including high development barriers, high resource investment, and difficulty in upgrading. Business within web applications is developed and rendered using a pure front-end approach. Development is simple, and the code can be reused in multiple environments, but the user interaction experience is often poor. Hybrid applications combine the advantages of the above two models, with both efficient development speed and a high-performance experience for users. The development model of the mini-program framework is a mixed development method, which uses native Android development and has the ability to load web resources.

[0004] When a user clicks on a mini-program in a super app to start it, the corresponding Android component Activity in the super app receives an Intent notification to launch it. It then downloads the mini-program's resources from the server to the local mobile device. Then, based on the mini-program's code logic, it loads the content into a WebView (Android component) instance. The WebView instance can load template files downloaded from the server or external web resources from third parties with different domain identities. For example, a mini-program can load a third-party advertising provider's domain name. After loading and rendering, the mini-program can access powerful and sensitive privileged APIs provided by the super app. For example, these APIs can access saved user data (such as personal information such as the account used during registration and phone number) and utilize operating system-level resources provided to the super app (such as geolocation, camera, and microphone). The mini-program's ability to access APIs is provided by the WebView component. Developers can choose to bind a JavaScript Bridge to the WebView component. JavaScript code running in the WebView component can use this JavaScript Bridge to call into the Java code in the super app, thereby accessing sensitive APIs provided by the super app.

[0005] When a mini program loads content through WebView, a reliable security policy needs to be implemented for the loaded content. Otherwise, the mobile mini program may load and render unexpected view content that violates the mini program developer's intentions. When a mini program calls a sensitive privileged API provided by a super application, an access control policy also needs to be implemented for each API call. Not every API call can be successfully executed, otherwise it may lead to the leakage of user or system resources.

[0006] Traditional static analysis challenges the cross-language technical framework of mini-programs. Mini-program code logic is written in JavaScript, while the super-apps within which they run are written in Java. Furthermore, mini-programs are developed using customized code with unique lifecycle functions. Packaged mini-program code is fragmented and often dynamically downloaded from the cloud. Traditional static analysis cannot address these challenges.

[0007] For traditional dynamic testing, mini programs do not have a unified input format, and there are many startup entries, which makes it impossible to efficiently generate input that can be used for batch dynamic testing. In addition, different super applications require different input formats, so traditional dynamic testing has no way to solve these challenges.

[0008] The correct implementation of the above two security strategies is the basis for ensuring the security of mini programs. If there are loopholes in the security strategies of any link, it is very likely to cause users or systems to be attacked. Summary of the Invention

[0009] The purpose of the present invention is to provide a method for automatically detecting security vulnerabilities of a mini-program framework in an emerging super application.

[0010] The vulnerability detection method based on the mini-program framework provided by the present invention uses crawler technology, fuzz testing technology, static program analysis and dynamic testing technology to automatically detect two types of vulnerabilities in popular mini-program frameworks: cloud-side software component loading vulnerabilities and terminal-side API access control vulnerabilities.

[0011] The proposed method is based on the following observation (objective reality): the main technical principles of the popular mini-program framework within super apps are divided into two parts. The first part uses the WebView component to load and render the corresponding mini-program page, and the second part uses the JsCore thread to run the mini-program's JavaScript logic script. The content displayed to the user by the mini-program is implemented in the first part, while the API call logic that actually implements the functionality is implemented in the second part.

[0012] When loading and rendering the corresponding page content, the mini program should control the loaded page content, that is, it should limit the page content loaded and displayed to the user. For this stage, this paper proposes a detection model based on the intent mechanism in Android, which can automatically detect whether the security policy implemented by the mini program developer at this stage is comprehensive and reliable.

[0013] When implementing mini-program functionality and executing API calls, different API functions may involve sensitive user information or operating system-level resources. Therefore, super-apps must implement access control for each API call, determining whether the API call should be allowed and the corresponding resources should be properly protected. For this stage, this paper proposes a dynamic testing model based on a single variable to test the comprehensiveness and reliability of the super-app's security policy for API access control.

[0014] The present invention can automatically identify Android applications (hereinafter referred to as APPs) that have integrated a mini-program framework and detect two types of vulnerabilities in the mini-program framework: cloud-side software component loading vulnerabilities and end-side application programming interface (hereinafter referred to as API) access control vulnerabilities. In order to form a closed loop in the current APP as much as possible for user needs, that is, there is no need to switch to another APP to meet other needs, the super applications on the market now bring together many sub-applications developed by other parties. This feature makes it very popular, and more and more APPs are connected to the mini-program framework. For example, in the super application WeChat, more than 3.8 million sub-applications are hosted. For the emerging popular framework of mini-programs, the present invention proposes a detection method based on the combination of static program analysis and dynamic program testing to detect two types of vulnerabilities in the mini-program framework.

[0015] To detect software component loading vulnerabilities, the present invention uses fuzz testing technology to mutate some fields in the link that starts the mini-program, then starts the corresponding APP through the intent mechanism in Android and loads the corresponding software components in its corresponding mini-program, and determines whether this type of vulnerability exists based on the loading results.

[0016] For end-side application API access control vulnerabilities, the present invention adopts dynamic testing technology, controls a single variable in each test, and determines whether this type of vulnerability exists by observing the call results of the same sensitive API in different experimental environments.

[0017] The present invention can detect two vulnerabilities in the (class) applet framework in the APP, discover its defects in security policy, and thus block malicious attacks from attackers. BRIEF DESCRIPTION OF THE DRAWINGS

[0018] Figure 1 This is a flowchart of the vulnerability detection method based on the mini-program framework of the present invention. DETAILED DESCRIPTION

[0019] In order to evaluate the security strategies implemented by the super applications using the mini-program framework in the market at these two stages, the vulnerability detection method based on the mini-program framework provided by the present invention is divided into four steps. Figure 1 Specifically:

[0020] (1) Collecting end-cloud integrated (type) mini-program datasets

[0021] In this phase, static analysis is used to filter out super applications that integrate mini-program frameworks from ordinary applications as much as possible.

[0022] To collect as many super-apps as possible that integrate the mini-app framework, the present invention crawled nearly 6,000 popular free Android apps from Google Play and Wandoujia. Mini-app-based page rendering is implemented using the WebView component in Android. The initial dataset was filtered through static analysis. If the static analysis found that an application used the WebView component, it was retained; otherwise, it was discarded. However, for Android applications, using the WebView component is relatively common. For example, applications can use the WebView component to load privacy policies, advertising pages, and so on. In cases where only the WebView component is used to load local or external content, the corresponding WebView component is typically not bound to the JavaScript Bridge by the developer. However, if the page loaded by the mini-app needs to interact with the user and have the ability to access the API provided by the super-app, its WebView will inevitably be bound to the JavaScript Bridge. There are two ways to bind the JavaScript Bridge to the WebView component: one is to use the addJavaScriptInterface() method to expose the JavaScript Bridge implementation class to the JavaScript code running in the WebView component; the other is to intercept several JavaScript events, such as console.log(), alert(), prompt(), and confirm(), and rewrite the Java callback function to implement the corresponding functionality. By locating the above features through static analysis, we added the following constraints based on manual analysis for the case of overriding event callback functions: the callback function must be overridden and the length of the call chain starting from the callback function must be greater than N. This can more accurately ensure that the event callback function is used to implement the JavaScript Bridge, rather than just used to record JavaScript events triggered in the WebView component.

[0023] After filtering out super applications through the above features, in order to test for cloud-side software loading vulnerabilities, the present invention also needs to collect the resources of the mini-programs running in the super applications. Because the type of external web resources that a mini-program can load is determined by the mini-program developer, whether the cloud-side software component loading vulnerability exists is determined by the code logic of the mini-program itself. In this step, the following three methods are used to perform corresponding collection for different super applications:

[0024] (1) Analyze the traffic when the mini program is started. Since each mini program has a unique ID corresponding to it, which is used to identify the mini program, by intercepting the traffic when the mobile super application downloads the resources of the corresponding mini program from the server according to the ID, modifying the ID field, and then replaying this request, the relevant resources of different mini programs stored on the server can be obtained;

[0025] (2) Some super applications encrypt traffic, making it impossible to capture the corresponding traffic and modify the fields for replay. Therefore, we reverse engineer the super application and locate the pre-function that constructs a request to obtain server resources based on the ID. By replaying the call to the pre-function and passing a different mini-program ID into it, we can obtain the relevant resources of the corresponding mini-program.

[0026] (3) If neither of the above two methods is successful, use UI Automator to simulate manual use of mini-programs. This method is based on the following observation: when a user uses a mini-program, the super application must download the resources of the corresponding mini-program from the server to the local device; using UI Automator can simulate manual access to different mini-programs, so that the resources of different mini-programs will be downloaded to the local mobile device, and the relevant resources of these visited mini-programs can be obtained from the corresponding storage directory.

[0027] (2) Testing for Cloud-side Software Component Loading Vulnerabilities

[0028] In this stage, fuzz testing is used to detect whether the corresponding applet has cloud-side software component loading vulnerabilities.

[0029] What kind of external web resources the mini program can load is determined by the mini program developer, so whether the cloud-side software component loading vulnerability exists is determined by the code logic of the mini program itself. Therefore, the present invention first extracts the mini program ID, the page names contained in the mini program, and the parameter field names received when each page is started from the mini program's code resources through static analysis, which are used to construct a link for subsequent fuzz testing.

[0030] For super apps, either collect deep links related to mini-programs from their official documents or extract possible deep links from the app code through static analysis. After extracting the deep link, the format of the deep link is as follows: scheme: / / path / ID / page Key=value. The value of scheme corresponds to the super application one by one, and each super application has its own scheme value. Specifying this value specifies which super application this Deep Link will start. The path field is also strongly related to the super application, and super applications usually use this field to identify different businesses. The ID, page, and Key fields are strongly related to the mini program framework, and respectively specify the mini program to be started by the Deep Link, the corresponding page, and the startup parameter Key passed to the page. For such a Deep Link format, the present invention fills the corresponding fields with corresponding values according to different super applications, and mutates the value field therein.

[0031] For each variant Deep Link, the present invention determines whether its corresponding content can be successfully loaded by the corresponding Mini Program by hooking the loadUrl() function of the WebView component and judging by the execution result of this function. If the parameters received by this function are consistent with the content in the Deep Link, it indicates that the Mini Program has a cloud-side software component loading vulnerability.

[0032] (3) Discovery of Sensitive APIs on the Device Side

[0033] In this phase, more sensitive APIs on the end side are discovered through a combination of static analysis and dynamic testing.

[0034] In order to test whether the super application has an end-side API access control vulnerability, it is first necessary to extract the corresponding API list from the super application. In this step, the present invention adopts a combination of static analysis and dynamic analysis. Identifying the API framework is based on the following observations: When the JavaScript code running in the WebView component accesses the API, it will pass through the JavaScript Bridge to reach the JAVA code in the super application. From the control flow analysis, each API call will reach the API pool (hereinafter referred to as the API pool). This API pool stores all APIs under the mini program framework. Each API call will take out the implementation class of the corresponding API from the API pool and make subsequent calls. Therefore, the goal of this step is to locate the API pool and extract the contents stored therein.

[0035] Identifying the API framework involves two steps. The first step involves identifying the WebView component and locating the JavaScriptBridge entry point to which it is bound. The parameters received by this entry point are the parameters for each API call. Therefore, taint analysis is performed on these parameters. When the API pool (represented in the code as java.util.Map or its subclasses) is contaminated, the corresponding API pool class and the signatures of the methods accessing it are output to a JSON-formatted file for subsequent dynamic analysis input. This completes the goal of the first step of static analysis. The second step uses the Xposed-based hook framework to write hook functions that capture information about triggered functions in real time. The output from the first step serves as input for the second step, automatically hooking the target functions and possible target API pools contaminated in the first step by reading the JSON file. Next, different super apps are launched and the mini-program functions within them are used. If the hooked functions are triggered, the corresponding information is output, and the contents of the triggered API pool are also printed out, thereby obtaining sensitive APIs provided by the super apps to the mini-program framework.

[0036] (IV) End-side API access control vulnerability testing

[0037] In this phase, dynamic testing is used to detect whether the super application has end-side API access control vulnerabilities.

[0038] Super Apps perform permission checks based on the ID of the mini-program or the identity of the page owner that calls sensitive APIs. Certain privileged mini-programs or privileged page owners have the right to call all sensitive APIs. However, combined with the "cloud-side software component loading vulnerability," the attacker's identity can be elevated to a privileged level, giving the attacker the ability to call sensitive privileged APIs.

[0039] In order to detect whether there are loopholes in the API access control of the super application, the present invention calls the same API under different identities (different mini-programs, different page owners). If the calling results are different, it is determined that there is a loophole in the access control of the API.

[0040] In order to ensure the completeness of the test API as much as possible, the present invention collects examples of different API calls during the normal operation of the mini-program, and combines them with the sensitive APIs discovered on the end side. This union is used as the API call library to construct test cases.

[0041] For the same API, fix the same mini-program ID, change different page owner identities, conduct tests under this experimental condition, and compare the calling results; if the call is successful under the identity of page owner A, but fails under the identity of other page owners, it means that the page owner A is a privileged identity. Combined with the "cloud-side software component loading vulnerability", simulating the page owner A can enable attackers to have the ability to call sensitive APIs.

[0042] For the same API, the page owner identity is fixed, different mini-program IDs are changed, and tests are performed under these experimental conditions to compare the calling results. If the call is successful under a certain mini-program ID "X" but fails under other mini-program IDs, it means that the mini-program ID "X" is a privileged identity. Combined with the "cloud-side software component loading vulnerability", loading a malicious page controlled by the attacker into the mini-program can enable the attacker to call sensitive APIs.

[0043] Practice Test

[0044] (1) Test environment preparation

[0045] In order to verify the feasibility and effectiveness of the method of the present invention, all specific implementations are carried out on a unified server configuration and mobile devices. Specifically, the simulated test environment of this method relies on a OnePlus 7 mobile phone equipped with an Android 10.0 system, a Snapdragon 855 processor, 8GB RAM and 256GB ROM. The static analysis method relies on a high-performance server. During this test, an x86_64-bit server with Ubuntu 18.04 installed was used, which contained 548.61GB of storage, a total of 10 cores and 39 processors, and an Intel Xeon E7-4820 v4 CPU.

[0046] (2) Simulation test process and results

[0047] First, through static analysis, this method identified 291 apps containing WebView components and complex JavaScriptBridge implementations from 6,000 popular Android apps. Using relevant documentation, 47 mini-program super apps were quickly found. The filtering results at each stage are shown in the table below.

[0048] .

[0049] Furthermore, this method can automatically collect tens of thousands of mini-programs from mainstream WeChat, Baidu, and Alipay applications for subsequent vulnerability analysis.

[0050] In the terminal-side sensitive API discovery test, this method analyzed 15 popular applications and identified more than 4,038 terminal-side APIs. After manual analysis, it was confirmed that nearly 50% of them were APIs with non-public documentation.

[0051] .

[0052] This test implemented vulnerability detection code for 47 mini-programs using the aforementioned method. The test results are as follows.

[0053] We found that nine super apps failed to implement any security measures to protect their sensitive functional interfaces. The remaining 38 super apps had security vulnerabilities in their resource loading checks. Fifteen super apps implemented domain-based access control mechanisms and were all affected by vulnerabilities in the WebView component. Two super apps also had credential management gaps, potentially rendering access control ineffective. Regarding vulnerability impact, all 38 super apps were susceptible to unauthorized attacks, 31 of which were vulnerable to phishing attacks, and 35 to potential sensitive information leakage.

Claims

1. A vulnerability detection method based on a mini-program framework, characterized in that: The specific steps are: (1) Collecting data sets of mini-programs that integrate end and cloud; (2) Testing for vulnerabilities in loading cloud-side software components; Use fuzz testing to detect whether the corresponding applet has cloud-side software component loading vulnerabilities; First, through static analysis, the applet's code resources are extracted from the applet's ID, the names of the pages it contains, and the names of the parameter fields received when each page is started. These are used to construct a link for subsequent fuzz testing. For super apps, we collect deep links related to mini-apps from their official documentation, or extract possible deep links from the app code through static analysis. After extracting the deep link, the format of the deep link is as follows: scheme: / / path / ID / page?Key=value. The scheme value corresponds to the super app one by one. Each super app has its own scheme value, and specifying this value determines which super app this deep link will launch. The path field is also strongly related to the super app, and super apps use this field to identify different businesses. The ID, page, and Key fields are strongly related to the Mini Program framework, respectively specifying the Mini Program to be launched by the Deep Link, the corresponding page, and the key parameter passed to the page. For this Deep Link format, the corresponding fields are filled with corresponding values based on the different Super Apps, and the value field is mutated. For each mutated Deep Link, whether its corresponding content can be successfully loaded by the corresponding Mini Program is determined by hooking the execution result of the loadUrl() function of the WebView component. If the parameters received by this function are consistent with the content in the Deep Link, it indicates that the Mini Program has a cloud-side software component loading vulnerability. (3) Discovery of Sensitive APIs on the Device Side Discover more sensitive APIs on the client side through a combination of static analysis and dynamic testing; To test whether a super app has a client-side API access control vulnerability, first extract the corresponding API list from the super app. The goal of this step is to locate the API pool and extract the content stored therein. Identifying the API framework is a two-step process: The first step is to identify the WebView component and locate the JavaScript Bridge entry point to which it is bound. The parameters received by this entry point function are the parameters of each API call. Therefore, taint analysis is performed on the parameters received by the entry point function. When the API pool is contaminated, the corresponding API pool class and the method signature that accesses the API pool are output to a JSON file for record storage for subsequent dynamic analysis input. In the second step, we use the Xposed-based hook framework to write hook functions and obtain the triggered function information in real time. The output of the first step is used as the input of the second step. By reading the JSON file, we automatically hook the target function and possible target API Pool that were contaminated in the first step. Next, we launch different super applications and use the mini-program functions in them. If the hooked function is triggered, the corresponding information will be output. The triggered API Pool will also print out the stored content, thus obtaining the sensitive API provided by the super application to the mini-program framework. (IV) End-side API access control vulnerability testing Use dynamic testing to detect whether super applications have end-side API access control vulnerabilities; Super Apps perform permission verification based on the mini-program ID or the owner of the page that calls sensitive APIs. Owners of certain privileged mini-programs or pages have the right to call all sensitive APIs. However, combined with the "cloud-side software component loading vulnerability," the attacker's identity can be elevated to a privileged level, giving the attacker the ability to call sensitive privileged APIs. To detect vulnerabilities in the API access control of super applications, the same API is called under different identities. If the call results are different, it is determined that there is a vulnerability in the API access control. To ensure the completeness of the test API as much as possible, during the normal operation of the mini program, we collected examples of different API calls and combined them with sensitive APIs discovered on the client side. This union was used as the API call library to construct test cases. For the same API, we fixed the same Mini Program ID, changed the identities of different page owners, conducted tests under these experimental conditions, and compared the call results. If the call succeeds under the identity of page owner A but fails under the identity of other page owners, it means that page owner A is a privileged identity. Combined with the "cloud-side software component loading vulnerability", the attacker can simulate page owner A and gain the ability to call sensitive APIs. For the same API, we fixed the page owner identity, changed different mini program IDs, conducted tests under these experimental conditions, and compared the call results. If the call succeeds under a certain mini-program ID "X" but fails under other mini-program IDs, it means that the mini-program ID "X" is a privileged identity. Combined with the "cloud-side software component loading vulnerability", a malicious page controlled by the attacker is loaded into the mini-program, giving the attacker the ability to call sensitive APIs.

2. The vulnerability detection method based on the applet framework according to claim 1 is characterized in that: The collection of the end-cloud integrated mini-program dataset in step (1) is performed by filtering out super applications that integrate the mini-program framework from ordinary applications through static analysis; Specifically, we crawled 6,000 popular free Android apps from Google Play and Wandoujia. Mini-app-based page rendering is implemented using the WebView component in Android. The initial dataset was filtered through static analysis. If the static analysis found that the app used the WebView component, it was retained; otherwise, it was discarded. When only the WebView component is used to load local or external content, the corresponding WebView component will not be bound to the JavaScript Bridge by the developer. However, if the page loaded by the mini program needs to interact with the user and have the ability to access the API provided by the super application, its WebView will be bound to the JavaScript Bridge. There are two ways to bind the JavaScript Bridge to the WebView component. One is to use the addJavaScriptInterface() method to expose the implementation class of the JavaScript Bridge to the JavaScript code running in the WebView component. The other is to intercept several events in JavaScript and rewrite the callback function on the JAVA side to implement the corresponding functions. For the case of rewriting the event callback function, based on manual analysis, the following constraints are added: the callback function must be rewritten and the length of the call chain starting from the callback function must be greater than N. This more accurately ensures that the event callback function is used to implement the JavaScript Bridge, rather than just for recording JavaScript events triggered in the WebView component. After filtering out super apps through the above operations, in order to test the cloud-side software loading vulnerability, we further collect the resources of mini-programs running in super apps. During this process, we use the following three methods to collect resources for different super apps: (1) Analyze the traffic when the mini program is started. Since each mini program has a unique ID corresponding to it, which is used to identify the mini program, by intercepting the traffic when the mobile super application downloads the resources of the corresponding mini program from the server according to the ID, modifying the ID field in it, and then replaying this request, the relevant resources of different mini programs stored on the server can be obtained; (2) Some super applications encrypt traffic, making it impossible to capture the corresponding traffic and modify the fields for replay. By reverse engineering the super application, locating the pre-function that constructs a request to obtain server resources based on the ID, replaying the call to the pre-function and passing a different mini-program ID into it, the relevant resources of the corresponding mini-program can be obtained; (3) If the above two methods are unsuccessful, use UI Automator to simulate manual use of mini-programs and continuously access different mini-programs. In this way, the resources of different mini-programs will be downloaded to the local mobile terminal, and the relevant resources of these visited mini-programs can be obtained from the corresponding storage directory.

Images