[Bug]High-Risk Plugin Execution Model: Sandbox Isolation and Strict CSP Enforcement Needed

[bhangalesoham2606]

🐛 Problem Statement

The current plugin architecture in Music Blocks allows third-party JavaScript to execute directly within the main application thread using eval() and dynamically injected Blob scripts.

This execution model lacks proper isolation, allowing untrusted code to access:

• The global window object
• localStorage
• The DOM
• Sensitive browser APIs

Additionally, the use of inline <script> tags in index.html requires a permissive Content Security Policy (CSP), specifically enabling:

• 'unsafe-inline'
• 'unsafe-eval'

In an educational environment, this creates a significant security risk, including exposure to Cross-Site Scripting (XSS) attacks and potential data exfiltration.

---

🚨 Impact

• Security Bypass: Malicious plugins can bypass UI restrictions, access sensitive data, or hijack sessions
• XSS Vulnerability: Current CSP settings prevent modern browser protections from functioning effectively
• User Trust Risk: Relying on confirm() dialogs to approve plugin execution is insufficient, especially for young or non-technical users

---

🛠️ Proposed Solution & Architecture

1. Isolated Execution Environment (Sandbox)

Execute all unvetted plugins inside a cross-origin (null-origin) <iframe> with:
sandbox="allow-scripts"

• Prevent access to parent DOM and global scope

---

2. Capability-Based Permission API

Introduce a permissions manifest:
PERMISSIONS: ['audio', 'storage']

• Route sensitive operations via postMessage
• Require explicit user approval before execution

---

3. CSP Hardening

• Move all inline scripts from index.html to external .js files
• Enforce strict CSP:
  • Remove 'unsafe-inline'
  • Remove 'unsafe-eval'

---

4. Asynchronous Logo Engine

• Refactor core execution flow (parseArg, runFromBlockNow)
• Use async/await to support:
  • Promise-based sandbox communication
  • Non-blocking execution

---

5. Modernized Security Dialogs

• Replace confirm() with custom UI dialogs (e.g., MBDialog)
• Use Promise-based flows for:
  • Permission requests
  • Security warnings

---

✅ Acceptance Criteria

• No 'unsafe-inline' or 'unsafe-eval' in index.html
• Vetted (local) plugins execute with normal performance
• Unvetted plugins execute only inside sandboxed <iframe>
• No access to window, localStorage, or parent DOM from sandbox
• Logo engine correctly handles async responses from plugins

[rish106-hub]

Opened #7762 as a narrow first step toward this: it adds the isVettedPlugin() trust gate to the BLOCKPLUGINS/GLOBALS/ONLOAD setup handlers in processPluginData, which currently skip it — so unvetted plugin setup code no longer executes in the main realm after the confirm() dialog.

Scoped deliberately small (1 file + tests) rather than the full sandbox/CSP overhaul, since the larger #7048 stalled on scope. The iframe sandbox, capability manifest, and strict CSP remain valuable follow-ups. #7762 reuses the existing isVettedPlugin predicate uniformly, so it supersedes #7081's approach on current master.