如何净化任意代码防范恶意攻击？针对支持C#脚本的C++程序

Great question—this is a common challenge when building extensible apps that let users run custom code. Let’s break down the key strategies to lock down your C++/.NET hybrid app and reduce attack surface:

1. Sandbox Script Execution with .NET Permission Restrictions #

.NET gives you tools to isolate untrusted code from your main application and system resources:

• For .NET Framework: Use Code Access Security (CAS) to create a restricted permission set—grant only the bare minimum needed (like Execution permission) and block access to file system, network, reflection, and unsafe code.
• For .NET Core/.NET 5+: Use AssemblyLoadContext to load the script’s assembly in an isolated context, paired with PermissionSet to explicitly deny dangerous permissions. You can also spin up a separate AppDomain (though it’s less common in modern .NET) to contain the script.

2. Static Code Analysis with a Strict Allowlist #

Before executing any script, parse and validate its syntax tree to block dangerous constructs:

• Use Roslyn’s CSharpSyntaxTree to walk through every part of the user’s code:
  • Block forbidden keywords: unsafe, fixed, extern, and direct calls to high-risk namespaces like System.IO, System.Net, System.Reflection, or System.Diagnostics.
  • Only allow calls to your app’s pre-approved API surface—any attempt to call external methods not on your allowlist gets rejected.
• Build a custom Roslyn analyzer to enforce these rules during the script’s compilation phase, catching bad code before it ever runs.

3. Runtime Isolation & Monitoring #

Even with static checks, runtime safeguards add a critical layer of defense:

• Run scripts in a separate, low-privilege process instead of your main C++ app’s process. If the script misbehaves (e.g., spikes CPU, tries to access restricted resources), you can terminate the child process without crashing your main app.
• Set strict timeouts for script execution to prevent infinite loops or resource exhaustion.
• Restrict file system access to a dedicated, isolated working directory—never let scripts read/write outside of this sandboxed folder.

4. Secure Script Serialization & Validation #

When saving/loading user scripts, protect against tampering and injection:

• Sign saved scripts with a cryptographic hash (like SHA-256) tied to the user’s session or app instance. When loading, verify the hash to ensure the script hasn’t been modified with malicious code.
• For compiled scripts, use strong-named assemblies to enforce integrity checks during loading.

5. Enforce the Principle of Least Privilege #

This is non-negotiable for reducing risk:

• Run your entire application (and the script execution context) as a low-privilege user account—never use admin rights unless absolutely necessary.
• Trim your exposed API to only what users need to customize functionality. For example, if users only need to modify UI behavior, don’t give them access to system-level APIs.

A final note: There’s no way to eliminate risk entirely—if a user intentionally writes code to harm their own machine, some safeguards might be bypassed. Be sure to add clear warnings in your app about the risks of running custom scripts, so users understand what they’re getting into.

内容的提问来源于stack exchange，提问作者Tyson