Markdown 本身是一种轻量级标记语言，设计初衷是纯文本格式化，不具备代码执行能力。因此，标准的 Markdown 语法本身无法直接对网站完成注入攻击。
但是，在实际的 Web 应用场景中，如果开发者处理不当，Markdown 可以成为注入攻击的载体或入口。这通常不是 Markdown 的问题，而是解析器、渲染器或后端处理逻辑的安全缺陷导致的。
以下是 Markdown 可能引发安全风险的几种主要场景：
1. XSS（跨站脚本攻击）
这是最常见的风险。许多 Markdown 解析器允许嵌入原始 HTML 标签。
- 风险点： 如果解析器没有对用户输入的 Markdown 内容进行严格的消毒（Sanitization），攻击者可以在 Markdown 中写入
<script>alert(1)</script>或<img src=x onerror=alert(1)>等恶意代码。 - 结果： 当其他用户浏览该页面时，恶意脚本会在其浏览器中执行。
- 注意： 即使禁用了 HTML 标签，某些解析器的 Bug 也可能导致通过特殊 Markdown 语法绕过过滤实现 XSS。
2. 服务端模板注入 / 代码执行
部分应用支持在 Markdown 中使用扩展语法来动态生成内容。
- 风险点： 如果使用了不安全的插件或自定义渲染逻辑（例如允许在 Markdown 中嵌入 Jinja2、Liquid、EJS 等模板语法，或者允许执行 Lua/Python 脚本），且未做沙箱隔离。
- 结果： 攻击者可以通过构造特殊的 Markdown 内容，在服务端执行任意代码（RCE）。
3. SSRF（服务端请求伪造）与 DoS
- 图片/链接引用： Markdown 支持
[图片描述](https://)语法。如果服务端在渲染时会主动去请求该 URL（例如为了生成缩略图、预览或验证链接），攻击者可利用此特性探测内网或发起 SSRF 攻击。 - ReDoS（正则拒绝服务）： 一些老旧或编写不规范的 Markdown 解析器在处理特定畸形语法时，可能触发正则表达式的灾难性回溯，导致服务器 CPU 耗尽。
⚠️ 关键区分
Markdown ≠ 注入工具 SQL 注入、命令注入等漏洞的根源在于后端代码未对输入进行参数化处理或过滤。无论用户输入的是纯文本、JSON、XML 还是 Markdown，只要后端拼接了字符串，就可能被注入。Markdown 只是改变了"输入的形式"，并没有改变"注入的本质"。
✅ 安全建议
如果你在网站中使用 Markdown 功能，请务必采取以下措施：
- 使用成熟、维护良好的解析库（如 marked + DOMPurify, markdown-it + sanitize-html, Python 的 bleach 等）。
- 始终对输出进行 HTML 消毒，不要信任任何用户生成的 Markdown 渲染结果。
- 禁用不必要的扩展，特别是涉及代码执行、模板渲染或远程资源加载的功能。
- 配置 CSP（内容安全策略） 作为纵深防御，限制内联脚本的执行。
- 服务端渲染时做好超时和资源限制，防止 ReDoS 和 SSRF。
总结： Markdown 本身不能注入网站，但不安全地实现 Markdown 功能可以为攻击者提供注入的途径。安全的关键在于正确的解析、严格的过滤和安全的架构设计。
发表评论