1. 项目概述为什么LLM沙盒需要“正则”这道安全门最近在折腾几个大语言模型的应用项目发现一个挺普遍但容易被忽视的问题当你把LLM的API开放出去或者让它在你的系统里自由生成代码、执行命令时它偶尔会“放飞自我”。比如你让它写个Python脚本处理数据它可能顺手给你生成一个包含os.system(rm -rf /)或者__import__(subprocess).call([curl, malicious-site])的代码块。这种“危险代码”一旦在沙盒环境里被误执行轻则数据泄露、文件被删重则可能成为攻击内网的跳板。这就是为什么我们需要在LLM沙盒Sandbox的安全策略里加上一道基于正则表达式的精准拦截防线。简单来说LLM沙盒安全策略中的正则表达式拦截核心任务不是“防住LLM本身”而是防住LLM可能生成的有害内容。它像一个高度可定制的内容过滤器部署在LLM输出和实际执行或存储、转发之间。通过编写特定的正则模式Pattern我们可以实时扫描模型返回的文本、代码、命令一旦匹配到预设的危险特征就立即触发拦截动作——可能是丢弃、替换、记录日志或者要求人工复核。这个需求在以下场景尤其强烈自动化代码补全与生成工具、AI辅助编程助手、聊天机器人中集成代码执行功能、企业内部知识库问答系统防止模型泄露敏感信息或生成恶意指令。如果你正在构建这类应用那么深度配置这套安全策略就不是“可选项”而是“必选项”。接下来我会结合我踩过的坑和实战经验拆解如何从零搭建这套系统让你不仅能配更能理解为什么要这么配。2. 安全策略整体架构与设计思路一套有效的LLM沙盒安全策略不能只依赖单一防线。正则表达式拦截是其中非常关键、且灵活性极高的一环但它需要被放置在正确的架构位置并与其他机制协同工作。2.1 核心防御层次纵深防御策略我的设计通常遵循一个四层纵深防御模型正则拦截主要工作在第二层和第三层。第一层输入净化与提示词工程。在请求发送给LLM之前对用户的输入进行清洗和约束。例如在提示词Prompt中明确加入“你是一个安全的助手禁止生成任何可能破坏系统、泄露隐私或访问外部网络的代码”等指令。同时对用户输入进行基础过滤比如移除或转义某些特殊字符。这一层是预防降低模型“想歪”的概率。第二层输出实时检测与拦截正则表达式主战场。这是本项目的核心。当LLM返回结果后在将结果返回给用户或交给执行引擎前进行实时内容扫描。我们编写一系列正则表达式规则对返回的完整文本或其中的代码块进行匹配。这一层追求的是精准和低延迟需要在毫秒级内做出“放行”或“拦截”的判断。第三层执行前静态分析与沙盒隔离。对于需要执行的代码如Python在第二层过滤后可以进一步进行静态代码分析AST解析检查是否有危险的导入如os,subprocess,socket、函数调用或属性访问。同时所有代码必须在严格受限的沙盒环境如Docker容器、seccomp限制的系统调用、无网络访问的运行时中执行。正则表达式在这一层可以作为补充快速匹配一些静态分析可能遗漏的、通过字符串拼接或混淆的恶意代码模式。第四层运行时监控与行为审计。即使代码被执行也需要监控其行为如文件系统的异常读写、网络连接尝试、进程创建等。一旦发现越权行为立即终止进程并告警。这一层的日志可以为优化第二层的正则规则提供宝贵数据。正则表达式拦截之所以重要是因为它部署在输出端能够直接针对LLM生成内容的文本特征进行防御且规则可读、可调、热更新方便非常适合应对快速变化的攻击模式。2.2 正则规则引擎的选型考量你需要一个规则引擎来管理和执行这些正则表达式。通常有几种选择自行在应用层实现如果你的应用是Python写的直接用re模块如果是Node.js用RegExp对象。这是最轻量、最直接的方式适合规则数量较少几十条、逻辑简单的场景。你需要自己处理规则的加载、排序、匹配逻辑和命中后的动作拦截、记录、替换。使用专门的规则引擎库例如有些安全中间件或WAFWeb应用防火墙的规则引擎可以剥离出来使用。它们通常支持更复杂的规则逻辑如组合条件、速率限制、更高的性能和更好的管理界面。但引入复杂度也更高。集成到API网关或中间件如果你的LLM服务通过API提供可以在API网关如Kong, Apache APISIX或自定义的中间件中植入正则过滤逻辑。这样可以对所有流量进行统一管控与业务逻辑解耦。对于大多数从0到1的团队我建议从方案一开始。它简单、可控能让你快速理解核心问题。随着规则膨胀到上百条、性能成为瓶颈时再考虑迁移到更专业的引擎。本文的实操部分也将基于Pythonre模块展开但其思想是通用的。注意正则表达式的性能是关键。一条写得糟糕的、包含大量回溯的复杂正则可能让你的服务响应时间从几毫秒飙升到几百毫秒。设计规则时必须将性能作为首要考量之一。3. 危险代码模式分析与正则规则设计设计拦截规则的前提是你知道要拦截什么。我们不能盲目地拦截所有“看起来危险”的字符那样会误伤大量正常请求比如一篇讨论黑客技术的文章。我们的目标是高精度地识别出在LLM生成内容中可能被用于恶意执行的代码或指令模式。3.1 常见危险代码模式分类根据我的经验可以将危险模式分为以下几类并针对每一类设计正则表达式1. 系统命令执行高危这是最直接的威胁意图在宿主或沙盒内执行任意命令。模式特征调用os.system,subprocess.call/Popen,commands.getoutput等函数包含反引号 ...某些Shell下的命令替换直接出现rm -rf,format C:curl | bash等危险命令字符串。正则设计思路匹配这些特定的函数名、模块导入语句和命令字符串。注意攻击者可能会用空格、换行或拼接字符串来绕过简单匹配。示例规则Python匹配subprocess调用。\b(subprocess\.(call|Popen|run|check_output)\s*\(|os\.system\s*\()这个规则匹配以单词边界开始的subprocess.call(、subprocess.Popen(等或者os.system(。2. 文件系统危险操作包括任意文件读取、写入、删除特别是路径遍历攻击。模式特征open()函数调用中包含../路径遍历、/etc/passwd敏感文件、/tmp下可疑文件shutil.rmtreeos.remove作用于非预期路径。正则设计思路结合上下文匹配open和路径字符串。一个更稳健的方法是先提取代码中的字符串常量再检查路径是否可疑。示例规则匹配简单的路径遍历。open\s*\([^)]*\.\.\/[^)]*\)这个规则匹配open(后面括号内包含../的情况但比较粗糙可能误伤。3. 网络访问与数据渗出防止模型生成的代码建立未经授权的网络连接或向外发送数据。模式特征导入socket,urllib.request,requests,httpx等网络库代码中出现http://、https://或IP地址连接smtplib可能用于发送邮件泄露数据。正则设计思路匹配导入语句和URL字符串。对于IP需要更精确的正则来匹配有效IP地址。示例规则匹配requests导入和基础HTTP URL。\b(import\srequests|from\srequests|import\ssocket)\b |(https?://[^\s\])4. 敏感信息泄露模式模型可能在代码中硬编码密钥、令牌或内部信息。模式特征字符串中包含AKIAAWS密钥前缀、sk-某些API密钥、Bearer、password,secret_key等模式。正则设计思路使用高精度的关键词匹配通常配合字符串常量提取。示例规则匹配常见的密钥模式。\b(AKIA[0-9A-Z]{16}|sk-[a-zA-Z0-9]{20,}|Bearer\s[a-zA-Z0-9._-]{20,})\b5. 代码混淆与绕过尝试攻击者或模型在“对抗性提示”下可能生成混淆代码来绕过简单规则。模式特征使用eval(),exec(),compile()执行动态代码使用getattr(),__import__()进行动态导入字符串拼接如os .system十六进制或Unicode转义字符。正则设计思路这是最困难的部分。需要匹配这些高危函数本身同时规则引擎可能需要具备一定的“解码”能力或者使用更复杂的、能容忍一定混淆的正则。示例规则匹配基础的eval和exec。\b(eval|exec|compile)\s*\(应对拼接一个初步的防御是在匹配前可以对代码进行简单的“规范化”比如移除字符串中的加号风险高需谨慎或者使用抽象语法树AST分析这超出了纯正则的范畴。3.2 正则表达式编写的高级技巧与避坑指南直接写死字符串匹配是行不通的。你需要掌握一些技巧来提升规则的鲁棒性和性能。1. 使用原始字符串Raw String和单词边界在Python中正则模式字符串前加r如r\bimport\b。\b确保匹配的是完整的单词“import”而不是“importing”的一部分。这能减少大量误报。2. 非捕获组与性能优化如果你需要分组但不需提取内容使用(?:...)非捕获组它比捕获组(...)性能更好。# 较差 pattern r(subprocess\.(call|Popen)) # 较好 pattern rsubprocess\.(?:call|Popen|run|check_output)3. 谨慎使用.和*避免灾难性回溯.*是“万恶之源”容易导致性能灾难。尽量使用更精确的字符类[^)]*匹配非右括号的字符或\s*匹配空白字符来限定范围。# 危险可能因复杂的嵌套括号导致深度回溯 pattern ropen\(.*\.\./.*\) # 较好限定匹配范围 pattern ropen\([^)]*\.\./[^)]*\)4. 规则排序与短路匹配将最可能命中、最危险的规则放在前面。一旦某条规则命中后续规则可能无需检查取决于你的拦截逻辑。例如先检查eval(再检查os.system。5. 区分代码块与普通文本LLM的回复可能混合了自然语言和代码块用 包裹。一个有效的策略是先提取出所有代码块然后只对代码块应用最严格的正则规则集对自然语言部分应用另一套较宽松的、主要针对明显攻击指令的规则集。这能大幅降低误报率。6. 定期维护与测试安全规则不是一劳永逸的。你需要收集误报样本所有被拦截的正常请求都要记录并分析调整规则以避免再次误伤。收集漏报样本通过日志审计、红队测试或外部漏洞报告发现绕过规则的危险样本据此补充新规则。性能测试用真实流量或模拟流量对规则集进行压测确保不会引入不可接受的延迟。4. 基于Python的拦截系统实战实现下面我将展示一个最小化但功能完整的LLM输出拦截器实现。它包含规则管理、内容扫描、拦截处理等核心模块。4.1 项目结构与依赖假设我们有一个简单的FastAPI应用它接收用户请求调用LLM API然后对返回内容进行安全检查最后返回给用户。llm_sandbox_filter/ ├── config.yaml # 规则配置文件 ├── rule_engine.py # 规则引擎核心类 ├── main.py # FastAPI主应用 └── test_inputs.txt # 测试用例我们主要依赖re正则和yaml配置解析。4.2 规则配置文件设计我们将规则定义在YAML文件中便于管理和热更新。config.yamlrules: - name: dangerous_system_command pattern: r\b(os\.system|subprocess\.(call|Popen|run|check_output)|exec\s*\(|eval\s*\()\s*\( action: block # block, alert, replace severity: critical description: 拦截系统命令执行和动态代码执行函数 - name: path_traversal pattern: r\.\./|\.\.\\ context: code_block # 仅应用于代码块 action: block severity: high description: 拦截路径遍历符在代码块中 - name: hardcoded_secret_pattern pattern: r\b(AKIA[0-9A-Z]{16}|sk-[a-zA-Z0-9]{20,}|Bearer\s[a-zA-Z0-9._-]{20,})\b action: alert # 不直接阻断但记录高危日志 severity: high description: 疑似硬编码的云密钥或Bearer令牌 - name: network_import pattern: r\b(import\ssocket|import\surllib|import\srequests|from\srequests)\b context: code_block action: block severity: high description: 拦截网络库导入 - name: dangerous_shell_command pattern: r\b(rm\s-rf|chmod\s777|format\s\w:|curl\s.*\s*\|\s*bash)\b action: block severity: critical description: 拦截危险Shell命令字符串4.3 规则引擎核心实现rule_engine.pyimport re import yaml from typing import List, Dict, Any, Optional, Tuple from dataclasses import dataclass from enum import Enum class Action(Enum): BLOCK block ALERT alert REPLACE replace class MatchContext(Enum): ALL all # 匹配全部文本 CODE_BLOCK code_block # 仅匹配代码块 PLAIN_TEXT plain_text # 仅匹配非代码文本 dataclass class SecurityRule: name: str pattern: str compiled_regex: re.Pattern action: Action severity: str description: str context: MatchContext def __post_init__(self): # 预编译正则表达式提升性能 try: self.compiled_regex re.compile(self.pattern, re.IGNORECASE | re.MULTILINE) except re.error as e: raise ValueError(f无效的正则表达式 {self.pattern} 在规则 {self.name}: {e}) class RuleEngine: def __init__(self, rule_config_path: str): self.rules: List[SecurityRule] [] self.load_rules(rule_config_path) def load_rules(self, config_path: str): 从YAML文件加载规则 with open(config_path, r, encodingutf-8) as f: config yaml.safe_load(f) for rule_dict in config.get(rules, []): try: rule SecurityRule( namerule_dict[name], patternrule_dict[pattern], compiled_regexNone, # 由__post_init__处理 actionAction(rule_dict.get(action, block)), severityrule_dict.get(severity, medium), descriptionrule_dict.get(description, ), contextMatchContext(rule_dict.get(context, all)) ) self.rules.append(rule) except KeyError as e: print(f警告规则配置缺少必要字段 {e}已跳过) except ValueError as e: print(f警告规则 {rule_dict.get(name)} 初始化失败: {e}) def _extract_code_blocks(self, text: str) - List[Tuple[int, int, str]]: 提取Markdown代码块的位置和内容。返回列表元素为(start, end, code_text) code_blocks [] # 匹配 language ... 或 ... pattern r(?:\w)?\n(.*?) for match in re.finditer(pattern, text, re.DOTALL): start, end match.span(1) # 只取代码内容部分的范围 code_blocks.append((start, end, match.group(1))) return code_blocks def scan(self, text: str) - List[Dict[str, Any]]: 扫描文本返回匹配到的规则信息列表。 每个匹配项是一个字典包含规则名、匹配内容、位置、严重性等。 findings [] code_blocks self._extract_code_blocks(text) for rule in self.rules: # 根据规则上下文决定扫描范围 if rule.context MatchContext.ALL: search_text text offset_adjust 0 elif rule.context MatchContext.CODE_BLOCK: # 只扫描所有代码块拼接起来的内容 search_text \n---CODE_BLOCK_DELIMITER---\n.join([cb[2] for cb in code_blocks]) if not search_text: continue offset_adjust None # 位置计算复杂暂时简化 else: # PLAIN_TEXT # 从原始文本中移除代码块部分形成纯文本 plain_text_parts [] last_end 0 for start, end, _ in code_blocks: plain_text_parts.append(text[last_end:start]) last_end end plain_text_parts.append(text[last_end:]) search_text .join(plain_text_parts) offset_adjust None # 执行正则匹配 for match in rule.compiled_regex.finditer(search_text): # 简化处理记录规则信息和匹配到的字符串 # 在实际生产中这里需要更精确的位置映射特别是对于CODE_BLOCK和PLAIN_TEXT上下文 findings.append({ rule_name: rule.name, matched_string: match.group(), start_pos: match.start(), end_pos: match.end(), severity: rule.severity, action: rule.action.value, description: rule.description }) # 如果规则动作是BLOCK可以提前返回避免不必要的后续扫描 if rule.action Action.BLOCK: # 这里我们继续扫描以收集所有违规但实际拦截逻辑可根据需求调整 pass # 按严重性排序critical high medium low severity_order {critical: 0, high: 1, medium: 2, low: 3} findings.sort(keylambda x: severity_order.get(x[severity], 4)) return findings def should_block(self, findings: List[Dict[str, Any]]) - bool: 根据扫描结果判断是否应该阻断本次请求 return any(finding[action] block for finding in findings)4.4 集成到LLM服务中main.pyfrom fastapi import FastAPI, HTTPException, Request from pydantic import BaseModel import logging from rule_engine import RuleEngine app FastAPI(titleLLM Sandbox with Security Filter) rule_engine RuleEngine(config.yaml) logging.basicConfig(levellogging.INFO, format%(asctime)s - %(name)s - %(levelname)s - %(message)s) logger logging.getLogger(__name__) # 模拟调用LLM API的函数 async def call_llm_api(prompt: str) - str: # 这里替换成你真实的LLM API调用例如OpenAI, Anthropic等 # 模拟返回 simulated_responses [ 好的这是你要的Python脚本\npython\nimport os\ndata os.listdir(.)\nprint(data)\n, 我可以帮你删除临时文件rm -rf /tmp/*, 你的API密钥是sk-live-abc123def456ghi789jkl012。请保管好。, 要连接数据库你可以使用这个代码\npython\nimport sqlite3\nconn sqlite3.connect(data.db)\n ] import random return random.choice(simulated_responses) class LLMRequest(BaseModel): prompt: str max_tokens: int 500 app.post(/v1/chat/completions) async def chat_completion(request: LLMRequest): 处理用户请求调用LLM并执行安全过滤。 # 1. 可选对用户输入prompt进行基础安全检查 # input_findings rule_engine.scan(request.prompt) # if rule_engine.should_block(input_findings): # raise HTTPException(status_code400, detail输入包含不安全内容) # 2. 调用LLM try: llm_response await call_llm_api(request.prompt) except Exception as e: logger.error(f调用LLM API失败: {e}) raise HTTPException(status_code500, detailLLM服务暂时不可用) # 3. 对LLM输出进行安全扫描 findings rule_engine.scan(llm_response) logger.info(f安全扫描结果: {findings}) # 4. 根据扫描结果决定动作 if rule_engine.should_block(findings): logger.warning(f请求被阻断。原因: {[f[rule_name] for f in findings if f[action]block]}) # 可以选择返回一个安全的默认回复或者直接报错 safe_response 抱歉我的回复中包含被安全策略禁止的内容。请尝试换一种方式提问。 # 或者抛出异常 # raise HTTPException(status_code403, detail响应内容违反安全策略) return {choices: [{message: {content: safe_response}}]} # 5. 对于非阻断的告警记录日志但放行响应 for finding in findings: if finding[action] alert: logger.warning(f安全告警 - 规则[{finding[rule_name]}]: 匹配到 {finding[matched_string][:50]}...) # 6. 返回安全的响应 return {choices: [{message: {content: llm_response}}]} if __name__ __main__: import uvicorn uvicorn.run(app, host0.0.0.0, port8000)4.5 运行与测试安装依赖pip install fastapi uvicorn pyyaml将上面的代码文件保存到相应位置。运行服务python main.py使用curl或 Postman 进行测试curl -X POST http://localhost:8000/v1/chat/completions \ -H Content-Type: application/json \ -d {prompt: 帮我写一个删除临时文件的Python脚本}观察服务日志你会看到类似这样的输出INFO:root:安全扫描结果: [{rule_name: dangerous_shell_command, matched_string: rm -rf, ...}] WARNING:root:请求被阻断。原因: [dangerous_shell_command]客户端将收到我们预设的安全回复而不是包含rm -rf的原始内容。5. 性能优化、误报处理与规则维护实战系统跑起来只是第一步让它跑得稳、准、狠才是真正的挑战。5.1 性能优化技巧正则匹配是CPU密集型操作规则多了、文本长了性能瓶颈就来了。规则预编译我们已经在上面的SecurityRule类中通过__post_init__预编译了正则表达式这是最重要的优化。规则排序与短路将最可能命中、最严重的规则如eval,os.system放在规则列表前面。在scan方法中一旦发现一个BLOCK级别的匹配可以立即返回结果不再继续扫描剩余规则除非你需要收集所有违规信息用于审计。这可以通过在循环中添加检查来实现。分上下文扫描我们已经在scan方法中实现了按上下文全部、仅代码块、仅纯文本扫描。这能显著减少不必要的匹配尝试。例如匹配import socket的规则只应在代码块中应用避免在讨论网络的文章中误报。对超长文本采样或分段如果LLM可能生成极长的文本如一篇论文可以对超出一定长度的部分进行采样检查或者分段进行匹配避免单次匹配消耗过多时间。异步与非阻塞将扫描操作放在异步任务或单独的线程池中执行避免阻塞主请求线程。对于实时性要求不极高的场景甚至可以引入一个轻量级队列。定期性能剖析使用cProfile等工具定期分析scan函数的性能找出最耗时的规则并进行优化或拆分。5.2 误报False Positive处理实战误报是安全系统的天敌会严重影响用户体验。以下是我处理误报的流程建立误报收集通道所有被拦截的请求其原始输入、LLM输出、匹配的规则和内容都必须详细记录到日志或特定数据库中并打上false_positive待审查标签。案例分析定期审查误报案例。例如规则path_traversal匹配../可能拦截了包含“请参考上一级目录../下的文档”的自然语言描述。这不是代码不应被拦截。规则精细化添加上下文限制将上述规则从context: all改为context: code_block。调整模式边界如果规则\brm\b误伤了单词 “program”可以修改为\brm\s-rf\b或\brm\s-[rf]来更精确地匹配命令。添加白名单对于某些在特定上下文中安全的模式可以建立白名单。例如在代码块中匹配到open(“../legit_config.json”)可能是业务需要可以添加一条白名单规则当文件路径是特定的安全列表时放行。白名单需极其谨慎使用。引入置信度评分不要简单地“是/否”拦截。可以为每次匹配计算一个置信度分数基于匹配的完整度、上下文、其他规则的协同匹配等。低置信度的告警只记录不拦截高置信度的才阻断。人工复核队列对于置信度中等、或触发了重要但不紧急规则的请求可以进入一个“待人工复核”队列先返回一个“内容正在安全检查”的提示待管理员确认后再将结果返回给用户。这适合对延迟不敏感的内部系统。5.3 规则维护与更新流程安全是持续的过程规则库需要像杀毒软件病毒库一样更新。变更管理任何规则的增、删、改都必须经过评审和测试。使用版本控制如Git管理config.yaml文件。测试套件建立一个包含大量样本的测试文件test_inputs.txt里面既有已知的攻击样本确保能拦截也有大量的正常业务样本确保不误报。每次规则变更后运行测试套件确保拦截率和误报率在可接受范围内。# 测试用例格式示例 (可扩展为JSON等) - input: import os\nos.system(ls) expected_action: block reason: 直接系统调用 - input: 这篇文章讨论了../目录结构。 expected_action: pass reason: 自然语言描述非代码 - input: python\nimport requests\nresp requests.get(http://example.com)\n expected_action: block reason: 代码块中导入网络库自动化更新可以设置一个定时任务从内部威胁情报平台或经过严格审核的社区规则库拉取新的规则模式但必须经过测试才能上线生产环境。监控与告警监控规则引擎的拦截率、误报率、平均扫描时间。如果某个规则的误报率突然飙升或拦截率骤降需要立即触发告警通知安全人员检查。6. 进阶话题绕过技术与防御升级道高一尺魔高一丈。攻击者或诱导下的LLM会尝试绕过你的正则过滤器。6.1 常见绕过手法字符串拼接与编码‘im’ ‘port os’eval(‘__im’ ‘port__(“os”).system(“ls”)’)exec(‘\\x5f\\x5f\\x69\\x6d\\x70\\x6f\\x72\\x74\\x5f\\x5f\\x28\\x22\\x6f\\x73\\x22\\x29’)十六进制编码使用非常用函数或属性os.popen(‘ls’)如果规则只拦了os.systemsubprocess.getoutput(‘ls’)(lambda: __import__(‘os’).system(‘ls’))()匿名函数包装注释与空白符干扰os. system(‘ls’)函数名和括号间加空格eval#comment\n(‘code’)利用沙盒环境本身特性如果沙盒允许某些模块攻击者可能利用它们进行间接攻击如利用pickle反序列化、ctypes调用本地库等。6.2 防御升级策略正则规则强化规范化输入在匹配前对代码进行简单的规范化处理比如移除字符串中的加号‘im’ ‘port’-‘import’、解码简单的十六进制/Unicode转义。注意这本身可能引入复杂性且可能被更高级的混淆绕过。匹配“危险模式”而非精确字符串例如匹配任何__import__调用无论其参数如何拼接。规则可以写成r’__import__\s*\(’。组合规则一条规则匹配eval另一条规则匹配__import__再一条规则匹配system。当这些模式在近距离内比如同一行或同一个代码块同时出现时置信度大大提高。引入抽象语法树分析这是对抗代码混淆的终极武器之一。将代码块解析成AST抽象语法树然后遍历AST节点。检测危险调用检查是否有Call节点其函数名是eval,exec,os.system,subprocess.Popen等。检测危险导入检查Import或ImportFrom节点看是否导入了黑名单模块。检测属性访问检查是否有访问os.system这样的属性。优势AST分析不受字符串拼接、简单编码和空白符干扰的影响。‘__im’ ‘port__(“os”)’在AST层面仍然是__import__函数调用。劣势实现更复杂性能开销比正则大且只能用于语法正确的代码片段。对于自然语言中夹杂的代码片段提取和解析可能失败。语义分析高级理解代码的意图。例如检测代码是否试图访问文件系统、网络、环境变量无论它使用了什么具体的函数或语法。这需要更复杂的程序分析技术如数据流分析通常用于专业的安全产品中。多层沙盒与运行时限制正则和AST是静态分析最终极的防御是动态的运行时限制。即使恶意代码通过了所有静态检查也要确保它在极度受限的沙盒中运行无网络、只读文件系统或仅限特定目录、严格限制的系统调用通过seccomp、资源配额CPU、内存。这样即使代码被执行其破坏力也被限制在沙盒内。6.3 一个结合正则与AST的混合方案示例你可以将正则作为第一道快速过滤网AST作为第二道精确分析网。import ast import re class HybridSecurityAnalyzer: def __init__(self, rule_engine): self.rule_engine rule_engine self.dangerous_funcs {eval, exec, compile, open, __import__} self.dangerous_attrs {(os, system), (subprocess, call), (subprocess, Popen)} def analyze_code_block(self, code: str) - List[Dict]: 分析一个代码块 findings [] # 第一层快速正则过滤 regex_findings self.rule_engine.scan(code) findings.extend(regex_findings) # 第二层AST深度分析 try: tree ast.parse(code) for node in ast.walk(tree): # 检查危险函数调用 if isinstance(node, ast.Call): if isinstance(node.func, ast.Name): if node.func.id in self.dangerous_funcs: findings.append({ type: AST, rule_name: dangerous_function_call, details: f调用了危险函数: {node.func.id}, severity: critical }) # 检查危险属性调用如 os.system elif isinstance(node.func, ast.Attribute): # 简化处理尝试解析属性访问的完整名称 # 实际中需要更复杂的逻辑来解析如 getattr(os, system) 的情况 module_name self._get_full_attr_name(node.func) if module_name in self.dangerous_attrs: findings.append({ type: AST, rule_name: dangerous_attribute_call, details: f调用了危险属性: {module_name}, severity: critical }) # 检查危险模块导入 elif isinstance(node, (ast.Import, ast.ImportFrom)): for alias in node.names: module_to_check alias.name if isinstance(node, ast.Import) else node.module if module_to_check in [os, subprocess, socket, shutil]: findings.append({ type: AST, rule_name: dangerous_import, details: f导入了危险模块: {module_to_check}, severity: high }) except SyntaxError: # 代码语法错误可能不是有效代码或者是我们提取的片段不完整 # 可以记录日志但主要依赖正则层的结果 pass return findings def _get_full_attr_name(self, node: ast.Attribute) - str: 递归获取属性访问的全名如 os.system parts [] while isinstance(node, ast.Attribute): parts.append(node.attr) node node.value if isinstance(node, ast.Name): parts.append(node.id) parts.reverse() return ..join(parts) if parts else 这个混合方案提供了更深度的防御。正则负责快速抓取明显的模式和文本特征AST则能洞察经过混淆的代码结构。在实际部署中你可以根据性能要求决定是否默认开启AST分析或者只对正则扫描出中低置信度告警的代码块进行AST分析。配置LLM沙盒的安全策略尤其是正则表达式拦截是一个在安全性、性能、用户体验之间不断权衡的艺术。没有一劳永逸的银弹。从一套基础规则开始结合细致的日志分析、持续的规则调优并逐步引入AST分析等更强大的静态分析手段才能构建起一道真正有效的防线。记住你的对手不仅是潜在的恶意用户更可能是“一本正经”地生成危险代码的大模型本身。保持警惕持续迭代是守护应用安全的唯一途径。