接口多样化防御漏洞攻击研究

关于利用漏洞的内部接口及接口多样化的含义调查

1 引言

在防御计算机系统攻击时，我们必须保护一个包含多个未知漏洞的复杂环境。而攻击者则相反，他们只需要一两个可利用的安全漏洞就能攻破系统。大多数恶意软件攻击都依赖于目标平台上的可预测且已知的内部接口。接口多样化是应对这一威胁的一种有前景的方法。目前，不同的执行平台数量相当有限。由于这种所谓的“软件单一化”，存在大量具有相同内部结构的相同执行平台副本。因此，一个恶意程序可以在数百万台计算机上运行。恶意软件通过系统外部接口中的安全漏洞进入系统，但其实际的恶意载荷则利用了关于内部接口的知识。然而，如果每台计算机上的内部接口各不相同，那么依赖于相同接口知识的恶意软件将变得无效[9,11]。

基于这一思路，对目标系统的内部接口应用唯一的随机化——即多样化——可使软件更能抵御恶意攻击。在多样化的系统中，恶意软件不再了解系统中使用的密钥“语言”，因而无法访问任何关键资源。

本文的贡献如下。通过调查数百个现有漏洞，我们研究了攻击者所针对的接口以及相关的攻击向量和有效载荷。这使我们能够明确哪些接口应进行多样化以防止攻击。本研究聚焦于接口并对利用程序进行实际分析，从而区别于其他如[23]之类的多样化调研。因此，我们通过一项实证研究为持续讨论做出贡献，该研究分析现实世界中的攻击及其如何通过多样化加以防范。此外，我们还研究了由多样化引起的变更传播到了哪些地方，以及对特定接口进行多样化有多困难。进一步地，基于攻击者通常针对的接口集合，我们的研究还梳理了这些接口中已有多少在文献中被实现多样化，并提出了未来适合多样化的候选对象。最后，并非所有攻击都能通过多样化方法加以阻止，但本研究表明，大多数已分析的漏洞利用均可被成功阻止。

2 接口多样化

2.1 基本思想

通过对接口多样化，我们可以在不影响暴露给最终用户的接口的情况下，限制攻击者对执行环境所能做出的假设数量。也就是说，多样化会修改应用程序或系统的内部结构，使其对攻击者而言变得不可预测。多样化可以通过不同的混淆技术[9]来实现。在接口多样化中，甚至可以采用重命名和更改函数签名中参数顺序等简单的混淆方法。

需要注意的是，此处对接口interface一词的理解相当宽泛。所谓接口，不仅指软件模块提供的常规接口，还包括例如语言命令或内存地址（服务/资源的）等，这些都被视为可进行多样化的接口。从这个意义上讲，任何可用于访问计算机关键资源的内容都可称为接口。

一个说明接口多样化的实际例子是更改操作系统的系统调用号。系统调用是程序向操作系统内核请求服务并访问计算机基本资源的一种方式。因此，对它们进行多样化是有意义的，以防止对手利用系统调用。

例如，在Linux中，可以通过将原始系统调用号（超过300个系统调用）替换为新的系统调用号来实现这种多样化。现在，必须将这种多样化传播到使用系统调用的代码中。系统调用号必须在所有直接调用系统调用的库和程序中进行更改。那些直接或间接使用系统调用的库函数名称也必须替换，以防止恶意软件利用它们。换句话说，必须对系统调用的传递闭包进行多样化，以防止恶意程序利用这些接口访问计算机资源。此外，当每个Linux安装的系统调用号多样化是唯一的时候，攻击者将无法利用攻破一个系统所获得的信息来进行大规模攻击。

2.2 内部与外部接口

应用程序提供并使用接口。通常，应用程序会向其用户暴露一个外部接口，以提供所需的功能。例如，对于一个Web服务器而言，该外部接口可以是有效的HTTP请求和响应集合。

