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 正则规则引擎的选型考量

你需要一个规则引擎来管理和执行这些正则表达式。通常有几种选择：

1. 自行在应用层实现：如果你的应用是Python写的，直接用re模块；如果是Node.js，用RegExp对象。这是最轻量、最直接的方式，适合规则数量较少（几十条）、逻辑简单的场景。你需要自己处理规则的加载、排序、匹配逻辑和命中后的动作（拦截、记录、替换）。
2. 使用专门的规则引擎库：例如，有些安全中间件或WAF（Web应用防火墙）的规则引擎可以剥离出来使用。它们通常支持更复杂的规则逻辑（如组合条件、速率限制）、更高的性能和更好的管理界面。但引入复杂度也更高。
3. 集成到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.rmtree；os.remove作用于非预期路径。
• 正则设计思路：结合上下文匹配open和路径字符串。一个更稳健的方法是先提取代码中的字符串常量，再检查路径是否可疑。
  • 示例规则：匹配简单的路径遍历。

    open\s*\([^)]*\.\.\/[^)]*\)

    这个规则匹配open(后面括号内包含../的情况，但比较粗糙，可能误伤。

3. 网络访问与数据渗出防止模型生成的代码建立未经授权的网络连接，或向外发送数据。

• 模式特征：导入socket,urllib.request,requests,httpx等网络库；代码中出现http://、https://或IP地址连接；smtplib（可能用于发送邮件泄露数据）。
• 正则设计思路：匹配导入语句和URL字符串。对于IP，需要更精确的正则来匹配有效IP地址。
  • 示例规则：匹配requests导入和基础HTTP URL。

    \b(import\s+requests|from\s+requests|import\s+socket)\b |(https?://[^\s<>\"']+)

4. 敏感信息泄露模式模型可能在代码中硬编码密钥、令牌或内部信息。

• 模式特征：字符串中包含AKIA（AWS密钥前缀）、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,})\b

5. 代码混淆与绕过尝试攻击者（或模型在“对抗性提示”下）可能生成混淆代码来绕过简单规则。

• 模式特征：使用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 = r'subprocess\.(?:call|Popen|run|check_output)'

3. 谨慎使用.和*，避免灾难性回溯.*是“万恶之源”，容易导致性能灾难。尽量使用更精确的字符类[^)]*（匹配非右括号的字符）或\s*（匹配空白字符）来限定范围。

# 危险：可能因复杂的嵌套括号导致深度回溯 pattern = r'open\(.*\.\./.*\)' # 较好：限定匹配范围 pattern = r'open\([^)]*\.\./[^)]*\)'

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.yaml：

rules: - 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\s+socket|import\s+urllib|import\s+requests|from\s+requests)\b' context: "code_block" action: "block" severity: "high" description: "拦截网络库导入" - name: "dangerous_shell_command" pattern: r'\b(rm\s+-rf|chmod\s+777|format\s+\w:|curl\s+.*\s*\|\s*bash)\b' action: "block" severity: "critical" description: "拦截危险Shell命令字符串"

4.3 规则引擎核心实现

rule_engine.py：

import 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', encoding='utf-8') as f: config = yaml.safe_load(f) for rule_dict in config.get('rules', []): try: rule = SecurityRule( name=rule_dict['name'], pattern=rule_dict['pattern'], compiled_regex=None, # 由__post_init__处理 action=Action(rule_dict.get('action', 'block')), severity=rule_dict.get('severity', 'medium'), description=rule_dict.get('description', ''), context=MatchContext(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(key=lambda 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.py：

