ASP.NET Core中安全执行用户提交的JS脚本实践

在低代码平台、自定义计算规则与 Webhook 转换管道中，服务端常需要执行由终端用户编写的 JavaScript 脚本。在 ASP.NET Core 应用程序中承接此类逻辑时，首要目标是在开放灵活语法的同时间接筑起安全防线，杜绝死循环耗尽 CPU 线程池、超大内存分配撑爆进程以及脚本逃逸读取主机系统资源。本文将围绕 .NET 生态中的主流执行方案，详细解析托管引擎与原生引擎的关键差异，并通过超时熔断、步数配额、内存限制与宿主隔离等机制，落地一套安全可控的执行实践。

一、架构选型：托管引擎与原生引擎的关键差异

在 .NET 平台运行 JavaScript 代码，常见做法分为两类：一类是完全使用 C# 开发的纯托管解释引擎（以 Jint 为代表）；另一类是封装底层 Google V8 引擎的原生互操作方案（以 Microsoft ClearScript 为代表）。两者的运行模型差异直接决定了安全边界的控制深度与维护成本。

对于绝大多数用户提交的规则计算与字段转换任务，代码复杂度相对固定、运行频次高但计算量小。采用纯托管引擎能够提供最具确定性的步数与内存拦截能力，且在 Linux Docker 容器中分发无需处理复杂的 glibc 与架构兼容性；若业务涉及高频重型数据运算，则 ClearScript 是更佳的高性能选择。下文将以安全可控性更精细的托管沙箱为核心展开工程实践。

二、四重沙箱防护策略与配置实现

为了防止恶意或低效脚本造成服务端瘫痪，构建脚本沙箱时必须同时施加时间、步数、内存和反射调用四道屏障。缺少任何一道屏障都会留下拒绝服务或提权漏洞。

1. 执行时间与步数熔断

死循环（如 while(true){}）或低效正则表达式会导致宿主线程被长时间占用。通过配置 TimeoutInterval 可以实现基于时间的强制中断；配合 MaxStatements 限制最大执行语句条数，可以在脚本陷入密集计算时提前触发异常，而无需等待物理定时器触发。

2. 内存硬上限拦截

恶意脚本可能通过构造超长字符串拼接或无线扩容大数组（例如 let a = []; while(true) a.push(new Array(10000));）耗尽宿主应用内存。在引擎选项中启用 LimitMemory，当沙箱分配的托管内存超过预设阈值（如 10MB）时即刻终止执行。

3. 严格禁止 CLR 互操作与反射

这是防止脚本逃逸最关键的一步。默认情况下，不要在沙箱中启用 CLR 互操作扩展（不要调用 AllowClr()）。一旦开放 CLR，脚本便能通过 System.IO.File 或 System.Diagnostics.Process 访问服务器本地硬盘和执行终端指令。上下文传递仅允许注入经过深拷贝的简单数据对象或原生 JS 基础类型。

4. 作用域生命周期独立

避免跨请求共用同一个引擎实例。全局变量的修改（如覆写 Array.prototype）会在不同请求间产生不可预料的状态污染。最佳实践是每次脚本调用均创建崭新的轻量实例，或者在单次执行后彻底重置环境。

三、ASP.NET Core 完整服务实现

在工程实现中，我们将脚本执行逻辑封装为独立的服务组件 IScriptExecutionService，提供标准化的输入输出契约与分级异常拦截。使用前通过 NuGet 引入 Jint 依赖包。

// 依赖项包安装
// dotnet add package Jint --version 3.0.0

以下为完整的沙箱服务实现代码，包含超时约束、语句配额、内存限额与详细异常分类：

using System;
using System.Text.Json;
using Jint;
using Jint.Runtime;

namespace SafeScripting.Services
{
    public interface IScriptExecutionService
    {
        ScriptExecutionResult Execute(string userScript, object inputContext);
    }

    public record ScriptExecutionResult(bool Success, object? Data, string? ErrorMessage);

    public class SafeScriptExecutionService : IScriptExecutionService
    {
        // 约束参数集中配置
        private const int MaxScriptLength = 8192; // 脚本最大字符数
        private const int MaxAllowedStatements = 3000; // 最多执行语句步数
        private const int MaxRecursionCallDepth = 32; // 递归调用深度
        private static readonly TimeSpan ExecutionTimeout = TimeSpan.FromMilliseconds(400); // 物理执行超时
        private const long MemoryLimitInBytes = 8 * 1024 * 1024; // 8MB 内存上限

