Escaping the Sandbox: New Attack Vectors in the Mini-App Ecosystem

Introduction

In the modern mobile landscape, the 'Super-App' has become a dominant force. Apps like WeChat, TikTok, and Alipay are no longer just single-purpose tools; they are platforms hosting thousands of 'Mini-Apps.' These mini-apps offer a seamless user experience, running instantly without installation by leveraging web technologies and a native bridge. However, this convenience introduces a massive, often overlooked attack surface. This post dives into research from Black Hat Asia regarding how the sandbox environments of these super-apps can be bypassed to achieve Remote Code Execution (RCE) and total account compromise.

Historically, mobile security focused on native binaries or standard web browsers. Mini-apps sit in a precarious middle ground, using web engines like V8 or JavaScriptCore but possessing the ability to call native system APIs. This research reveals that the isolation we assume exists between a mini-app and its host is often paper-thin.

Background & Context

Mini-apps are essentially web applications wrapped in a custom framework provided by the super-app. They rely on a 'Logic Layer' (executing JavaScript) and a 'View Layer' (rendering UI). The communication between these layers and the host operating system happens through a JS-Native bridge (JSB).

Because mini-apps are intended to be lightweight and fast, they bypass traditional app store installation processes. Users launch them via QR codes or links, making them a perfect vector for 'one-click' attacks. The security of billions of users relies on the host super-app's ability to sandbox these mini-apps effectively. If the sandbox fails, a malicious mini-app can reach into the super-app's private data, steal session tokens, or even execute arbitrary code on the underlying device.

Technical Deep Dive

1. File System Sandbox Escapes

Most super-apps provide APIs for file management, such as readFile, writeFile, and unzip. The researchers found that many implementations were vulnerable to standard path traversal (../../).

• The Attack: An attacker crafts a mini-app that calls unzip on a malicious archive containing symlinks or files with traversal paths.
• The Impact: By traversing out of the mini-app's designated folder, attackers could overwrite sensitive files in the super-app's data directory. Specifically, overwriting dynamic libraries (.so files) or Dalvik Executable (.dex) files allows the attacker to achieve RCE the next time the super-app loads those resources.

2. Network Credential Leakage

The 'Request' API in many mini-apps does not follow the strict Same-Origin Policy (SOP) seen in browsers.

• The Flaw: When a mini-app makes a request to a first-party domain (the super-app's own servers), the host app often automatically attaches the user's main authentication cookies.
• The Exploit: A third-party mini-app can silently send a request to https://super-app.com/api/get_user_info. Because the bridge attaches the user's cookies, the server returns private data to the mini-app's JavaScript callback, leading to immediate account hijacking.

3. Hidden APIs and Prototype Pollution

Perhaps the most innovative part of this research is the discovery and exploitation of hidden APIs. Super-apps often contain 'private' APIs meant only for internal use. Attackers can find these by analyzing the JS Core source code found within the app's installation package.

To prevent the use of these APIs, super-apps often use a blacklist. However, the researchers applied a classic web vulnerability—JavaScript Prototype Pollution—to the mobile context to bypass these checks.

Step-by-Step Prototype Bypass:

1. The super-app checks if an API call is allowed using: if (blacklist.includes(apiName)) return error;.
2. The attacker 'pollutes' the Array prototype:

   Array.prototype.includes = function(val) {
     if (val === 'PrivilegedInternalAPI') return false;
     return originalIncludes.apply(this, arguments);
   };
   

3. When the security check runs, the polluted includes method returns false even for blacklisted items, allowing the restricted API to execute.

Mitigation & Defense

Defending a super-app requires a multi-layered approach:

• Environment Hardening: Use Object.freeze(Object.prototype) and Object.freeze(Array.prototype) early in the JS Core initialization to prevent prototype pollution attacks.
• Strict API Validation: Never rely on client-side (JS) checks for security. Validation must happen in the native layer where the mini-app cannot tamper with the logic.
• Path Sanitization: Use canonical paths and strict allow-lists for file operations. Disallow symlinks within extraction APIs.
• Network Isolation: Implement a strict 'Sandboxed Fetch' that does not automatically include host cookies unless explicitly authorized by the user and verified by the platform.

Conclusion & Key Takeaways

The shift toward mini-app ecosystems has outpaced the security controls required to protect them. This research demonstrates that traditional web vulnerabilities like path traversal and prototype pollution take on a much more dangerous form when granted access to native mobile bridges. For developers, the message is clear: the sandbox is only as strong as its weakest API. Continuous auditing of the JS-to-Native bridge and the implementation of immutability in the JS runtime are essential steps to securing the next generation of mobile applications.