然而，除了外部接口之外，应用程序通常还会向外界暴露其他细节，这通常是其实现的结果。根据定义，这些内部接口并不期望被外部使用者所使用，它们被视为实现细节。

恶意软件与合法用户的不同之处在于，恶意软件通常依赖于这些内部接口。这是因为如果恶意软件仅使用外部接口——即仅利用应用程序设计提供的功能——那么它的能力将仅限于普通用户的水平。

应用程序还可能通过其外部接口意外暴露自身的内部接口，或其所使用的其他组件的接口。由于缺乏输入净化而导致的SQL注入就是此类漏洞的一个典型例子。SQL注入利用了某些应用程序意外通过其外部接口暴露数据库后端内部接口这一事实。例如，如果通过Web服务发生SQL注入，则外部HTTP接口实际上会成为数据库的网关。

接下来，我们将介绍一项研究，分析漏洞及其所利用的内部接口。基于此，我们讨论了多样化多种类型内部接口的方法，以减轻和防止恶意攻击。

3 研究设置

3.1 研究的设定

为了研究攻击者所利用的内部接口——即可以通过多样化来防止攻击的接口——我们研究了来自漏洞数据库的500个漏洞利用1。我们使用的500个样本是从数据库中近年来添加的利用程序中随机选择的2010和2015。该随机样本可被视为足够充分；其数量约占纵向抽样区间内利用程序总数的百分之四。

在本研究中，我们遵循基钦厄姆[21]提出的系统性综述指南。每个漏洞均由至少两名评审人员独立研究，所有案例均在作者会议中进行讨论。少数存在分歧的情况也在这些会议中得到解决，直至达成一致意见。针对每个漏洞利用，回答了以下问题：

1. 有效载荷的类型是什么？
2. 漏洞利用的执行环境是什么？
3. 为了防止攻击，应进行多样化的接口（或哪些接口）是什么？
4. 多样化后，我们需要将变更传播到哪些地方？
5. 攻击向量是什么？（例如上传的文件）
6. 攻击类型是什么？（例如SQL注入）

显然，由于我们想要研究接口，第三个问题是最重要的一项。第四个问题的答案直接由它得出。其他问题有助于我们定义需多样化的接口，并了解不同变量之间的关系，例如攻击类型和需多样化的接口。选择漏洞数据库是因为它是一个相当知名的漏洞数据库，其中包含针对攻击的详细概念验证实现。其他一些列出漏洞的来源，如通用漏洞和暴露（CVE），对于我们的目的而言对漏洞的描述不够准确，因此被排除在外。

3.2 变量

针对500个利用程序中的每一个，确定了以下变量。这些变量对应于上述问题中概述的内容。

有效载荷。 有效载荷描述了攻击者通过攻击向量注入到系统中的内容。根据攻击类型的不同，有效载荷可以是被解释器执行的内容，也可以是不打算被执行的静态内容。例如，在注入攻击中使用的一段JavaScript代码需要被执行，而为披露文件内容所提供的文件名则不需要执行。在这里，我们将主要关注可执行载荷。

执行环境。 我们还关注有效载荷由哪种解释器执行，以防其被解释为可执行文件。例如，如果有效载荷是一段恶意的JavaScript代码，则执行环境是JavaScript解释器。

可能的执行环境包括：

• 应用程序地址空间和运行上下文。这是将机器码注入进程的情况。
• SQL数据库引擎。在SQL注入攻击的情况下，注入的查询显然会被接收数据库的引擎执行。
• 网页脚本。将JavaScript或VBScript注入页面的情况，例如跨站脚本攻击。攻击者可以访问浏览器和相关页面提供的所有常用功能。
• Shell解释器。命令行外壳也可用于执行任意代码。
• 其他脚本语言的解释器。其他脚本环境（如PHP和Python）与前述情况非常相似。