        public ScriptExecutionResult Execute(string userScript, object inputContext)
        {
            // 1. 前置防线：校验输入长度
            if (string.IsNullOrWhiteSpace(userScript))
            {
                return new ScriptExecutionResult(false, null, "脚本内容不能为空。");
            }

            if (userScript.Length > MaxScriptLength)
            {
                return new ScriptExecutionResult(false, null, $"脚本长度超过上限 ({MaxScriptLength} 字符)。");
            }

            try
            {
                // 2. 构造轻量且受到严格安全边界保护的引擎实例
                using var engine = new Engine(options =>
                {
                    // 设置硬超时限制
                    options.TimeoutInterval(ExecutionTimeout);
                    // 限制最大可执行 AST 语句数，提前打断死循环
                    options.MaxStatements(MaxAllowedStatements);
                    // 限制函数递归层级，防止栈溢出
                    options.LimitRecursion(MaxRecursionCallDepth);
                    // 限制内存分配大小
                    options.LimitMemory(MemoryLimitInBytes);
                    // 严格不调用 options.AllowClr()，确保完全封锁 CLR 反射
                });

                // 3. 安全注入上下文：序列化为干净的 JSON 对象，切断潜在的 CLR 引用传递
                string jsonContext = JsonSerializer.Serialize(inputContext);
                engine.Execute($"const context = {jsonContext};");

                // 4. 执行用户脚本并获取返回结果
                var jsResult = engine.Evaluate(userScript);

                // 5. 将结果清洗并转换回 .NET 对象
                object? resultValue = jsResult.ToObject();
                return new ScriptExecutionResult(true, resultValue, null);
            }
            catch (TimeoutException)
            {
                return new ScriptExecutionResult(false, null, "脚本执行超时，已被沙箱强制熔断。");
            }
            catch (StatementsCountOverflowException)
            {
                return new ScriptExecutionResult(false, null, "脚本执行步骤超过最大配额限制。");
            }
            catch (MemoryLimitExceededException)
            {
                return new ScriptExecutionResult(false, null, "脚本内存分配超出限定范围。");
            }
            catch (JavaScriptException jsEx)
            {
                // 仅返回脚本内部抛出的错误消息，不泄露内部调用栈
                return new ScriptExecutionResult(false, null, $"脚本运行时错误: {jsEx.Message}");
            }
            catch (ParserException parseEx)
            {
                return new ScriptExecutionResult(false, null, $"脚本语法解析失败: {parseEx.Message}");
            }
            catch (Exception ex)
            {
                return new ScriptExecutionResult(false, null, $"系统执行异常: {ex.Message}");
            }
        }
    }
}

四、控制器接口集成与异常响应分流

在 ASP.NET Core 控制器中，需明确区分“系统级错误”与“脚本自身约束失败”。当用户脚本触发超时或语法错误时，属于业务维度的非法输入，应当返回 HTTP 400 或标准化业务错误体，而非引发 HTTP 500 服务器崩溃。

using Microsoft.AspNetCore.Mvc;
using SafeScripting.Services;

namespace SafeScripting.Controllers
{
    [ApiController]
    [Route("api/[controller]")]
    public class ScriptRunnerController : ControllerBase
    {
        private readonly IScriptExecutionService _scriptService;

        public ScriptRunnerController(IScriptExecutionService scriptService)
        {
            _scriptService = scriptService;
        }

        [HttpPost("execute")]
        public IActionResult RunScript([FromBody] RunScriptRequest request)
        {
            // 上下文示例数据
            var contextData = new
            {
                orderId = "ORD-2026-8801",
                amount = 250.0,
                userLevel = "VIP",
                itemsCount = 3
            };

            var executionResult = _scriptService.Execute(request.Script, contextData);

            if (!executionResult.Success)
            {
                return BadRequest(new
                {
                    status = "failed",
                    message = executionResult.ErrorMessage
                });
            }

            return Ok(new
            {
                status = "success",
                result = executionResult.Data
            });
        }
    }

    public record RunScriptRequest(string Script);
}

五、生产级高并发防护与治理建议

将用户脚本沙箱接入生产系统时，除单次调用的防护外，还需从全局系统韧性角度防范级联雪崩：

1. 线程池与并发背压控制

虽然每个沙箱均有超时机制（如 500ms），但在突发高并发攻击下，成百上千个陷入死循环的脚本并发执行，依然能在数百毫秒内抢占完 .NET CLR 线程池中的可用工作线程，导致其他常规 API 无法响应。因此，必须通过 SemaphoreSlim 或独立工作队列，对脚本并发执行线程数设置硬上限（例如限制最多并发运行 8 个脚本线程），超出并发上限时直接返回系统繁忙提示。

2. AST 预编译缓存

在很多业务场景中，同一份脚本规则会被频繁触发（如计算订单优惠）。重复的语法解析与 AST 构建会造成不必要的 CPU 消耗。可以使用 Jint 的 Script.Parse(script) 预编译成抽象语法树并缓存于内存字典中，执行时直接运行预编译后的 Script 实例，兼顾效率与安全性。

3. 返回结果的序列化清洗

脚本返回值可能被用户恶意篡改为包含特殊循环引用的对象。在将结果反序列化为 .NET 强类型前，必须确保递归解包逻辑受限，避免在结果解析阶段再度引发内存泄漏。

六、总结与落地建议

在 ASP.NET Core 应用中运行动态 JavaScript 脚本并不是必须承担安全风险的妥协做法。通过采用如 Jint 这样的纯托管沙箱，配合严密的执行步数限制、物理毫秒级超时熔断、内存配额隔离以及彻底的 CLR 反射封锁，可以在允许业务逻辑动态拓展的同时，完全消除脚本逃逸与资源枯竭的风险。在架构落地时，保持引擎无状态化与单次调用生命周期隔离，将异常清晰归类并在控制器层实施背压保护，是保障整个 Web 服务高可用与高安全性的关键基石。