如何防止Apache PDFBox中的通用签名伪造（USF），增量保存攻击（ISA），签名包装（SWA）

Question

目前Iam使用apache pdfbox创建数字和电子签名。最近我开始了解数字和电子签名中的漏洞，如通用签名伪造（USF），增量保存攻击（ISA）和签名包装（SWA）。 PDFBox是自动接受这种关注还是我们需要在代码中另外强制执行此操作

Answer 1

On the attacks themselves

首先，提到的攻击是在2019年2月公开发表的硕士论文（由波士顿鲁尔大学的Karsten Meyer zu Selhausen撰写的"Security of PDF Signatures"）中发展出来的。派生的"Vulnerability Report"的预发布已经与2018年11月，信息安全相关组织的数量已经确定，因此在文件中测试的一些PDF签名验证器已被修复，以正确显示签名有效性违规或限制。你可以找到关于the PDF insecurity site的概述。

阅读论文并检查示例，我得到的印象是作者及其顾问还没有处理PDF很长时间，至少没有深入处理。导致这种印象的两个例子：

• 该论文明确基于2006年出版的PDF Reference 1.7，它知道PDF已于2008年成为ISO标准（ISO 32000-1），同时在2017年更新（ISO 32000-2）。 其结果是它的某些方面已经过时了。例如。 它描述了未来工作“攻击对象摘要”的主题，但是对象摘要在2008年没有被纳入ISO 32000-1标准，它们在论文发表时已经过时了10多年。 。 此外，从论文中得出的“漏洞报告”包含一个改进验证的提议，但提到它需要更改PDF规范，将ByteRange定义为可选参数......但自2008年以来一直需要ISO 32000-1（至少对于这里感兴趣的签名）！
• 操作（最重要的是在USF攻击的背景下）是在没有充分尊重最终PDF的有效性的情况下完成的。 可见效果例如是在Adobe Reader中打开测试PDF之后，再次关闭它会导致查看者询问是否应该保存更改，即对查看器必须应用的文件进行修复以使其足够有效以供查看者正确显示。一方面，这种行为可以使用户对操作保持警惕，另一方面，这些修复本身已经使签名无效，从而使得可能是好的攻击失败。 对于某些攻击情形，无效的PDF是可以的，甚至可能是有效的，但在许多情况下，它们是不必要的，应该避免。

尽管如此，这些攻击很有意思，特别是它们让我想知道哪些攻击者可能会对那些对PDF有更深入了解的攻击者设计攻击......

Preventing upcoming attacks as a PDFBox based signer

OP正在“使用apache pdfbox创建数字和电子签名”，并且就上述攻击而言，奇怪的是他作为签名创建者可以做些什么来防止攻击。

实际上签名创建者几乎无法阻止攻击，它主要是签名验证器识别操作的工作。

但是，在某种程度上，他可以提供帮助：签名包装攻击的某些变体使用签名内容中00字节的尾随字符串区域;所以他可以通过尽可能地缩短字符串来帮助防止一些攻击。遗憾的是，有许多签名设置，其中很难预测要嵌入的签名容器的大小，因此难以避免一定数量的尾随00字节。

此外，您可以使用“不允许更改”来制作签名认证签名 - 以这种方式尊重认证级别的验证者可以更轻松地识别并报告任何不允许的更改。但是，如果在长期验证扩展的上下文中使用，这可能是一个障碍。

Correctly recognizing attacks as a PDFBox based validator

首先，PDFBox不提供可立即使用的实用程序，用于检查增量更新中所做的更改类型。因此，除非您自己实现，否则您的验证器只能说明覆盖整个文档的签名，即签署文件显示的内容。对于先前的签名，它可以仅表示相应的签名签署了该文档的某些早期版本，而不是该修订版是否与当前版本对应。

在其报告中，基于PDFBox的验证器（没有用于修订比较的大量贡献）不包括整个文档的签名必须指出这一事实并要求用户手动确定修订之间的更改。

针对来自PDF安全站点（ShowSignature）的示例攻击文件运行PDFBox签名验证示例here，可获得以下结果：

• 通常（大多数ISA，所有SWA文件）都会看到“签名已验证”的输出以及“签名未涵盖整个文档”。
• 在一个ISA案例中有一个NoSuchAlgorithmException。
• 通常（大多数USF文件）有一个NullPointerException。
• 在一个USF案例中，有一个ClassCastException。
• 在一个USF案例中，有一个CMSException。

（SecurityThesisValidation测试的结果）

因此，只要基于PDFBox的验证器在适用的情况下正确输出“签名不覆盖整个文档”警告并在任意异常情况下输出“失败”或“未知”，它就不会成为当前攻击文件的牺牲品。

正如@Tilman在对该问题的评论中所说，在加载PDF进行验证时停用宽松模式可能是个好主意。在任何验证程序被愚弄之前，这将抓住大多数ISA和一些USF攻击......

---

但要注意：如上所述，论文和示例文件显示出一些不足之处。因此，PDFBox很可能容易受到攻击的改进版本的影响。特别是签名包装方法看起来很有希望，因为PDFBox仅使用Contents字符串，并不将其与字节范围间隙的内容进行比较。