需多样化的接口。 本研究中最重要的变量是应进行多样化的接口。一旦确定了有效载荷的执行器及其所提供环境的特征，我们就可以确定应进行多样化以防止攻击的接口。例如，如果有效载荷包含SQL命令，则应对SQL语言进行多样化。有时可能存在多个可选的可多样化接口来防止攻击。例如，如果有效载荷中包含本地代码，则通常可以通过指令集随机化或对操作系统的系统调用号进行多样化来阻止攻击。

接口多样化需要传播变更。 当我们成功对相关接口应用了多样化技术，使得攻击者无法针对该接口时，还必须将这些变更传播到依赖于现已实现多样化的接口的组件中。因此，为了评估特定接口多样化的可行性，还需要确定变更将要传播到的软件层。例如，如果我们对关系型数据库的对外SQL接口进行了多样化，则还必须将这些变更传播到使用该接口的应用程序和组件中。

攻击向量。 攻击向量描述了恶意软件用于将其有效载荷传入系统的通道。例如，许多SQL注入通过HTTP请求的GET和POST参数发生。在后续的研究中，我们将看到在对特定接口进行多样化时，哪些类型的攻击向量会被缓解。

攻击类型。 最后，我们还列出了每个漏洞的攻击类型。这使我们能够了解通过多样化特定接口所能防止或缓解的攻击类型。例如任意代码执行。在本研究中，该攻击类型意味着在某个进程的地址空间中执行了任意原生代码。

4 结果

4.1 载荷类型

在我们研究的500个利用程序中，有356个具有明显可识别的可执行载荷以及可通过多样化来阻止攻击的接口。需要注意的是，并非所有攻击都有明确的载荷。例如，跨站请求伪造攻击——即来自被网站信任的客户端发出未经授权的命令——实际上并没有可执行载荷。然而，这种解释可能受到质疑，因为在复杂系统中，很难明确区分可执行代码和指导执行的数据。

每个有效载荷都在某种执行环境中执行。已针对每种载荷类别确定了该环境。载荷类别及其相应的执行环境如表1所示。

有效载荷	出现次数	执行环境
本地代码	112	CPU和操作系统
SQL	103	SQL引擎
JavaScript	65	脚本引擎
Any	32	Any
shell脚本	30	命令行外壳
PHP	9	PHP解释器
VBScript	4	VBScript解释器
Java字节码	1	Java虚拟机
Python	1	Python解释器

我们可以看到，由于SQL注入攻击的普遍性，在我们的研究中，SQL查询类有效载荷占比最高。包含本地代码的漏洞数量几乎与之相当。紧随其后的是JavaScript（也可能包含HTML代码），这类有效载荷通常用于跨站脚本（XSS）攻击。

类别any适用于可将任意文件上传到系统的利用程序。在这种情况下，文件中的可执行载荷实际上可以是任何内容，无法具体指定。PHP和JavaScript是此类情况下的常见选择，但本地代码和shell脚本也是可行的选项。

还有相当多的有效载荷是用shell脚本编写的；攻击者通常最终目的是执行shell命令以实现其目标。一些较小的类别包括PHP、VBScript、Perl和Python，它们都是解释型脚本语言。有一个漏洞的有效载荷使用了Java字节码。

这些类别及其执行环境使我们能够了解哪些接口是适合多样化的候选对象。接下来我们将讨论具体的接口。

4.2 已发现的接口

表2中列出了发现的接口。值得注意的是，已识别的接口的重要性超过了其比例，因为正如后文所讨论的，漏洞数据库中漏洞的分布可能存在一定程度的偏差。尽管如此，该分析仍有助于深入了解适合多样化的候选对象中的流行接口。

接口	出现次数
操作系统和CPU接口	112
SQL	103
JavaScript	64
命令行外壳语言	33
路径或文件名	33
Any	31
参数名称	21
PHP	9
VBScript	2
Java字节码	1
Python	1

