攻击面分析

什么是攻击面分析及其重要性¶

本文介绍了一种简单实用的方法来进行攻击面分析和管理应用程序的攻击面。它旨在供开发人员在设计和更改应用程序时了解和管理应用程序安全风险，以及供应用程序安全专家进行安全风险评估。这里的重点是保护应用程序免受外部攻击——它没有考虑对系统用户或操作员的攻击（例如恶意软件注入、社会工程攻击），并且较少关注内部威胁，尽管原则仍然存在相同。内部攻击面可能与外部攻击面不同，一些用户可能有很多访问权限。

攻击面分析是关于映射系统的哪些部分需要审查和测试安全漏洞。攻击面分析的重点是了解应用程序中的风险区域，让开发人员和安全专家了解应用程序的哪些部分容易受到攻击，找到最小化攻击的方法，并注意攻击面何时以及如何变化以及从风险的角度来看这意味着什么。

攻击面分析通常由安全架构师和渗透测试人员完成。但是开发人员在设计、构建和更改系统时应该了解和监控攻击面。

攻击面分析可帮助您：

确定系统的哪些功能和哪些部分需要审查/测试安全漏洞
识别需要纵深防御保护的高风险代码区域——您需要保护系统的哪些部分
确定何时更改了攻击面并需要进行某种威胁评估

定义应用程序的攻击面¶

攻击面描述了攻击者可以进入系统的所有不同点，以及他们可以从哪里获取数据。

应用程序的攻击面是：

数据/命令进出应用程序的所有路径的总和，以及
保护这些路径的代码（包括资源连接和身份验证、授权、活动日志记录、数据验证和编码）
应用程序中使用的所有有价值的数据，包括秘密和密钥、知识产权、关键业务数据、个人数据和 PII，以及
保护这些数据的代码（包括加密和校验和、访问审计、数据完整性和操作安全控制）。

您将此模型与可以访问系统（无论是否已授权）的不同类型的用户（角色、权限级别）叠加在一起。复杂性随着不同类型用户的数量而增加。但重要的是要特别关注两个极端：未经身份验证的匿名用户和高权限管理员用户（例如数据库管理员、系统管理员）。

根据风险（面向外部或内部）、目的、实施、设计和技术，将每种类型的攻击点分组到桶中。然后，您可以计算每种类型的攻击点数量，然后为每种类型选择一些案例，并将您的审查/评估重点放在这些案例上。

使用这种方法，您无需了解每个端点即可了解攻击面和系统的潜在风险概况。相反，您可以计算不同的一般类型的端点和每种类型的点数。有了它，您可以预算评估大规模风险所需的费用，并且可以判断应用程序的风险状况何时发生重大变化。

微服务和云原生应用¶

微服务和云原生应用程序由多个较小的组件组成，使用 API 松散耦合并可独立扩展。在评估这种架构风格的应用程序的攻击面时，您应该优先考虑可从攻击源（例如来自 Internet 的外部流量）到达的组件。这些组件可能位于代理层、负载均衡器和入口控制器的后面，并且可能会在没有警告的情况下自动缩放。

Scope或ThreatMapper等开源工具有助于可视化攻击面。

识别和映射攻击面¶

您可以开始在图片和注释中构建攻击面的基线描述。花几个小时从攻击者的角度审阅设计和架构文档。通读源代码并确定不同的入口/出口点：

用户界面 (UI) 表单和字段
HTTP 标头和 cookie
蜜蜂
文件
数据库
其他本地存储
电子邮件或其他类型的消息
运行时参数
...您的入口/出口点

不同攻击点的总数加起来很容易达到数千甚至更多。为了使其易于管理，根据功能、设计和技术将模型分成不同的类型：

登录/身份验证入口点
管理界面
查询及搜寻功能
数据输入 (CRUD) 表单
业务流程
事务接口/API
操作命令和监控接口/API
与其他应用程序/系统的接口
...你的类型

您还需要通过采访系统的开发人员和用户，并再次审查源代码，来识别应用程序中有价值的数据（例如机密、敏感、受监管）。

您还可以通过扫描应用程序来构建攻击面的图片。对于 Web 应用程序，您可以使用OWASP ZAP或Arachni或Skipfish或w3af等工具或众多商业动态测试和漏洞扫描工具或服务之一来抓取您的应用程序并映射可通过 Web 访问的应用程序部分。某些 Web 应用程序防火墙 (WAF) 也可能能够导出应用程序入口点的模型。

通过浏览系统中的一些主要用例来验证并补充您对攻击面的理解：注册和创建用户配置文件、登录、搜索项目、下订单、更改订单等. 跟踪系统中的控制流和数据流，了解信息的验证方式和存储位置、触及的资源以及涉及的其他系统。Attack Surface Analysis 和Application Threat Modeling之间存在递归关系：Attack Surface 的变化应该触发威胁建模，而威胁建模可以帮助您了解应用程序的 Attack Surface。

