Proposal for Secure Remote Code Handling in Browser Extensions
Issue:
I have developed complex automation plugins that involve significant effort and intellectual property. However, distributing these extensions exposes substantial parts of the code, allowing competitors to potentially copy and misuse it. This situation highlights the need for a better approach to secure remote code within extensions while protecting intellectual property.
Proposal:
I propose a structured method for managing remote code in extensions, incorporating verification, obfuscation, and encryption to enhance security and protect intellectual property.
- Extension Package Structure
When submitting an extension for signing, the package will include two primary components:
Local Extension Code: The code that is part of the XPI package.
Remote Code Settings: Instructions and references related to the remote code.
- XPI Extension Code Structure
The standard structure for the XPI package includes:
XPI Extension Code/
├── background-scripts/
├── content-scripts/
├── manifest.json
- Remote Code Structure
The remote code details are submitted as part of the signing process but are not included in the final XPI package. Instead, a settings.json file references the remote code structure:
Remote Code/
├── settings.json
├── background-scripts/
├── content-scripts/
Detailed Breakdown of settings.json
Before Signing:
{
“obfuscation_library”: “library_name”,
“obfuscation_params”: {
“param1”: “value1”,
“param2”: “value2”
},
“remote_code_files”: [
{
“filename”: “background-script.js”,
“url”: “https://your-server.com/scripts/background-script.js”
},
{
“filename”: “content-script.js”,
“url”: “https://your-server.com/scripts/content-script.js”
}
]
}
After Signing:
{
“remote_code_files”: [
{
“filename”: “background-script.js”,
“url”: “https://your-server.com/scripts/background-script.js”,
“md5”: “qwertyuiopasdfgh”
},
{
“filename”: “content-script.js”,
“url”: “https://your-server.com/scripts/content-script.js”,
“md5”: “asdfghjklzxcvbnm”
}
]
}
Process Workflow
Submission for Signing:
Developers submit the full package, including both local XPI extension code and remote code.
The settings.json file includes details about the obfuscation library, parameters, and URLs for remote code files.
Obfuscation and MD5 Generation:
Mozilla takes the code in the remote directory
Mozilla then obfuscates the code using the specified library and settings.
MD5 hashes are generated for each obfuscated file.
The settings.json file is updated with these MD5 hashes before finalizing the signing process.
Final Package Composition:
After signing, the remote code itself is removed from the XPI package.
The final XPI package will include:
The local extension code.
The Remote Code directory with settings.json, which contains the updated MD5 hashes.
Runtime Operation:
The extension fetches remote code based on the URLs specified in settings.json.
It computes MD5 hashes of fetched files and compares them with the hashes stored in settings.json to verify code integrity before execution.
Security and Integrity
Protection of Intellectual Property: Remote code is verified via MD5 hashes and protected by obfuscation (encrypting would be also nice but thats for later)
Flexibility for Updates: Developers can update remote code by resubmitting the extension for signing. Any changes to remote code require a new submission to ensure code integrity.
Maintained Security: MD5 hashes ensure that any remotely executed code matches the verified and signed code.
Developer and User Benefits
Secured Execution Environment: Ensures that only authorized and verified remote code is executed, preserving both security and code integrity.
Ease of Management: Developers can securely manage remote code without exposing it in the final XPI package, reducing the risk of intellectual property theft.
Controlled Updates: Allows developers to update remote code by resubmitting the extension, ensuring that any changes are verified and signed.
This would allow control over who gets the code, e.g. authenticated users, logged and tracked etc
Issues:
Some of the remote code may have injected variables e.g. user name from a server say from a rails app then serving the code with modifications - so yes some will complain…
Thoughts? Don’t shoot this down - try to think objectively about how we can commercialize plugins later on this way