总计，有410个利用程序可以通过接口多样化来缓解或阻止。这占所有漏洞的82.0%。请注意，并非所有攻击都可以通过接口多样化来防止。例如，如果由于软件中的逻辑漏洞导致认证机制被绕过，则通常无法通过多样化来修复此问题。在2个漏洞的情况下，没有可用的源代码，且提供的描述不够准确，无法可靠地推断出需要多样化以防止攻击的内部接口。

值得注意的是，可通过多样化来防止或缓解的利用程序数量高于具有可执行载荷的利用程序数量。这是因为有些攻击即使不具备可执行载荷，也可以通过多样化来击败。这类利用程序的一个例子是我们之前提到的跨站请求伪造攻击。该攻击不需要包含任何可执行载荷，但可以通过为Web应用程序中的每个HTTP请求生成并在服务器端验证的唯一且随机的密钥令牌来防止。这显然可以被视为一种多样化技术。

接下来，我们将对每个发现的接口进行更详细的讨论。

在SQL注入攻击中，攻击者将恶意的SQL片段注入到SQL查询中。避免这种情况的一个明显方法是多样化SQL语言中的命令。这种多样化必须传播到所有使用特定服务器的多样化SQL语言的程序和库中。

操作系统接口或指令集的多样化可用于防御旨在在系统中执行本地代码有效载荷的攻击。尽管为了简化我们在此将接口合并讨论，但在操作系统（和CPU）中有多个接口可以实现多样化，从而使恶意的本地代码失效。

首先，正如我们在第2节示例中已讨论的那样，系统调用接口可以被唯一地多样化。这将阻止直接调用系统调用的恶意软件正常运行。这种多样化必须传播到所有受信任的二进制文件，以确保这些可执行文件能够正常工作。此外，直接或间接调用系统调用的库函数在包含或调用这些函数的二进制文件中也必须进行多样化（重命名）。函数名称的多样化会传播到所有调用导致系统调用的库函数的二进制文件中。

其次，特定机器语言中使用的整个指令集可以实现多样化。这是防止恶意二进制文件（使用错误指令集的二进制文件）在系统中造成破坏的一种非常有效的方法。

第三，为了抵御利用内存布局知识的利用程序，address space layout可以被随机化。该技术会随机化进程重要区域中的地址位置。

当Web应用程序存在XSS漏洞时，攻击者可以将JavaScript代码（或HTML）注入网页。如果JavaScript语言能够实现多样化，这种情况就可以避免。相关更改必须传播到每台客户端机器上的浏览器的JavaScript引擎。

攻击者的另一个常见目标是打开命令行外壳，以便使用shell脚本实施攻击。在这种情况下，对命令行外壳语言进行多样化将能够阻止攻击。这种多样化必须传播到系统中的所有脚本文件。此外，任何在运行时动态生成脚本的程序的源代码也必须进行更新。

文件路径和名称可以在不同的计算机上设置为唯一。这会使文件泄露攻击更加困难。特别是对于密码文件等关键文件，在某些情况下非常有用。此案例说明了多样化不仅可以防止恶意载荷的执行，还可以防止信息泄露。

当任意文件被上传到系统中时，它可能包含任意可执行内容（PHP、JavaScript、本地代码等）。因此，在这些情况下，需多样化的接口可能是此处介绍的其他任何接口。

有时，在Web应用程序中随机化GET或POST parameter names可以提供额外的安全性。通过这种方式，对手将恶意载荷传入系统不再那么容易，成功攻击的威胁也随之降低。此方法同样适用于例如SQL表名和字段。

在某些情况下，当攻击者能够上传自己选择的文件，或有机会在Web环境中进行代码注入攻击时，有效载荷通常使用PHP编写。为了抵御这种威胁，最明显的选择是对PHP语言进行多样化。PHP的多样化与对其他解释型语言（如Bash或Python）的多样化非常相似。这些更改将传播到特定服务器上的所有PHP脚本和库。

