目前我正在使用apache pdfbox创建数字和电子签名。 最近，我开始了解数字和电子签名中的漏洞，例如通用签名伪造(USF)，增量保存攻击(ISA)和签名包装(SWA)。PDFBox 是否会自动处理此问题，或者我们是否需要在代码中额外强制执行以解决此问题
关于攻击本身
首先，提到的攻击是在2019年2月公开发表的硕士论文(波鸿鲁尔大学的Karsten Meyer zu Selhausen的"PDF签名的安全性")中开发的。派生的"漏洞报告"的预发布版本已于2018年11月与多个信息安全相关组织共享和讨论，因此同时修复了论文中测试的一些PDF签名验证器，以正确显示签名有效性违规或限制。您可以在 PDF 不安全站点上找到概述。
阅读论文并检查示例，我的印象是作者和他的顾问还没有很长时间处理PDF，至少没有深入处理。造成这种印象的两个例子：
-
该论文明确基于2006年发布的PDF参考1.7，它知道PDF在2008年成为ISO标准(ISO 32000-1)，同时在2017年进行了更新(ISO 32000-2)。
其效果是其中的某些方面已经过时了。
例如- 它描述了未来工作的主题"对对象摘要的攻击"，但对象摘要尚未包含在2008年的ISO 32000-1标准中，在论文发表时它们已经过时了10多年。
- 此外，从论文中得出的"漏洞报告"包含改进验证的建议，但提到它需要更改将ByteRange定义为可选参数的 PDF 规范作为缺点......但自 2008 年以来，ISO 32000-1 中一直要求它(至少对于这里感兴趣的签名)！
-
这些操作(尤其是在USF攻击的背景下)是在没有充分尊重生成的PDF的有效性的情况下进行的。
一个可见的效果是，例如，在Adobe Reader中打开测试PDF后，再次关闭它会导致查看者询问是否应保存更改，即查看者必须对文件进行修复，以使其足够有效，以便查看者正确显示它。一方面，这种行为会使用户对操纵保持警惕，另一方面，这些修复本身已经可以使签名无效，从而使可能良好的攻击失败。
对于某些攻击场景，无效的PDF是可以的，甚至可能是有效的，但在许多情况下它们是不必要的，应该避免。
尽管如此，这些攻击还是很有趣的，特别是它们让我想知道那些对PDF有更深入了解的攻击者可能会设计出什么攻击......
作为基于 PDFBox 的签名者防止即将发生的攻击
OP正在"使用apache pdfbox创建数字和电子签名">，关于上述攻击，他想知道他作为签名创建者可以做些什么来防止攻击。
实际上，签名创建者几乎无法阻止攻击，主要是签名验证器的工作来识别操纵。
不过，在某种程度上，他可以提供帮助：签名包装攻击的某些变体使用签名内容中尾随字符串 00 字节的区域;因此他可以通过保持该字符串尽可能短来帮助防止某些攻击。不幸的是，有许多签名设置很难预测要嵌入在此处的签名容器的大小，因此很难避免一定数量的尾随 00 字节。
此外，您可以使用"不允许更改"来使您的签名成为认证签名 - 以这种方式更容易地遵守认证级别的验证者可以识别并将任何更改报告为不允许。但是，如果在长期验证扩展的上下文中使用，这可能会有点障碍。
正确识别攻击是基于 PDFBox 的验证器
首先，PDFBox不提供现成的实用程序来检查增量更新中所做的更改类型。因此，除非您自己实现这一点，否则您的验证器只能对覆盖整个文档的签名说他们签署了文件显示的内容。对于以前的签名，它只能说相应的签名签署了文档的某个早期修订版，但不能说该修订版是否与当前修订版相对应。
基于 PDFBox 的验证器(没有对修订比较的大量贡献)在其报告中对于未覆盖整个文档的签名必须指出这一事实，并要求用户手动确定修订之间的更改。
针对 PDF 安全站点(此处)的示例攻击文件运行 PDFBox 签名验证示例ShowSignature，得到以下结果：
- 很多时候(大多数ISA，所有SWA文件)人们会看到"签名已验证"和"签名不涵盖整个文档"的输出。
- 在一个ISA案例中，有一个
NoSuchAlgorithmException。 - 通常(大多数USF文件)有一个
NullPointerException. - 在一个USF案例中，有一个
ClassCastException. - 在一个USF案例中，有一个
CMSException.
(安全论文验证测试的结果)
因此，只要基于 PDFBox 的验证器在适用的情况下正确输出"签名未覆盖整个文档"警告，并在出现任意异常时输出"失败"或"未知"，它就不会成为当前攻击文件的牺牲品。
正如@Tilman在对该问题的评论中所说，在加载 PDF 进行验证时停用宽松模式可能是一个好主意。这将在任何验证例程被愚弄之前捕获大多数ISA和一些USF攻击......
但要注意：如上所述，论文和示例文件显示出一些缺陷。因此，PDFBox有可能容易受到攻击的改进版本。特别是签名包装方法看起来很有前途，因为PDFBox仅使用内容字符串，而不会将其与字节范围间隙的内容进行比较。