基于Puppeteer的HTML转图片功能SSRF防护与安全隔离方案

一、Sidecar容器隔离Puppeteer/Chromium的可行性 #

完全可以通过Sidecar容器架构实现隔离，核心思路是将Node.js业务主进程与Chromium/Puppeteer渲染进程拆分到两个独立容器中：

• 通信机制：主容器通过HTTP API、gRPC或IPC管道向Sidecar容器发送渲染请求，Sidecar仅负责执行HTML渲染并返回缩略图结果，不直接接触业务数据库、队列等机密资源。
• 隔离强化：给Sidecar容器配置最小权限运行：
  • 以非root用户启动Chromium
  • 挂载只读文件系统（仅必要临时目录可写）
  • 限制CPU、内存配额，防止恶意脚本耗尽资源
  • 禁用容器的网络出站权限（或仅允许白名单域名），阻断恶意脚本向外泄露信息

即便攻击者利用浏览器漏洞攻陷Sidecar容器，也无法访问Node.js主容器内的环境变量、数据库凭证等敏感信息，攻击面被大幅压缩。

二、HTML转PDF同类服务商的通用防护方案 #

主流服务商的防护逻辑围绕「最小权限+沙箱隔离+资源管控」展开，典型措施包括：

• 多层沙箱防护：同时启用Chromium内置沙箱与操作系统级沙箱（如Linux的Seccomp、AppArmor），限制渲染进程的系统调用权限，即使浏览器漏洞被利用，也无法执行高危系统操作。
• 一次性环境销毁：每个渲染任务分配独立的临时进程或容器，任务完成后立即销毁环境，彻底避免跨任务的恶意代码残留与信息泄露。
• 内容与请求过滤：通过代理拦截恶意外部资源（如已知恶意域名、可疑脚本URL），限制脚本的跨域请求权限，同时伪造或隐藏navigator中的敏感系统字段（如真实浏览器版本、系统内核信息）。
• 严格资源配额：对每个任务设置执行时长、CPU使用率、内存上限，超过阈值直接终止进程，防止DoS攻击。
• 最小依赖镜像：容器仅安装Chromium运行必需的依赖，不包含bash、curl等额外工具，减少攻击者攻陷容器后的横向移动能力。

三、提升安全性的Chromium启动参数 #

以下是必须启用的核心安全参数，需配合容器隔离措施使用：

• --sandbox：强制启用Chromium沙箱（默认开启，若容器不支持setuid沙箱，可搭配--disable-setuid-sandbox）
• --disable-dev-shm-usage：避免使用/dev/shm共享内存，改用临时文件，减少共享内存攻击风险
• --disable-extensions：禁用所有浏览器扩展，消除扩展漏洞带来的攻击面
• --disable-plugins：禁用Flash等插件，彻底阻断插件相关攻击
• --disable-remote-fonts：禁止加载远程字体，防止恶意字体触发渲染引擎漏洞
• --incognito：以无痕模式启动，避免缓存、本地存储残留，防止跨任务信息泄露
• --no-first-run、--no-default-browser-check：跳过首次运行配置与默认浏览器检查，减少不必要的系统交互与信息暴露
• --process-per-site-instance：为每个模板实例分配独立进程，避免单个进程漏洞影响其他任务
• --disable-blink-features=AutomationControlled：避免Chromium被检测为自动化工具，减少定向攻击风险

注意：绝对禁止启用--disable-web-security、--allow-running-insecure-content这类弱化安全的参数，会彻底破坏浏览器的同源策略防护。

内容的提问来源于stack exchange，提问作者Avneesh Kumar