还有一些Other罕见的接口。这些是VBScript、Python和Java字节码。对VBScript进行多样化可能与对JavaScript和其他解释型脚本语言的多样化类似。Python也是如此；在许多方面，它与shell脚本相似。

为了抵御针对Java虚拟机的攻击，可以对Java字节码中使用的指令集进行多样化。在这种情况下，这些更改将影响Java编译器和执行代码的虚拟机。

4.3 攻击类型和攻击向量

攻击向量与多样化接口之间的关系如表3所示。换句话说，该表说明了每种多样化接口能够缓解哪些类型的攻击向量。由于不同攻击向量的数量较多，我们将其划分为五个抽象类别。HTTP包括GET和POST参数以及HTTP头等攻击向量。远程协议（表3中的RP）指通过TCP、RPC和FTP等其他协议传递的有效载荷。本地配置（LC）包括应用程序设置、输入文件、程序参数和Windows注册表等向量。本地可执行文件（LE）类别用于区分可执行文件中的不同攻击向量，例如DLL注入、函数调用，或仅仅是上传到系统的可执行文件。此外还有一些其他情况，无法归入前述类别。

接口	HTTP	LC	LE	RP	其他	总计
操作系统和CPU	8	2	26	3	3	112
SQL	103	0	0	0	0	103
JavaScript	61	1	1	1	0	64
Shell	19	7	1	2	4	33
路径或文件名	32	0	0	0	0	32
Any	0	0	30	0	1	31
参数名称	21	0	0	0	0	21
PHP	8	0	1	0	0	9
VBScript	0	0	1	0	0	1
Python	1	0	0	0	0	1
Java字节码	0	0	0	0	1	1
总计	253	61	55	29	10	408

在表3中，我们可以看到，例如，对SQL语言接口进行多样化主要可以防止利用HTTP（GET和POST参数）作为攻击向量的攻击，这并不令人意外。另一方面，通过多样化操作系统接口来防范的本地代码利用程序，则通过许多不同的攻击向量渗透到系统中。

类似地，表4展示了通过特定接口的多样化所阻止或缓解的不同攻击类型。最大的类别是SQL注入攻击和包含执行任意原生代码的攻击。

攻击类型	接口	数量	总计
SQL注入	SQL	103	103
任意代码执行	操作系统和CPU	95	97
任意代码执行	Any	1
任意代码执行	Java字节码	1
XSS	JavaScript	63	63
命令注入	Shell	32	41
命令注入	PHP	8
命令注入	Python	1
本地文件包含	路径或文件名	27	34
本地文件包含	参数名称	7
任意文件上传	Any	30	30
跨站请求伪造	JavaScript	1	11
跨站请求伪造	路径或文件名	1
跨站请求伪造	参数名称	9
权限提升	操作系统和CPU	7	10
权限提升	Shell	1
权限提升	参数名称	2
拒绝服务	操作系统和CPU	7	10
拒绝服务	参数名称	2
拒绝服务	PHP	1
内存修改	操作系统和CPU	2	3
内存修改	VBScript	1
目录遍历	路径或文件名	3	3
沙箱逃逸	操作系统和CPU	2	2
信息泄露	路径或文件名	1	1
任意文件删除	参数名称	1	1

这两类合计约占全部500个漏洞利用的20%。如前所述，约20%的攻击无法通过多样化来防止，因此不在本讨论范围内。

当涉及到本地代码时，多样化通常被认为是一种主要防止缓冲区溢出攻击的方法，但根据本研究，我们认为它是一种更为通用的工具，可用于普遍防止任意代码执行。例如，多样化能够有效应对那些将恶意可执行文件上传到系统并试图基于对已知接口的了解来执行任意代码的攻击。

4.4 评估