from fastapi import FastAPI, HTTPException, Request from pydantic import BaseModel import logging from rule_engine import RuleEngine app = FastAPI(title="LLM Sandbox with Security Filter") rule_engine = RuleEngine("config.yaml") logging.basicConfig(level=logging.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脚本：\n```python\nimport os\ndata = os.listdir('.')\nprint(data)\n```", "我可以帮你删除临时文件：`rm -rf /tmp/*`", "你的API密钥是：sk-live-abc123def456ghi789jkl012。请保管好。", "要连接数据库，你可以使用这个代码：\n```python\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_code=400, 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_code=500, detail="LLM服务暂时不可用") # 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_code=403, 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, host="0.0.0.0", port=8000)

4.5 运行与测试

1. 安装依赖：pip install fastapi uvicorn pyyaml
2. 将上面的代码文件保存到相应位置。
3. 运行服务：python main.py
4. 使用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密集型操作，规则多了、文本长了，性能瓶颈就来了。

1. 规则预编译：我们已经在上面的SecurityRule类中通过__post_init__预编译了正则表达式，这是最重要的优化。
2. 规则排序与短路：将最可能命中、最严重的规则（如eval,os.system）放在规则列表前面。在scan方法中，一旦发现一个BLOCK级别的匹配，可以立即返回结果，不再继续扫描剩余规则（除非你需要收集所有违规信息用于审计）。这可以通过在循环中添加检查来实现。
3. 分上下文扫描：我们已经在scan方法中实现了按上下文（全部、仅代码块、仅纯文本）扫描。这能显著减少不必要的匹配尝试。例如，匹配import socket的规则只应在代码块中应用，避免在讨论网络的文章中误报。
4. 对超长文本采样或分段：如果LLM可能生成极长的文本（如一篇论文），可以对超出一定长度的部分进行采样检查，或者分段进行匹配，避免单次匹配消耗过多时间。
5. 异步与非阻塞：将扫描操作放在异步任务或单独的线程池中执行，避免阻塞主请求线程。对于实时性要求不极高的场景，甚至可以引入一个轻量级队列。
6. 定期性能剖析：使用cProfile等工具定期分析scan函数的性能，找出最耗时的规则并进行优化或拆分。

5.2 误报（False Positive）处理实战

误报是安全系统的天敌，会严重影响用户体验。以下是我处理误报的流程：

1. 建立误报收集通道：所有被拦截的请求，其原始输入、LLM输出、匹配的规则和内容，都必须详细记录到日志或特定数据库中，并打上false_positive待审查标签。
2. 案例分析：定期审查误报案例。例如，规则path_traversal（匹配../）可能拦截了包含“请参考上一级目录（../）下的文档”的自然语言描述。这不是代码，不应被拦截。
3. 规则精细化：
   • 添加上下文限制：将上述规则从context: all改为context: code_block。
   • 调整模式边界：如果规则\brm\b误伤了单词 “program”，可以修改为\brm\s+-rf\b或\brm\s+-[rf]来更精确地匹配命令。
   • 添加白名单：对于某些在特定上下文中安全的模式，可以建立白名单。例如，在代码块中匹配到open(“../legit_config.json”)可能是业务需要，可以添加一条白名单规则，当文件路径是特定的安全列表时放行。白名单需极其谨慎使用。
4. 引入置信度评分：不要简单地“是/否”拦截。可以为每次匹配计算一个置信度分数（基于匹配的完整度、上下文、其他规则的协同匹配等）。低置信度的告警只记录不拦截，高置信度的才阻断。
5. 人工复核队列：对于置信度中等、或触发了重要但不紧急规则的请求，可以进入一个“待人工复核”队列，先返回一个“内容正在安全检查”的提示，待管理员确认后再将结果返回给用户。这适合对延迟不敏感的内部系统。

5.3 规则维护与更新流程

安全是持续的过程，规则库需要像杀毒软件病毒库一样更新。

1. 变更管理：任何规则的增、删、改，都必须经过评审和测试。使用版本控制（如Git）管理config.yaml文件。
2. 测试套件：建立一个包含大量样本的测试文件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: "代码块中导入网络库"

3. 自动化更新：可以设置一个定时任务，从内部威胁情报平台或经过严格审核的社区规则库拉取新的规则模式，但必须经过测试才能上线生产环境。
4. 监控与告警：监控规则引擎的拦截率、误报率、平均扫描时间。如果某个规则的误报率突然飙升，或拦截率骤降，需要立即触发告警，通知安全人员检查。

6. 进阶话题：绕过技术与防御升级

道高一尺，魔高一丈。攻击者（或诱导下的LLM）会尝试绕过你的正则过滤器。

6.1 常见绕过手法

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’)（十六进制编码）
2. 使用非常用函数或属性：
   • os.popen(‘ls’)（如果规则只拦了os.system）
   • subprocess.getoutput(‘ls’)
   • (lambda: __import__(‘os’).system(‘ls’))()（匿名函数包装）
3. 注释与空白符干扰：
   • os. system(‘ls’)（函数名和括号间加空格）
   • eval#comment\n(‘code’)
4. 利用沙盒环境本身特性：如果沙盒允许某些模块，攻击者可能利用它们进行间接攻击，如利用pickle反序列化、ctypes调用本地库等。

6.2 防御升级策略

1. 正则规则强化：
   • 规范化输入：在匹配前，对代码进行简单的规范化处理，比如移除字符串中的加号（‘im’ + ‘port’->‘import’）、解码简单的十六进制/Unicode转义。注意：这本身可能引入复杂性，且可能被更高级的混淆绕过。
   • 匹配“危险模式”而非精确字符串：例如，匹配任何__import__调用，无论其参数如何拼接。规则可以写成r’__import__\s*\(’。
   • 组合规则：一条规则匹配eval，另一条规则匹配__import__，再一条规则匹配system。当这些模式在近距离内（比如同一行或同一个代码块）同时出现时，置信度大大提高。
2. 引入抽象语法树分析：这是对抗代码混淆的终极武器之一。将代码块解析成AST（抽象语法树），然后遍历AST节点。
   • 检测危险调用：检查是否有Call节点，其函数名是eval,exec,os.system,subprocess.Popen等。
   • 检测危险导入：检查Import或ImportFrom节点，看是否导入了黑名单模块。
   • 检测属性访问：检查是否有访问os.system这样的属性。
   • 优势：AST分析不受字符串拼接、简单编码和空白符干扰的影响。‘__im’ + ‘port__(“os”)’在AST层面仍然是__import__函数调用。
   • 劣势：实现更复杂，性能开销比正则大，且只能用于语法正确的代码片段。对于自然语言中夹杂的代码片段，提取和解析可能失败。
3. 语义分析（高级）：理解代码的意图。例如，检测代码是否试图访问文件系统、网络、环境变量，无论它使用了什么具体的函数或语法。这需要更复杂的程序分析技术，如数据流分析，通常用于专业的安全产品中。
4. 多层沙盒与运行时限制：正则和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分析等更强大的静态分析手段，才能构建起一道真正有效的防线。记住，你的对手不仅是潜在的恶意用户，更可能是“一本正经”地生成危险代码的大模型本身。保持警惕，持续迭代，是守护应用安全的唯一途径。