攻击面模型开始时可能比较粗糙且不完整，尤其是如果您之前没有对应用程序做过任何安全工作的话。当您在安全分析中深入挖掘时，或者当您更多地使用应用程序并意识到您对攻击面的理解有所提高时，填补漏洞。

测量和评估攻击面¶

绘制攻击面图后，确定高风险区域。关注远程入口点——与外部系统和互联网的接口——尤其是系统允许匿名、公共访问的地方。

面向网络，尤其是面向互联网的代码
网络表格
来自网络外部的文件
与其他系统的向后兼容接口——旧协议，有时是旧代码和库，难以维护和测试多个版本
自定义 API——协议等——可能在设计和实现中存在错误
安全代码：与密码学、身份验证、授权（访问控制）和会话管理有关的任何事情

这些通常是您最容易受到攻击的地方。然后了解您实施了哪些补偿控制措施、网络防火墙和应用程序防火墙等操作控制措施，以及有助于保护您的应用程序的入侵检测或预防系统。

Microsoft 的 Michael Howard 和其他研究人员开发了一种方法来测量应用程序的攻击面，并跟踪攻击面随时间的变化，称为相对攻击面商数 (RSQ)。使用此方法，您可以计算系统的总体攻击面分数，并在对系统及其部署方式进行更改时衡量此分数。卡内基梅隆大学的研究人员在这项工作的基础上开发了一种计算攻击面指标的正式方法对于像 SAP 这样的大型系统。他们将攻击面计算为所有入口点和出口点、通道（客户端或外部系统连接到系统的不同方式，包括 TCP/UDP 端口、RPC 端点、命名管道......）和不受信任的数据元素的总和. 然后，他们对这些攻击面元素应用破坏潜力/努力比率来识别高风险区域。

请注意，部署应用程序的多个版本，保留不再使用的功能以防将来可能需要它们，或者保留旧的备份副本和未使用的代码会增加攻击面。应使用源代码控制和稳健的变更管理/配置实践来确保实际部署的攻击面与理论攻击面尽可能接近。

代码和数据的备份 - 在线和离线媒体 - 是系统攻击面的一个重要但经常被忽视的部分。如果您通过不保护您的备份将一切交给坏人，那么通过编写安全软件和加固基础架构来保护您的数据和 IP 将全部付诸东流。

管理攻击面¶

一旦您对攻击面有了基本的了解，您就可以在对应用程序进行更改时使用它来逐步识别和管理未来的风险。问你自己：

发生了什么变化？
你有什么不同？（技术，新方法，......）
你能打开什么洞？

您创建的第一个网页会显着打开系统的攻击面并引入各种新风险。如果您向该页面或类似的其他网页添加另一个字段，虽然从技术上讲您已经扩大了攻击面，但您并没有以有意义的方式增加应用程序的风险状况。除非您遵循新设计或使用新框架，否则这些增量更改中的每一个都大同小异。

如果您添加另一个网页，该网页遵循与现有网页相同的设计并使用相同的技术，则很容易理解它需要多少安全测试和审查。如果您添加一个新的 Web 服务 API 或可以从 Internet 上传的文件，这些更改中的每一个都会再次具有不同的风险概况 - 查看更改是否适合现有的存储桶，查看现有的控制和保护是否适用。如果您要添加不属于现有存储桶的内容，这意味着您必须进行更彻底的风险评估，以了解您可能会打开什么样的安全漏洞以及您需要采取哪些保护措施。

会话管理、身份验证和密码管理的更改直接影响攻击面，需要进行审查。授权和访问控制逻辑的更改也是如此，特别是添加或更改角色定义，添加具有高权限的管理员用户或管理员功能。对于处理加密和秘密的代码的更改也是如此。对数据验证方式的根本改变。以及对分层和信任关系的重大架构更改，或技术架构的根本更改——换出您的 Web 服务器或数据库平台，或更改运行时操作系统。

当您添加新的用户类型或角色或权限级别时，您会进行相同类型的分析和风险评估。覆盖数据和功能的访问类型，并查找问题和不一致之处。了解应用程序的访问模型很重要，无论是积极的（默认情况下拒绝访问）还是消极的（默认情况下允许访问）。在积极的访问模型中，在定义允许新用户类型或角色使用哪些数据或功能方面的任何错误都很容易被发现。在消极访问模型中，您必须更加小心，以确保用户无法访问他们不应被允许访问的数据/功能。

这种威胁或风险评估可以定期进行，或者作为串行/分阶段/螺旋式/瀑布式开发项目中设计工作的一部分，或者在敏捷/迭代开发中连续递增地进行。

通常，随着您添加更多界面和用户类型并与其他系统集成，应用程序的攻击面会随着时间的推移而增加。您还希望通过简化模型（例如，减少用户级别的数量或不存储您绝对不需要的机密数据）、关闭功能和通过引入诸如 Web 应用程序防火墙 (WAF) 和实时特定于应用程序的攻击检测之类的操作控制来减少未使用的接口。