尽管我们的样本是随机选择的，且利用程序的数量可视为足够，但样本在2010年代初期以及Web应用程序漏洞利用方面存在偏向性（见图1）。从图2可以看出，数据库中的其他三个元数据类别——拒绝服务（DoS）、本地和远程漏洞利用——相比Web漏洞利用收录的样本数量要少得多。此外，值得指出的是，EDB是一个基于社区的数据库，所存档的利用程序可能反映了为这一开放数据存档做出贡献的安全研究人员的偏好。然而，在观察的时间间隔内，所选样本与EDB中存档的利用程序总数并无显著差异；因此可以说该样本能够代表EDB的整体情况，当然，若试图直接将其推广到整个利用程序群体则存在问题。

然而，尽管报告中的比例可能无法完全反映现实情况，但我们通过对500个漏洞利用的分析所得到的数据仍然能够很好地说明哪些类型的接口是多样化的良好目标。我们还发现接口与其他变量之间的许多依赖关系，这些依赖关系并不真正取决于它们的比例。

5 现有接口多样化研究

在本节中，我们将简要回顾文献中提出的针对不同接口的多样化方法。本次综述主要基于我们在开展软件安全领域中多样化与混淆技术的系统性文献回顾时所收集的数据[15]。然而，此处的视角（哪些接口已被多样化）完全是新颖的。

操作系统和CPU。 周和宋最先提出了通过更改系统调用映射和多样化库API来使恶意软件失效的想法[7]。江等人[18]和梁等人[25]随后对该想法进行了更准确的概念性方案描述和实现。劳蒂等人也提出了一种系统调用多样化[28]以及对二进制文件中的库函数名称进行多样化的方案[24]。劳蒂等人在执行前更改系统调用号和函数名称，而江等人则在运行时动态地进行多样化。运行时多样化提供了更高的灵活性（例如，某些选定的应用程序可以在无需多样化的情况下运行），但会影响性能。这些修改系统调用映射和库函数名称的技术，与通过对高级程序代码中的静态标识符重命名以获得程序唯一实例的多样化技术具有相似之处[17]。

另一种防御本地代码攻击的方法是指令集随机化（ISR）。指令集也可被视为恶意软件已知并利用的一种接口。因此，可以通过多样化机器码指令来防止任何不可信代码的执行[4,5]。应用程序所使用的指令可通过特定函数（如异或[19]）进行随机化。指令集随机化的一个问题是目前没有commercially available CPU支持该技术。然而，随着云环境和虚拟机的日益普及，我们预计这种方法将变得更加可用[32]。

最后，通过多样化程序内存布局[8]可以thwart利用内存结构的攻击。这种方法通常称为地址空间布局随机化（ASLR）。它用于保护系统免受导致任意代码执行的缓冲区溢出攻击。这是唯一的多样化已在现有操作系统中广泛使用的技术[20]。ASLR随机排列进程地址空间最重要区域的位置，包括可执行文件的基址以及内存中的栈、堆和库位置[1,16,30]。对手将无法跳转到内存中的特定位置。

还需要注意的是，尽管许多二进制文件的多样化方法并未明确针对我们在此称为接口的部分，但这些方法仍可能有效缓解多种恶意攻击。二进制文件可以被重写[22]，或通过编译器作为多样化引擎生成唯一的二进制文件[12]。所使用的多样化方法包括例如反汇编和随机化函数块[14]、将应用程序二进制文件拆分为块并重新排列[13]，以及混淆和重定位信息[10]。所有这些方法都会产生多样化的二进制文件，从而增加对手的攻击难度。

Shell. Uitto等人提供了一种多样化Bash解释器[31]的实现。通过对Bash解释器的词法分析器所识别的所有令牌进行多样化，以防止对手编写恶意脚本片段。类似地，Kc等人先前修改了Perl解释器，以支持执行多样化的Perl脚本[19]。

多样化命令行外壳语言会带来一些挑战，例如共享库（如果许多唯一多样化的脚本使用一个公共库，该库应如何进行多样化？）以及在运行时动态生成脚本的程序（这些程序的源代码必须被修改）。否则，该方法效果良好，且仅带来适度的性能开销[19]。

SQL. SQL多样化由 Boyd 和 Kruegel 在[6]中提出。他们采用基于代理的解决方案，在多样化的SQL查询到达服务器之前对其进行解码。劳蒂等人提出了一种直接集成到SQL服务器本身的解决方案[29]。后一种方案虽然可提供更高的安全性，但灵活性较低。SQL多样化功能也可以嵌入到数据库驱动程序中。一个此类方案的例子是 Locasto 和 Kruegel 实现的PostgreSQL JDBC驱动程序[26]。

该接口多样化方案面临的最大挑战可能是需要将更改传播到生成SQL查询的应用程序。这些查询通常在运行时动态创建，这给自动多样化带来了困难。最困难的情况可以通过为软件开发者提供一种工具来处理，该工具可帮助他们实现最复杂查询的多样化[20,29]。

JavaScript. 阿萨纳西奥波洛斯等人提出了一种JavaScript多样化方案，以防止[3]中的跨站脚本攻击和基于DOM的攻击。该概念验证实现已针对超过1300个跨站脚本攻击进行了测试，并成功阻止了这些攻击，且性能开销可忽略不计。这种JavaScript多样化明显面临的挑战是，JavaScript在服务器端生成但在客户端机器上执行。因此，为了使该方案能够工作，必须同时修改客户端（浏览器）和服务器端（生成JavaScript代码的组件）。一种解决方案是实现浏览器扩展或在客户端和服务器端部署代理[2]。这些组件负责多样化和解码。

在对JavaScript进行多样化时，一个重大挑战是客户端和服务器之间共享多样化密钥。在[2]中，用于解码多样化的密钥通过HTTP消息的头部发送，因此每次请求的多样化都可以是唯一的。此外，这种多样化还必须传播到所有外部JavaScript文件，这进一步增加了复杂性。

Interfaces not yet diversified. 有一些接口仍有待实现多样化，尽管这些并非最值得关注的。据我们所知，目前尚无针对PHP语言的多样化实现方案。然而，这一问题很可能与其他已经实现多样化的解释型语言（如Bash和Perl）非常相似。VBScript也缺乏多样化解释器的实现。作为一种网页脚本，它将面临与JavaScript相同的问题场景。

根据我们分析的一些利用程序，某些特定应用接口和协议也可能是适合多样化的候选对象。由于这种特定于应用程序的安全措施不够通用，我们在此未予以重点关注。一些应用程序开发者可能会希望使用这种方法来增强其应用程序的安全性。

最后，我们尚未考虑在此处对任何网络协议进行多样化。这可能会阻止某些攻击，是一个有趣的话题，但不在本研究的范围之内。

6 结论

本研究表明，通过多样化攻击者所利用的一些最常见接口，可以使绝大多数（80%）已分析的漏洞利用失效。我们还指出，在文献中通常认为适用的攻击类别之外，多样化似乎对更多类别的攻击都是一种有效的防御措施。

我们的文献综述表明，本研究中识别出的几乎所有接口的多样化在现有文献中已有讨论。然而，将多样化作为安全措施的实际应用仍不广泛，且缺乏实用的多样化工具。因此，与接口多样化方法相关的挑战和局限性仍需进一步深入研究，需要提出切实可行的解决方案以进一步提高其可行性和可用性。尽管部署接口多样化方案通常并不简单，但它仍是一种非常有前景的方法，能够有效抵御多种类型的攻击。随着地址空间布局随机化已被纳入多个操作系统之中，大规模应用多样化已经拉开序幕。在我们看来，多样化可被视为一种全面的防护机制，覆盖特定系统中的所有关键接口和软件层（另见[27]）。

未来，我们希望看到更多的接口多样化方案在实际软件系统中得到应用。代码量较小且更新不频繁的受限系统——例如一些带有轻量级操作系统的微型嵌入式系统——是开始实施的理想选择。